4 ms·

Looks very promising! We've looked at Cockroach for a particular project, and we've been concerned that performance wasn't good enough. Cockroach performance s

Looks very promising! We've looked at Cockroach for a particular project, and we've been concerned that performance wasn't good enough. Cockroach performance seems to scale linearly, but single-connection performance, especially for small transactions, seems rather dismal. Some casual stress testing against a 3-node cluster on Kubernetes showed that small transactions modifying a single row could take as much as 7-8 seconds, where Postgres would take just a few milliseconds. The documentation recommends that you batch as many updates as possible, but obviously that doesn't work for low-latency applications like web frontends that need to be able to do small, fine-grained modifications.

tyingq 9y ago
" small transactions modifying a single row could take as much as 7-8 seconds" That's surprising. I wasn't expecting CockroachDB to be really fast, given the constraints they work within. But that sounds more like a bug or config error. Unless perhaps you mean a really high number of processes trying to update the same row at the same time? Like a global counter or something?
- lobster_johnson 9y ago
  Indeed, the stress test updates just one row, which mirrors certain write patterns in our application. I just started this testing, so we'll see what happens when I extend it to more than one row.
jetrink 9y ago
7-8 seconds seems extremely long. Human beings performing the raft consensus algorithm using paper and pencil over Skype wouldn't be much slower than that. Are you sure everything was working correctly?
- lacker 9y ago
  I don't know about you, but it would take me a lot longer than 7 seconds to perform the raft consensus algorithm with paper and pencil.
  - deleted 9y ago
    [deleted]
  - danicgross 9y ago
    Who are you to judge? Did you win the Putnam or something?
    - Gigablah 9y ago
      I think people are generally allowed to judge themselves without industry credentials...
      - ComputerGuru 9y ago
        That was tongue-in-cheek (that still had no business on HN), a reference to @lacker's two Putnam awards.
        grzm 9y ago
        The Putnam is also the source of one of the best burns on HN: https://news.ycombinator.com/item?id=35079 https://news.ycombinator.com/item?id=35079
jnordwick 9y ago
> low-latency applications like web frontends ...
- zzzcpan 9y ago
  Poor UI choices these days do not provide feedback and reload, hence making low-latency necessary to even be tolerated by users.
- atombender 9y ago
  We have a collaborative, Google Docs-like application that currently issues a write every time someone types into a text field. Now, clearly it's suboptimal and something that should be optimized to batch the updates, but on the other hand, with Postgres we've had zero incentive to make such an optimization, because it's able to handle thousands of writes per node in real time with no queuing happening on the client. I don't expect this from Cockroach, but I would definitely want low latency.
  - thanatos_dem 9y ago
    Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right. Have you explored implementing a CRDT based solution like WOOT instead?
    - Groxx 9y ago
      Why write conflicts? Contention, sure, but contention isn't an issue until you have literal tons of it.
      - thanatos_dem 9y ago
        From OP's description > issues a write every time someone types into a text field With more than a handful of people, this is getting into conflict territory pretty rapidly, especially if the document is structured as a single row (hopefully it's more granular than that). Time for some back of the envelope maths: Assuming that an average person types at around 200 words per minute (number pulled from https://www.livechatinc.com/typing-speed-test/#/ https://www.livechatinc.com/typing-speed-test/#/), that's a character every 300ms on average. With 10 people editing the document, that's a character every 30ms on average, which can easily lead to conflicts if they're all trying to update the same resource.
welder 9y ago
Did you use the 2.0 beta version or the latest stable release? They improved performance a lot in the 2.0 beta released this month.
- lobster_johnson 9y ago
  I used 1.1.6. Looking forward to testing 2.0.
thanatos_dem 9y ago
7-8 seconds? Something definitely sounds misconfigured. I've been running a 1.1.x cluster for quite a while and I've never seen a single row transaction take that long. And even the slowest queries took at most ~500ms, and that was with: - Replication factor increased to 5x (rather than the 3x default) - 8 indexes on the table being modified which also needed to be updated - Nodes spread across North America, incurring higher RTT latency between nodes - Relatively high contention on the data triggering client-side retries - HDD's as the storage medium (RockDB is optimized for SSDs)
orangechairs 9y ago
[cockroach employee here] Have you hit us up on Gitter or Stack Overflow to help debug and tune? We'd also love to learn more about how you're using K8s, what your setup looks like, surprises you're running into with it, etc.
- lobster_johnson 9y ago
  Thanks, I'll do that when I get back to testing.

tyingq 9y ago

" small transactions modifying a single row could take as much as 7-8 seconds" That's surprising. I wasn't expecting CockroachDB to be really fast, given the constraints they work within. But that sounds more like a bug or config error. Unless perhaps you mean a really high number of processes trying to update the same row at the same time? Like a global counter or something?

lobster_johnson 9y ago
Indeed, the stress test updates just one row, which mirrors certain write patterns in our application. I just started this testing, so we'll see what happens when I extend it to more than one row.

jetrink 9y ago

7-8 seconds seems extremely long. Human beings performing the raft consensus algorithm using paper and pencil over Skype wouldn't be much slower than that. Are you sure everything was working correctly?

lacker 9y ago
I don't know about you, but it would take me a lot longer than 7 seconds to perform the raft consensus algorithm with paper and pencil.
- deleted 9y ago
  [deleted]
- danicgross 9y ago
  Who are you to judge? Did you win the Putnam or something?
  - Gigablah 9y ago
    I think people are generally allowed to judge themselves without industry credentials...
    - ComputerGuru 9y ago
      That was tongue-in-cheek (that still had no business on HN), a reference to @lacker's two Putnam awards.
      - grzm 9y ago
        The Putnam is also the source of one of the best burns on HN: https://news.ycombinator.com/item?id=35079 https://news.ycombinator.com/item?id=35079

jnordwick 9y ago

> low-latency applications like web frontends ...

zzzcpan 9y ago
Poor UI choices these days do not provide feedback and reload, hence making low-latency necessary to even be tolerated by users.
atombender 9y ago
We have a collaborative, Google Docs-like application that currently issues a write every time someone types into a text field. Now, clearly it's suboptimal and something that should be optimized to batch the updates, but on the other hand, with Postgres we've had zero incentive to make such an optimization, because it's able to handle thousands of writes per node in real time with no queuing happening on the client. I don't expect this from Cockroach, but I would definitely want low latency.
- thanatos_dem 9y ago
  Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right. Have you explored implementing a CRDT based solution like WOOT instead?
  - Groxx 9y ago
    Why write conflicts? Contention, sure, but contention isn't an issue until you have literal tons of it.
    - thanatos_dem 9y ago
      From OP's description > issues a write every time someone types into a text field With more than a handful of people, this is getting into conflict territory pretty rapidly, especially if the document is structured as a single row (hopefully it's more granular than that). Time for some back of the envelope maths: Assuming that an average person types at around 200 words per minute (number pulled from https://www.livechatinc.com/typing-speed-test/#/ https://www.livechatinc.com/typing-speed-test/#/), that's a character every 300ms on average. With 10 people editing the document, that's a character every 30ms on average, which can easily lead to conflicts if they're all trying to update the same resource.

welder 9y ago

Did you use the 2.0 beta version or the latest stable release? They improved performance a lot in the 2.0 beta released this month.

lobster_johnson 9y ago
I used 1.1.6. Looking forward to testing 2.0.

thanatos_dem 9y ago

7-8 seconds? Something definitely sounds misconfigured. I've been running a 1.1.x cluster for quite a while and I've never seen a single row transaction take that long. And even the slowest queries took at most ~500ms, and that was with: - Replication factor increased to 5x (rather than the 3x default) - 8 indexes on the table being modified which also needed to be updated - Nodes spread across North America, incurring higher RTT latency between nodes - Relatively high contention on the data triggering client-side retries - HDD's as the storage medium (RockDB is optimized for SSDs)

orangechairs 9y ago

[cockroach employee here] Have you hit us up on Gitter or Stack Overflow to help debug and tune? We'd also love to learn more about how you're using K8s, what your setup looks like, surprises you're running into with it, etc.

lobster_johnson 9y ago
Thanks, I'll do that when I get back to testing.