<p>I'm pretty sure you're observing the disk cache. When you call <code>getrawtransaction</code>, Bitcoin Core first needs to check the transaction index (enabled by <code>-txindex</code>) and then load the transaction from its <code>blk*.dat</code> file (and <code>rev*.dat</code> file if you're also requesting prevouts), all of which are operations that access the disk. As far as I know, Bitcoin Core itself doesn't have a cache that would help in this situation.</p>
<p>Side note, if you want to process the entire blockchain with an external program, I'd recommend using <code>getblock</code> instead of <code>getrawtransaction</code>.</p>

CC BY-SA 4.0
2023-10-23T14:36:10.163Z
The database system Bitcoin Core uses for the txindex is LevelDB, which does have a small in-memory cache in user space. Still, I'd expect that the majority of what OP is observing is indeed the operating system's disk cache.
Pieter Wuille
CC BY-SA 4.0
2023-10-24T08:44:10.170Z
Thank you very much for your answer! The disk cache theory makes sense, and I noted your advice about `getblock`.
Lev
CC BY-SA 4.0
2023-10-24T13:33:15.987Z
@vojtěch-strnad just to let you know that using `getblock` and parsing the transactions from there, instead of using `getrawtransaction`, has divided the time of my program by 3. Many thanks again!
Lev
CC BY-SA 4.0
2023-10-23T14:34:39.503Z
2023-10-23T14:34:39.503Z
Vojtěch Strnad
<p>I am currently working on a script that parses every BTC transaction from the beginning of the blockchain. My goal is to record summaries about each transaction in database, after synthesizing it.</p>
<p>While working on this, I observed that the first time I am using <code>getrawtransaction</code>, for 1000 transactions (i.e., 1000 RPCs), it takes between 20 and 30 seconds.</p>
<p>The second time I do the RPCs, for the same 1000 transactions, it takes less than 1 second.</p>
<p>My conclusion is that there is some caching mechanism set up, somewhere. I do not know if it is caching at the OS layer or at the software layer, though, and cannot manage to find any documentation on this.
Incidentally, I would like to be able to manage this mechanism to allow me to make requests more quickly.</p>
<p>Does anyone have an idea?</p>
<p>Thank you very much.</p>

<json-rpc><cache><getrawtransaction>
Is there a cache mechanism with getrawtransaction?
Lev
# Is there a cache mechanism with getrawtransaction?

(Asked by: username_0 on 2023-10-23)

I am currently working on a script that parses every BTC transaction from the beginning of the blockchain. My goal is to record summaries about each transaction in database, after synthesizing it.

While working on this, I observed that the first time I am using `getrawtransaction`, for 1000 transactions (i.e., 1000 RPCs), it takes between 20 and 30 seconds.

The second time I do the RPCs, for the same 1000 transactions, it takes less than 1 second.

My conclusion is that there is some caching mechanism set up, somewhere. I do not know if it is caching at the OS layer or at the software layer, though, and cannot manage to find any documentation on this.
Incidentally, I would like to be able to manage this mechanism to allow me to make requests more quickly.

Does anyone have an idea?

Thank you very much.

**Tags:** json-rpc, cache, getrawtransaction


---

## 1 answers

### Answer by username_1 on 2023-10-23. Score: 4 | Accepted answer

I'm pretty sure you're observing the disk cache. When you call `getrawtransaction`, Bitcoin Core first needs to check the transaction index (enabled by `-txindex`) and then load the transaction from its `blk*.dat` file (and `rev*.dat` file if you're also requesting prevouts), all of which are operations that access the disk. As far as I know, Bitcoin Core itself doesn't have a cache that would help in this situation.

Side note, if you want to process the entire blockchain with an external program, I'd recommend using `getblock` instead of `getrawtransaction`.

> **Comments:**
> **username_2**: The database system Bitcoin Core uses for the txindex is LevelDB, which does have a small in-memory cache in user space. Still, I'd expect that the majority of what OP is observing is indeed the operating system's disk cache.  
> **username_0**: Thank you very much for your answer! The disk cache theory makes sense, and I noted your advice about `getblock`.  
> **username_0**: @username_1-username_1 just to let you know that using `getblock` and parsing the transactions from there, instead of using `getrawtransaction`, has divided the time of my program by 3. Many thanks again!  

---

