5 ms·

> Removing the dependency is just one part of the story. Another part is that requests per second under heavy load increased from ~400 to ~850! Also, all those

> Removing the dependency is just one part of the story. Another part is that requests per second under heavy load increased from ~400 to ~850! Also, all those weird errors were gone – using BoltDB with 10k concurrent users we get zero errors. Not exactly surprising. Redis is single threaded so if you will need to spawn multiple instances if you want to satisfy all cores. Which is what I assume is happening here.

antirez 11y ago
I'm not sure what the user did with Redis, but it's unlikely that you can saturate a core with, like, 1000 requests/sec unless you do complex/slow operation. But apparently the OP was just doing simple ops because otherwise the switch to BoltDB could be impossible or harder. So I guess there is something to dig to understand what was happening. The most likely cause is the execution of many fast commands in Redis without a pipeline, so that all the time was burn in RTTs. EDIT: Anyway for my programming philosophy, what the OP did, regardless of performances, totally makes sense. I think easy to use and deploy is a key value in software ;-)
- ploxiln 11y ago
  There can often be issues with managing pools of tcp connections in clients - locking around accessing the pool, corner cases in state/lifetime of a connection in the pool, etc. In my experience with other databases and languages anyway.
- andrewguenther 11y ago
  I just did some digging on their Github, for every captured HTTP request there is one Redis/Bolt op and for every replay there is one get Redis/Bolt op. You should be able to pipeline the recording, but likely not the get operations.
Loic 11y ago
I am using BoltDB in production. BoltDB is wonderful for mostly read operations, if you perform a lot of read/write operations, Redis will at the end be better because of the B-tree of BoltDB and the way the pages are handled (the author and the docs do not hide this, heavy read is the use case). What I take from his post is that his software was nicely designed to be able to easily change the backend which will allow him to easily switch back to Redis in the future when he will get corruption from BoltDB because of the intensive read/write which is not the use case.
- deforciant 11y ago
  In case of Hoverfly, it never needs read/write operations, it only writes during "capture" mode and then only reads during "virtualize" mode and that's when performance really counts, so it looks like a perfect solution.
- ddorian43 11y ago
  BoltDB is based on LMDB which is supposed to never be corrupted, so if they based it right they'll be fine.
  - justin66 11y ago
    They share no code at all.
    - benbjohnson 11y ago
      The fundamental design of Bolt is the same as LMDB though. The premise behind why LMDB is "uncorruptable" is that all the dirty data pages for a transaction are written out first followed by a write to a double-buffered meta page that points to the new root of the B+tree. If any data page is partially written then it doesn't matter because the new meta page hasn't been written to point to it. If the new meta page is partially written then it is detected through a checksum and the previous meta page is used (thereby rolling back the transaction). That's how Bolt works as well. That being said, all code has bugs (yes, even LMDB). Bolt has a large amount of test coverage as well as randomized black box testing that it uses to help minimize those bugs.
      - justin66 11y ago
        That's a really good explanation of the db's function, thanks. Are you guys still single process? That killed a few pretty important lmdb use cases. I've always been curious why you did that.
      - Loic 11y ago
        The corruption I was talking about is this one: https://github.com/boltdb/bolt/issues/348 https://github.com/boltdb/bolt/issues/348

antirez 11y ago

I'm not sure what the user did with Redis, but it's unlikely that you can saturate a core with, like, 1000 requests/sec unless you do complex/slow operation. But apparently the OP was just doing simple ops because otherwise the switch to BoltDB could be impossible or harder. So I guess there is something to dig to understand what was happening. The most likely cause is the execution of many fast commands in Redis without a pipeline, so that all the time was burn in RTTs. EDIT: Anyway for my programming philosophy, what the OP did, regardless of performances, totally makes sense. I think easy to use and deploy is a key value in software ;-)

ploxiln 11y ago
There can often be issues with managing pools of tcp connections in clients - locking around accessing the pool, corner cases in state/lifetime of a connection in the pool, etc. In my experience with other databases and languages anyway.
andrewguenther 11y ago
I just did some digging on their Github, for every captured HTTP request there is one Redis/Bolt op and for every replay there is one get Redis/Bolt op. You should be able to pipeline the recording, but likely not the get operations.

Loic 11y ago

I am using BoltDB in production. BoltDB is wonderful for mostly read operations, if you perform a lot of read/write operations, Redis will at the end be better because of the B-tree of BoltDB and the way the pages are handled (the author and the docs do not hide this, heavy read is the use case). What I take from his post is that his software was nicely designed to be able to easily change the backend which will allow him to easily switch back to Redis in the future when he will get corruption from BoltDB because of the intensive read/write which is not the use case.

deforciant 11y ago
In case of Hoverfly, it never needs read/write operations, it only writes during "capture" mode and then only reads during "virtualize" mode and that's when performance really counts, so it looks like a perfect solution.
ddorian43 11y ago
BoltDB is based on LMDB which is supposed to never be corrupted, so if they based it right they'll be fine.
- justin66 11y ago
  They share no code at all.
  - benbjohnson 11y ago
    The fundamental design of Bolt is the same as LMDB though. The premise behind why LMDB is "uncorruptable" is that all the dirty data pages for a transaction are written out first followed by a write to a double-buffered meta page that points to the new root of the B+tree. If any data page is partially written then it doesn't matter because the new meta page hasn't been written to point to it. If the new meta page is partially written then it is detected through a checksum and the previous meta page is used (thereby rolling back the transaction). That's how Bolt works as well. That being said, all code has bugs (yes, even LMDB). Bolt has a large amount of test coverage as well as randomized black box testing that it uses to help minimize those bugs.
    - justin66 11y ago
      That's a really good explanation of the db's function, thanks. Are you guys still single process? That killed a few pretty important lmdb use cases. I've always been curious why you did that.
    - Loic 11y ago
      The corruption I was talking about is this one: https://github.com/boltdb/bolt/issues/348 https://github.com/boltdb/bolt/issues/348