When it doesn't matter how fast is your RPC

Let's see an example of why is important to read the documentation of your RPC. In this post I'll analyze why interacting with Kamino Finance UX is really painful, mainly because of their poor use of the RPC calls. Nothing against the UI, is actually cool, and personally I like Kamino Finance. Is just that every time I have to open the application, in the browser and the phone, I have to wait an absurd amount of time in order to interact with it.

Even though the example is with Kamino Finance, is not the only one that make bad use of RPC calls. Is just the one I'll take as example to explain why is important to read the documentation. For example Pumpfun makes 66 calls to getLatestBlockhash when loading the landing page, Jupiter Vote makes 16 getAccountInfo instead of a single getMultipleAccounts, etc...

TL;DR

In general everything can be resumed in read the RPC documentation, if you see yourself performing 100 getAccountInfo maybe you should use getMultipleAccounts.

Kamino Finance

Recently I've been using Kamino Finance, mainly because I wanted to write a liquidator bot. During this development I've been entering Kamino Landing webpage so many times, and so many time getting my pacience to the limit. Is so slow, that even the clean design they have doesn't compensate the time you have to wait just for make a first click. As a developer with curiosity I wanted to know what's going on there, why took so much time to interact with their application. First step running Lighthouse on their website, the performance score is so poor basically 2 points out of 100.

lighthouse performance

According to lighthourse report, the First Contentful Paint took 64.3 seconds, with a total blocking time of 12440 ms basically 12 seconds. That's not okay, and specially for an application that deals with money, and with positions getting liquidated. Now, given that I do like Kamino I took the time to look why it takes them so much time serving that first contentful paint.

Landing Page

This is a HAR file taken from a load of the Landing Page, you can get a file like this very easy from the Developer console of your browser while loading a website.

HAR file

Looking into this HAR file I noticed several getAccountInfo requests to their RPC provider, when I looked in detail about these requests this is what I found out.

  • 41 getAccountInfo requests for the account Fi8vncGpNKbq62gPo56G4toCehWNy77GgqGkTaAF5Lkk

Why?? Why on hell do you need to make 41 getAccountInfo of the exact same account? It just doesn't makes sense, the worst is that all of them are made one after another according to the HAR file records.

41 gAI

The timelapsed between these requests are milliseconds.

  • Another 22 getAccountInfo requests for the account 3NJYftD5sjVfxSnUdZ1wVML8f3aC6mp1CXCL6L7TnU8C

Same case as before just with a different account.

  • Empty getMultipleAccounts

The next case that break my brain, are 22 requests to getMultipleAccounts with an empty list of accounts. You can check that with the following command against he HAR file.

ag "getMultipleAccounts.*?\[\]" app.kamino.finance.har |  cut -d '"' -f25 | cut -d '\' -f1 | uniq | wc

empty gMA

These are 22 requests that are completely unnecessary given that you know the RPC won't return you anything. This translate into the user waiting for you to make this stupid requests, from where you will get a single useful data.

  • 106 getAccountInfo in total

In total Kamino makes, just loading landing page, 106 getAccountInfo requests from which 41 are for this account Fi8vncGpNKbq62gPo56G4toCehWNy77GgqGkTaAF5Lkk, and 22 from second case which leaves 43 extra getAccountInfo. All these requests can be summarized in 2 getMultipleAccounts, given that getMultipleAccounts allows a maximum of 100 accounts. Even if your amazing logic requires you to make those first two cases, why wouldn't you make a getMultipleAccounts request for the rest? Instead of making getMultipleAccounts with an empty list of accounts.

Markets page

With the Markets page is most of the same, a bunch of getAccountInfo that can be resumed in a single getMultipleAccounts.

HAR file

  • 34 getAccountInfo

Same cases as before, 34 unique getAccountInfo which can resume in a single getMultipleAccounts.