couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Huw Selley <huw.sel...@netdev.co.uk>
Subject Read request throughput
Date Wed, 01 Dec 2010 11:30:50 GMT
Hi,

I have been doing some performance testing with couch and am hoping someone here will be able
to help me ascertain if/how I can get higher throughput.

Scenario:

I am trying to measure max couch throughput - for these tests im happy with just repeatedly
requesting the same document.
I have some reasonable boxes to perform these tests - they have dual quad core X5550 CPUs
with HyperThreading enabled and 24GB RAM.
These boxes have a stock install of oracle enterprise linux 5 on them (which is pretty much
RHEL5).
The oracle supplied erlang version is R12B5 and I am using couch 1.0.1 built from source.

The database is pretty small (just under 100K docs) and I am querying a view that includes
some other docs (the request contains include_docs=true) and using jmeter on another identical
box to generate the traffic.
The total amount of data returned from the request is 1467 bytes.
For all of my tests I capture system state using sadc and there is nothing else happening
on these boxes.

In my initial round of testing I found that I was only getting ~126 requests/s throughput
which surprised me somewhat. Looking at the generated graphs from the test run there were
plenty of resources to go round - the disk controller was nowhere near busy and neither was
the cpu.

Before coming here to question my findings I took a 3rd box (same spec) and built couch from
the tip of the 1.1.x branch (rev 1040477). After compiling couch and installing it I found
that it didn't start up (or log anything useful). After a bit of digging I figured it's probably
due to the age of the erlang version being used - I upgraded to OTP R14B and rebuilt couch
against it. This gave me a working install again.

I got an immediate throughput increase to ~500 requests/s which was nice but the data being
collected via sadc still showed that the cpu was at most 20% utilised and the disk controller
was doing next to nothing (I assume the OS cache already has the data requested so no trip
to disk required?)

At this point I started to wonder if jmeter is unable to send in enough requests to stress
couch so I started up another jmeter instance on another box and had it also send in requests
to couch. What i noticed was that the total throughput didn't increase - it was just split
over both jmeter instances.
This made me start to think maybe there is something going on in the erlang vm that's stopping
me getting higher throughput. Did some digging around and read this:

http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-and-SMP-td2108770.html

Granted the information is a bit stale but that post made me start thinking that maybe I am
seeing contention around the run-queue.
I see that in R14B I can pass the erlang vm the '+S N:N' flag to control the number of run-queues
and how many of them are active. I did a bit of tweaking and ended up getting 700 requests/s
by using '+S 16:2". I don't seem to be able to get any more than this though and the system
is still not really stressed - CPU is just under 20% and very little disk i/o.

Can anyone offer up any advice/suggestions on where to go next?

Thanks in advance
Huw
Mime
View raw message