Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cherokee: users

Performance test data and likely memory leak: 0.54 for Windows

 

 

Cherokee users RSS feed   Index | Next | Previous | View Threaded


jlist9 at gmail

May 2, 2008, 8:58 AM

Post #1 of 5 (338 views)
Permalink
Performance test data and likely memory leak: 0.54 for Windows

Since I didn't have much experience with Cherokee, I did some (brutal)
apache ab testing last night with 0.54 Windows version.

The good news is, Cherokee completed one million static requests and
one million scgi dynamic requests in about 3 hours, most successfully.
5 requests failed to connect in each group, I'm not sure about the
reason. Two ab commands started at about the same time. see detailed
data below.

The test also seems to have revealed a memory leak. When the test was
done, cherokee process took about 100MB memory (it started with
2.5MB.) I wasn't sure if the leak was from static requests or dynamic
requests. So I re-did 10,000 request with a static page, and didn't
observe memory leak. In the dynamic page tests, memory usage kept
growing, at the speed of around 100 bytes per request. When the load
stopped, the memory didn't get released.

Not sure if this has also been observed on Linux?

The scgi performance was quite impressive. I'm not sure about the
details of Cherokee's scgi and fcgi implementation. In my testing, a
multi-threaded scgi back-end written in Python was much faster
handling concurrent requests than a single-threaded fcgi backend
written in a compiled language, when the number of concurrent requests
was more than 5. But dealing with continuous but non-concurrent
requests, the natively compiled fastcgi takes about 40% of the time of
what it takes the scgi Python app to handle a request. This tells me
that the Python scgi backend (web.py) is able to cope with pretty
heavy traffic, which will be a bit less than half of the ultimate
capacity that could be achieved by running a server pool of
fastcgi/scgi written in a compiled language. (I'm assuming the
overhead of fcgi and scgi are similar, or the difference ignorable.)

The test is done on a single-CPU vmware guest OS running on a powerful
core 2 dual host. It was taking most CPU time of a core during the
test. No other vms or heavy tasks were run during the tests.

C:\Internet>ab -n 1000000 -c 1 http://localhost/image/google.html

Server Software: Cherokee/0.5.4
Server Hostname: localhost
Server Port: 80

Document Path: /image/static.html
Document Length: 67859 bytes

Concurrency Level: 1
Time taken for tests: 6012.703125 seconds
Complete requests: 1000000
Failed requests: 5
(Connect: 5, Length: 0, Exceptions: 0)
Write errors: 0
Total transferred: -681476736 bytes
HTML transferred: -860476736 bytes
Requests per second: 166.31 [#/sec] (mean)
Time per request: 6.013 [ms] (mean)
Time per request: 6.013 [ms] (mean, across all concurrent requests)
Transfer rate: -110.68 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 12.0 0 3015
Processing: 0 2 6.1 0 203
Waiting: 0 0 3.0 0 156
Total: 0 4 13.2 0 3046

Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 15
80% 15
90% 15
95% 15
98% 15
99% 15
100% 3046 (longest request)



C:\Internet>ab -n 1000000 -c 1 http://localhost/s/scgi/

Benchmarking localhost (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Finished 1000000 requests


Server Software: Cherokee/0.5.4
Server Hostname: localhost
Server Port: 80

Document Path: /s/scgi/
Document Length: 693 bytes

Concurrency Level: 1
Time taken for tests: 8875.62500 seconds
Complete requests: 1000000
Failed requests: 5
(Connect: 5, Length: 0, Exceptions: 0)
Write errors: 0
Total transferred: 803000000 bytes
HTML transferred: 693000000 bytes
Requests per second: 112.68 [#/sec] (mean)
Time per request: 8.875 [ms] (mean)
Time per request: 8.875 [ms] (mean, across all concurrent requests)
Transfer rate: 88.36 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 6.9 0 2984
Processing: 0 8 8.1 15 281
Waiting: 0 7 8.0 0 281
Total: 0 8 10.5 15 3031

Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 15
95% 15
98% 15
99% 31
100% 3031 (longest request)
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee


skinkie at xs4all

May 2, 2008, 9:17 AM

Post #2 of 5 (326 views)
Permalink
Re: Performance test data and likely memory leak: 0.54 for Windows [In reply to]

On Fri, 2 May 2008, Jack wrote:

> The test also seems to have revealed a memory leak. When the test was
> done, cherokee process took about 100MB memory (it started with
> 2.5MB.) I wasn't sure if the leak was from static requests or dynamic
> requests. So I re-did 10,000 request with a static page, and didn't
> observe memory leak. In the dynamic page tests, memory usage kept
> growing, at the speed of around 100 bytes per request. When the load
> stopped, the memory didn't get released.

VERY GOOD! I'm happy you found it! I think this accounts for my previous
problems too.

> Not sure if this has also been observed on Linux?

Yes, under Linux this was also found. I only don't know if it was a
memoryleak resulting in high load (due to swapping) or something else.


Stefan

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee


alvaro at gnu

May 2, 2008, 8:27 PM

Post #3 of 5 (322 views)
Permalink
Re: Performance test data and likely memory leak: 0.54 for Windows [In reply to]

On 2 May 2008, at 18:17, Stefan de Konink wrote:
> On Fri, 2 May 2008, Jack wrote:
>
>> The test also seems to have revealed a memory leak. When the test was
>> done, cherokee process took about 100MB memory (it started with
>> 2.5MB.) I wasn't sure if the leak was from static requests or dynamic
>> requests. So I re-did 10,000 request with a static page, and didn't
>> observe memory leak. In the dynamic page tests, memory usage kept
>> growing, at the speed of around 100 bytes per request. When the load
>> stopped, the memory didn't get released.
>
> VERY GOOD! I'm happy you found it! I think this accounts for my
> previous
> problems too.
>
>> Not sure if this has also been observed on Linux?
>
> Yes, under Linux this was also found. I only don't know if it was a
> memoryleak resulting in high load (due to swapping) or something else.

This is the first notice I have got about this.. I'm checking it right
away.

Thanks for reporting Jack!!

--
Greetings, alo.
http://www.alobbs.com/

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee


alvaro at sun

May 3, 2008, 2:07 PM

Post #4 of 5 (310 views)
Permalink
Re: Performance test data and likely memory leak: 0.54 for Windows [In reply to]

On 3 May 2008, at 05:27, Alvaro Lopez Ortega wrote:
> On 2 May 2008, at 18:17, Stefan de Konink wrote:
>> On Fri, 2 May 2008, Jack wrote:
>>
>>> The test also seems to have revealed a memory leak. When the test
>>> was
>>> done, cherokee process took about 100MB memory (it started with
>>> 2.5MB.) I wasn't sure if the leak was from static requests or
>>> dynamic
>>> requests. So I re-did 10,000 request with a static page, and didn't
>>> observe memory leak. In the dynamic page tests, memory usage kept
>>> growing, at the speed of around 100 bytes per request. When the load
>>> stopped, the memory didn't get released.
>>
>> VERY GOOD! I'm happy you found it! I think this accounts for my
>> previous
>> problems too.
>>
>>> Not sure if this has also been observed on Linux?
>>
>> Yes, under Linux this was also found. I only don't know if it was a
>> memoryleak resulting in high load (due to swapping) or something
>> else.
>
> This is the first notice I have got about this.. I'm checking it
> right away.

Could you please guys give more details on how to reproduce it? I have
tried to reproduce this but I haven't succeeded. The only leak I have
found was a 16 bytes long buffer that was unreferred during the server
initialization.

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee


adefacc at tin

May 3, 2008, 2:20 PM

Post #5 of 5 (308 views)
Permalink
Re: Performance test data and likely memory leak: 0.54for Windows [In reply to]

Stefan de Konink wrote:
>
> On Fri, 2 May 2008, Jack wrote:
>
> > The test also seems to have revealed a memory leak. When the test was
> > done, cherokee process took about 100MB memory (it started with
> > 2.5MB.) I wasn't sure if the leak was from static requests or dynamic
> > requests. So I re-did 10,000 request with a static page, and didn't
> > observe memory leak. In the dynamic page tests, memory usage kept
> > growing, at the speed of around 100 bytes per request. When the load
> > stopped, the memory didn't get released.
>
> VERY GOOD! I'm happy you found it! I think this accounts for my previous
> problems too.
>
> > Not sure if this has also been observed on Linux?
>
> Yes, under Linux this was also found. I only don't know if it was a
> memoryleak resulting in high load (due to swapping) or something else.

OK, but version 0.5.4 is a bit stale to perform meaningful tests on it.

Doing them on last 0.6.x o trunk 0.7 would be much more appreciated.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

Cherokee users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.