How can I speed up calls to the ledger software?

[MicrophoneGuy]

G'day all, 

Got an interesting question. I'm writing an app that interacts with the XRP Ledger, and it seems like calls to the ledger are taking a long and variable time to return, for calls that seem like they shouldn't take that long. 

The app makes 4-6 calls to the ledger each time it runs: a couple of bookOffers, an accountInfo and an accountLines, and occasionally an offerCreate. It's taking a surprisingly long time to run, though - up to ten seconds - and as best I can tell, most of its time is being consumed with calls to the XRP Ledger node. I've wrapped timers around the individual calls to the ledger, and they can take up to three seconds each to return. 

Does anyone have any idea why the XRPL software might be taking so long to respond to calls, or whether there's a way to speed them up?

Couple of possible data points: 

1. I'm writing in Python (using xrpl-py). Haven't tried running a profiler on the code, but I could give it a shot if people are interested.
2. I've tried switching from JSON-RPC (on s1.ripple.com) to websockets (on xrpl.ws), and it didn't make any difference. (Please don't say 'run your own node', I'm trying to keep this lightweight...!)
3. I've also tried consolidating multiple calls into a single websocket client session, and it doesn't seem to make any difference.
4. As best I can tell it's not a network latency thing; the calls seem to be equally slow whether the code is running on my laptop or in AWS us-west-2.

(As a side note, I ran into an odd bug in xrpl-py while I was testing this - some bookOffers calls that work through the JSON-RPC client stopped working when I switched to websockets. If you're finding that bookOffers is throwing weird type errors, try not using the 'value' field in your issuedCurrency objects.)

 

[jn_r]

9 hours ago, MicrophoneGuy said:

G'day all, 

Got an interesting question. I'm writing an app that interacts with the XRP Ledger, and it seems like calls to the ledger are taking a long and variable time to return, for calls that seem like they shouldn't take that long. 

The app makes 4-6 calls to the ledger each time it runs: a couple of bookOffers, an accountInfo and an accountLines, and occasionally an offerCreate. It's taking a surprisingly long time to run, though - up to ten seconds - and as best I can tell, most of its time is being consumed with calls to the XRP Ledger node. I've wrapped timers around the individual calls to the ledger, and they can take up to three seconds each to return. 

Does anyone have any idea why the XRPL software might be taking so long to respond to calls, or whether there's a way to speed them up?

Couple of possible data points: 

1. I'm writing in Python (using xrpl-py). Haven't tried running a profiler on the code, but I could give it a shot if people are interested.
2. I've tried switching from JSON-RPC (on s1.ripple.com) to websockets (on xrpl.ws), and it didn't make any difference. (Please don't say 'run your own node', I'm trying to keep this lightweight...!)
3. I've also tried consolidating multiple calls into a single websocket client session, and it doesn't seem to make any difference.
4. As best I can tell it's not a network latency thing; the calls seem to be equally slow whether the code is running on my laptop or in AWS us-west-2.

(As a side note, I ran into an odd bug in xrpl-py while I was testing this - some bookOffers calls that work through the JSON-RPC client stopped working when I switched to websockets. If you're finding that bookOffers is throwing weird type errors, try not using the 'value' field in your issuedCurrency objects.)

 

I am not familiar with the python client, but what you normally should do is, create a transaction with specific sequence number, in parallel you can create other transactions with higher sequence number - i.e. as many as you want as long as your sequence numbers are increasing and show no gaps. The ledger will sort it out and order your transactions according to sequence numbers.

You will normally first receive a response on each transaction if it has been received by the node (and you can do many in parallel). A separate next step is to check if the transaction is included in a ledger (takes +/- 3/4 seconds), but you do not have to wait for that. What I suspect is that the python API or the function that you are using is actually waiting for these last calls. That can be the right thing to do if you want to be sure your transaction is included and hence final, but in case of trading and adding orders to the order books, this is not what you want. 

It should not matter if you use websockets or RPC.

[tulo]

I'm not used to the py library, but there is something wrong if a call takes 3-10 seconds.

What you can do is:

• Make multiple calls in parallel and wait for them all at once, so the longest call will limit the overall time, but you won't have to wait for them sequentially.
• Run your own node. I know you wrote you won't do it, but for a commercial application is a must. You can keep an external node now for testing but you won't have any control on the answer time and there is a rate limiter.
• As far as you can you can try the "subscribe" with websocket instead of making REST calls. In that way you'll have a "continuous" stream of information you can parse and it's much faster than REST calls.
• Check if the bottleneck is in the py library (which is not maintained AFAIK).

Edited August 27, 2022 by tulo

[tulo]

Tested now on s1.ripple.com making 3 calls in parallel with JS library. To return them all it took an average of 600-800ms and I'm not phisically located near the server.

So it's something wrong in your code or the library.

The same calls on a local node in the same network take 1-10ms.

Edited August 27, 2022 by tulo

[MicrophoneGuy]

Thanks folks! I'll give a few of those ideas a try, and I'll report back if I find a solution. 

[MicrophoneGuy]

Just dropping back in to say @tulo, you nailed it. My runtime with four calls to the ledger has dropped from two-and-a-half seconds to less than half a second consistently sub-150msec.

For anyone who runs across this thread in future: the xrpl-py library in synchronous mode is way slower than in asynchronous mode; you'll want to use the asynchronous clients and wrap everything up in asyncio instead.

Edited October 8, 2022 by MicrophoneGuy