couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <...@kowalski.gd>
Subject CouchDB got 100% slower in the past 3 weeks
Date Sun, 30 Aug 2015 21:15:14 GMT
Hi list,

I got pinged as our friends from PouchDB notices that their testsuite
with CouchDB 2 as a backend suddenly takes 100% longer (20mins instead
of 10). [1] Because the diff was so significant I got really curious
and worried about it.

This testsuite just took 10min

https://travis-ci.org/pouchdb/pouchdb/jobs/74585676 (22 days old)

vs

https://travis-ci.org/pouchdb/pouchdb/jobs/77865796 (yesterday)

which took like the other runs these days 20min.

I wasn't really sure, maybe the travis VMs changed. Or Pouch.

Based on the report I created a few flamegraphs to poke around what
changed in CouchDBs internals. They look quite different to the ones I
created in the past weeks:

https://dl.dropboxusercontent.com/u/1809262/flame-couch-epi-update-doc.svg

this flamegraphs shows the update of a doc. couch-epi takes 33% of the
time and blocks.

https://dl.dropboxusercontent.com/u/1809262/flame-epi.svg

in this flamegraph I receive a document. I have 3 blocking calls to
couch_epi, adding up to 21% time of the request.

The report from Nolan (perf decrease of 100% in a timeframe from 3
weeks) fits into the timeframe where we added couch_epi. As almost
every module uses couch_epi the performance decrease of almost all
APIs also fits into the scheme. And I think the flamegraphs show that
the additional time is spent in couch_epi.


- I see that couch_epi uses the codeserver internally, would it be
possible to use faster ETS tables?
- Anything else we could do?

Best,
Robert

[1] https://github.com/pouchdb/pouchdb/issues/4209#issuecomment-135964232

Mime
View raw message