incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sajeesh P N" <sajees...@tataelxsi.co.in>
Subject Re: Queries on CouchDB tests done using Tsung
Date Tue, 03 May 2011 11:53:23 GMT
I already tried increasing max_connections to 4096, but still errors are 
coming after a certain request rate. The max open files in Couchdb server 
system is just 1024. Should we have to increase this value ?

How do we increase the ERL_MAX_PORTS ? If we set this env variable, do we 
need to set it again for every couchdb restart ? How to see the existing 
configuration values?

Thanks,
Sajeesh

----- Original Message ----- 
From: "Sebastian Cohnen" <sebastiancohnen@googlemail.com>
To: <user@couchdb.apache.org>
Sent: Tuesday, May 03, 2011 3:42 PM
Subject: Re: Queries on CouchDB tests done using Tsung


You could try

[httpd]
max_connections = 2048

Also you could try to increase ERL_MAX_PORTS

On 03.05.2011, at 12:03, Sajeesh P N wrote:

> Do we need to increase the max connections configuration in Couchdb to 
> increase the no. of requests it can handle. I have 3 Tsung clients, should 
> I have to do any system related configurations in Couchdb like max open 
> files??
>
> I am facing a problem like, even though I used 3 tsung clients or 1 
> client, the max no. of requests to Couchdb is around 1000 per sec. I could 
> not increase it further... and getting CouchDB errors like ("mochiweb 
> socket server .... acceptor error... accept failed"). Do you have any idea 
> about this ?
>
> Thanks,
> Sajeesh
>
> ----- Original Message ----- From: "Sebastian Cohnen" 
> <sebastiancohnen@googlemail.com>
> To: <user@couchdb.apache.org>
> Sent: Tuesday, May 03, 2011 3:06 PM
> Subject: Re: Queries on CouchDB tests done using Tsung
>
>
> I'm currently doing some performance analysis/engineering for a customer 
> of mine using tsung (not benchmarking couchdb though). To generate load in 
> this magnitude reliably you'll need either more machines generating the 
> load, or doing more requests in each session (even if they are all the 
> same). Using more requests per session vs one request per session has 
> proven to work for me much better - especially when the response time per 
> request is low.
>
> You should specify you scenarios according to your usage patterns (e.g. 
> read/write ratio, accessing views etc.). Simply hammering on reading docs 
> e.g. is probably not very meaningful for a real world application.
>
> Another thing you should consider is using a proxy/http accelerator like 
> varnish to serve cacheable resources.
>
> On 03.05.2011, at 10:31, Sajeesh P N wrote:
>
>> Thanks. I am reading different documents in Couchdb as my requests. My 
>> aim is to get like 1000, 2000, 3000 ... requests per sec handled by 
>> CouchDB and reported in Tsung. Is it necessary to have more clients in 
>> Tsung to generate more requests/sec or have more requests per session for 
>> one tsung client.
>>
>> Thanks in advance,
>> Sajeesh
>>
>> ----- Original Message ----- From: "Sebastian Cohnen" 
>> <sebastiancohnen@googlemail.com>
>> To: <user@couchdb.apache.org>
>> Sent: Tuesday, May 03, 2011 1:54 PM
>> Subject: Re: Queries on CouchDB tests done using Tsung
>>
>>
>> Hey,
>>
>> On 03.05.2011, at 09:52, Sajeesh P N wrote:
>>
>>> Hi,
>>>
>>> I am presently doing CouchDB performance tests using the Tsung tool 
>>> keeping the default configurations for CouchDB. I would like to get a 
>>> clarity on the following questions:-
>>>
>>> 1) For every requests queried from Tsung, whether CouchDB is creating a 
>>> new connection for each?
>>
>> The default for HTTP load testing in Tsung creates a new connection per 
>> request by default, IIRC. But it somehow depends on what you want to 
>> test.
>>
>>> 2) I would like to increase the no. of requests handled by CouchDB. What 
>>> configuration in Couchdb should I modify and how much should be the 
>>> value or limit?
>>
>> I'd say that's hard to answer per se. What kind of requests? Reading 
>> documents? Creating? Accessing views? ...
>>
>> If you could elaborate a bit more on what you want to test/benchmark, it 
>> might be easier to answer.
>>
>>
>> Best
>>
>> Sebastian=
>>
>>
>
>
>




Mime
View raw message