Failed requests

[ngocdaothanh]

On Leopard, I run the "Quickstart", then:
ab -c 10 -n 1000 http://127.0.0.1:8000/web/samples

The result shows that there are failed requests. I don't know why
because there is no log. Does anybody know?

----------------------------------------
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software: inets/5.0.12
Server Hostname: 127.0.0.1
Server Port: 8000

Document Path: /web/samples
Document Length: 5963 bytes

Concurrency Level: 10
Time taken for tests: 6.128 seconds
Complete requests: 1000
Failed requests: 133
(Connect: 0, Receive: 0, Length: 133, Exceptions: 0)
Write errors: 0
Total transferred: 6239549 bytes
HTML transferred: 5955589 bytes
Requests per second: 163.18 [#/sec] (mean)
Time per request: 61.283 [ms] (mean)
Time per request: 6.128 [ms] (mean, across all concurrent
requests)
Transfer rate: 994.29 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.3 0 10
Processing: 45 60 4.7 60 92
Waiting: 45 60 4.6 60 91
Total: 45 61 4.5 60 92

Percentage of the requests served within a certain time (ms)
50% 60
66% 62
75% 63
80% 64
90% 67
95% 70
98% 73
99% 76
100% 92 (longest request)
----------------------------------------

Ngoc.

[ngocdaothanh]

Erlang R13A gives better results than R12B-5 (~2x), but there are
still failed requests.

Below are the results for Nitrogen on Inets, MochiWeb (I could not run
on Yaws) with Erlang R13A.

Ngoc.


Inets

----------
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: inets/5.0.13

Server Hostname: 127.0.0.1
Server Port: 8000

Document Path: /web/samples
Document Length: 5963 bytes

Concurrency Level: 10

Time taken for tests: 2.693 seconds
Complete requests: 1000
Failed requests: 79
(Connect: 0, Receive: 0, Length: 79, Exceptions: 0)
Write errors: 0
Total transferred: 6241379 bytes
HTML transferred: 5957392 bytes
Requests per second: 371.39 [#/sec] (mean)
Time per request: 26.926 [ms] (mean)
Time per request: 2.693 [ms] (mean, across all concurrent
requests)
Transfer rate: 2263.67 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max

Connect: 0 0 0.9 0 10
Processing: 7 26 10.9 26 77
Waiting: 6 26 10.9 25 74
Total: 8 27 10.9 26 77

Percentage of the requests served within a certain time (ms)

50% 26
66% 31
75% 35
80% 36
90% 41
95% 44
98% 50
99% 58
100% 77 (longest request)
----------


MochiWeb

----------
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: MochiWeb/1.0

Server Hostname: 127.0.0.1
Server Port: 8000

Document Path: /web/samples

Document Length: 5897 bytes

Concurrency Level: 10
Time taken for tests: 2.573 seconds
Complete requests: 1000
Failed requests: 920
(Connect: 0, Receive: 0, Length: 920, Exceptions: 0)
Write errors: 0
Total transferred: 6296562 bytes
HTML transferred: 5954572 bytes
Requests per second: 388.65 [#/sec] (mean)
Time per request: 25.730 [ms] (mean)
Time per request: 2.573 [ms] (mean, across all concurrent
requests)
Transfer rate: 2389.78 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max

Connect: 0 0 1.0 0 10
Processing: 5 25 9.0 25 57
Waiting: 5 25 9.0 25 54
Total: 6 26 9.0 26 57

Percentage of the requests served within a certain time (ms)

50% 26
66% 30
75% 32
80% 33
90% 38
95% 41
98% 44
99% 46
100% 57 (longest request)
----------

On Apr 13, 5:08 pm, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
> On Leopard, I run the "Quickstart", then:

> ab -c 10 -n 1000http://127.0.0.1:8000/web/samples

>
> The result shows that there are failed requests. I don't know why
> because there is no log. Does anybody know?
>
> ----------------------------------------
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>

> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
> Licensed to The Apache Software Foundation,http://www.apache.org/

[ll...@paisite.com]

Hi Ngoc,

You deserve a solid gold trophy and a kiss from Miss Universe for running these performance tests.

At some point it would be great if you could find time to publish in detail how you run these tests so others of us can run and publish our own. In this way as a community, perhaps, we can build up over time a comprehensive profile across various environments of how Nitrogen/web server performance stacks up against other frameworks, as well as provide rich empirical data for determining where and how Nitrogen/web server performance can be improved.

No doubt Nitrogen will continue to evolve and performance will, we'd hope, improve incrementally. On-going performance testing by the community would hasten this evolution, I believe, and provide early warning when new features impose performance hits.

Similarly, once Nitrogen 1.0 is released, it would be great to have a similar community effort toward security stress testing.

These two things, combined with really great user documentation, would go a long way toward propelling Nitrogen to the levels of acceptance and popularity that I sense we all believe possible.

Incidentally, do you have comparable test data for other frameworks? Love to see the side-by-sides.

Thanks again,

Lloyd

[mats]

It is the  length of the received page that differs.
It looks like cookies was created with different sizes.

Set-Cookie: wf=TazdxoNQAAAAUHicy2DKY2XQ0Yk6zJfBlJ7CIJSXWVKUn56a55CTn5yYk5FfXMLAwN3DAASMRQzMWBUwMjDI_GKAAgCRQRUg;
Set-Cookie: wf=1VFSrINQAAAAUHicy2DKY2XQ0Yk6zJfBlJ7CIJSXWVKUn56a55CTn5yYk5FfXMLAwN3PAASMRQzMWBUwMjDIMsAAAIkCFCo;

[ngocdaothanh]

> At some point it would be great if you could find time to publish in detail how you run these tests so others of us can run and publish our own.

It is very simple:
* Start Quickstart
* Run ab -c 10 -n 1000 http://127.0.0.1:8000/web/samples
* See the result

I am wondering if others do also see some failed requests in the
result.

I will be very happy to create a wiki page about Nitrogen speed
compared to that of Rails, Java Servlet etc. after there is no failed
request.

Ngoc.

[Andreas Stenius]

I've run the benchmark on a MacBook Pro, MacOS Leopard 10.5.6 with the following results:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)

Server Software:        inets/5.0.12
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /web/samples

Document Length:        6070 bytes

Concurrency Level:      10
Time taken for tests:   3.022 seconds
Complete requests:      1000
Failed requests:        113
   (Connect: 0, Receive: 0, Length: 113, Exceptions: 0)
Write errors:           0
Total transferred:      6346136 bytes
HTML transferred:       6062145 bytes
Requests per second:    330.91 [#/sec] (mean)
Time per request:       30.220 [ms] (mean)
Time per request:       3.022 [ms] (mean, across all concurrent requests)
Transfer rate:          2050.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max

Connect:        0    0   0.8      0       9
Processing:    12   30   5.8     28      70
Waiting:       12   29   5.7     28      70
Total:         18   30   5.8     29      70

Percentage of the requests served within a certain time (ms)

  50%     29
  66%     31

  75%     32
  80%     33
  90%     38

  95%     43
  98%     47
  99%     49
 100%     70 (longest request)


Number of failed requests varies between runs, but stays within the 80 - 150 range...

BR,
Andreas

2009/4/16 ngocdaothanh <ngocda...@gmail.com>

[ll...@paisite.com]

What with speed tests and Windex, Nitrogen gets more exciting everyday.

Thanks, folks.

LRP

[Tom McNulty]

Hi there,

>> At some point it would be great if you could find time to publish
>> in detail how you run these tests so others of us can run and
>> publish our own.
>
> It is very simple:
> * Start Quickstart
> * Run ab -c 10 -n 1000 http://127.0.0.1:8000/web/samples
> * See the result

Did you run quickstart.sh? Inets, Yaws, Mochiweb will yield different
performance profiles (although it'll be slight, since nitrogen will be
the bottleneck). Does your system have Hipe, smp?, do you see an
improvement if you edit quickstart to include +K? (kernel poll). You
mentioned you're on leopard, I am too, one machine is an old power pc
(no erlang hipe) and erlang performance a lot worse compared to my
intel mac pro.

> I am wondering if others do also see some failed requests in the
> result.

I ran some very quick tests on the intel mac using httperf. Note: the
test machine/server where the same, which is not acceptable for
published results! To get error messages, I have to achieve
saturation, (S-curve style drop in performance, connection resets
etc...) With mochiweb this occurred at about 190 requests per second,
with inets it's about 160. Does this mean there is room for
performance? Absolutely, now I can't speak for anyone else, but since
nitrogen is quite young the development focus is on it's feature set,
not optimizations.

>
>
> I will be very happy to create a wiki page about Nitrogen speed
> compared to that of Rails, Java Servlet etc. after there is no failed
> request.

As for rails. It's probably not possible to build a slower framework.
I'm not knocking them for this, rails is actually quite well designed.
The problem is ruby doesn't have any fast implementation, and the last
time I checked it's threading model was atrocious. To get performance
out of rails requires tremendous trickery.

We have to compare apples to apples so with java we'll need to pick
frameworks (Struts, Spring, some enterprise (lol) junk...), raw
servlets should be screamingly fast.

I have a life long devotion to hating PHP, so I'd like to see nitrogen
compared to some PHP frameworks (CAKE, CodeIgniter, Symfony (slooow))

- Tom

[ngocdaothanh]

> Did you run quickstart.sh? Inets, Yaws, Mochiweb will yield different performance profiles

I ran quickstart.sh (Inets) and quickstart_mochiweb.sh (MochiWeb).

I think there are failed requests not because Nitrogen is not fast
enough, but because there is some bug (may be with Set-Cookie as mats
suggested?). Sorry I'm still not deep enough into Nitrogen to be able
to investigate the cause.

Ngoc.

[Tom McNulty]

Just to rule things out, try lowing the -c (concurrency) value to 1,
and if you do not get errors, slowly increment it until you do. You'll
also see wider standard devations and longer response times.

In my test, I didn't use sessions, I'll try that again tomorrow morning.

- Tom

[mats]

Sorry, for my short mail.
It's not a bug. Ab is a historical tool to measure static pages. Static pages have the same size, so it make sense to report when it differ. Dynamic pages differ all the time. I just noticed that it could be the cookie since it is not of constant size(which is ok). It could also be that the sample page have a counter that got bigger (99->100). 

I recommend looking at Tsung, and help out making it a better tool by joining the mailing list.
https://lists.process-one.net/mailman/listinfo/tsung-users

/m

[ngocdaothanh]

> Just to rule things out, try lowing the -c (concurrency) value to 1, and if you do not get errors, slowly increment it until you do.

There are failed requests even when -c = 1. The number of failed
requests when -c = 1 is about the same when -c = 10.

Ngoc.

[Tom McNulty]

Okay. I think Mats' reasoning is correct, that is the problem being ab
itself (it really is quite old). httperf is very similar and I
recommend that as a good replacement for ab.

Mats, thanks for the Tsung recommendation, I wasn't even aware of it's
existence. I'll have to play around with that when I get time.

- Tom

[mats]

Thanks.

I'm learning a lot from Tsung at the moment. Here is an example of
what Tsung can print out:
http://wiki.github.com/cadar/lfeweb

I'm trying to understand the result. It's easy to get something, but
to be sure it is correct, is a hole other thing.

/m

[ngocdaothanh]

> httperf is very similar and I recommend that as a good replacement for ab.

I'm testing localhost - localhost and httperf shows no 5xx reply
status for the request rate of about 250 (httperf --server localhost --
port 8000 --uri /web/samples --rate 250 --num-conns 1000 --hog). So
maybe there's no bug in Nitrogen that causes failed requests :).

I will report the result with remote - localhost.

Ngoc.

[Tom McNulty]

Cool, that seems pretty good. Handling concurrent requests should
improve (but obviously not reply speed) using the networked test, as
you'll half the pool of OS resources (sockets, buffers, etc).

Bump up the num conns (so the test lasts 20 seconds or so), and let us
know at which point increasing the request rate starts to bottom out
performance. When you get close to the limits, repeat the test for
about a minute duration to mitigate false readings due to buffering
(why? it might take a few seconds for queues to overflow).

A while back I built a special purpose server similar to http://www.trapexit.org/A_fast_web_server_demonstrating_some_undocumented_Erlang_features
, which handled requests per seconds in the thousands. It kicked the
crap outta the same program built with NGINX+PHP. So there's quite a
lot of potential for performance using Erlang. Any framework is going
to be the bottle neck, but I can't see any reason why Nitrogen should
not surpass the frameworks currently out there. From my limited
testing, at the time, Django had the edge in performance, making it
the one to beat.




- Tom

[mats]

What is your "ulimit -n" (open files)

I run my test with "erl +K true +P 100000" and before start I run
"ulimit -n 20000".

[ngocdaothanh]

> What is your "ulimit -n" (open files)

I'm on Leopard:

$ ulimit -n
256
$ ulimit -n 20000
-bash: ulimit: open files: cannot modify limit: Invalid argument
$ sudo ulimit -n 20000
/usr/bin/ulimit: line 4: ulimit: open files: cannot modify limit:
Invalid argument

Ngoc.

[mats]

ok, try "ulimit -n 1000"

Tsung will spawn off an extra node if the number of open files exceed
the specified maxusers="1000". This make tsung not restricted by the
"open files"-limit of the shell.

I don't know how to go beyond 1000, without using Tsung.

[ngocdaothanh]

> ok, try "ulimit -n 1000"

Below are results for a quick test with:
* 100 Mbps LAN
* Server: Leopard, Core 2 Duo, 2 GB RAM, ulimit -n = 1000, +K true +P
100000 for both Inets and MochiWeb
* Client: Ubuntu, Core 2 Duo, 4 GB RAM, ulimit -n = 1024

Comments:
* No 5xx errror when the number of concurrent connections is about 350
* Slightly better results compared to when testing on localhost
* MochiWeb gives slightly better result than Inets

Ngoc.


Result for Inets:
----------
$ httperf --server 10.41.255.201 --port 8000 --uri /web/samples --rate
350 --num-conns 35000 --hog
httperf --hog --client=0/1 --server=10.41.255.201 --port=8000 --uri=/
web/samples --rate=350 --send-buffer=4096 --recv-buffer=16384 --num-
conns=35000 --num-calls=1
Maximum connect burst length: 1

Total: connections 35000 requests 35000 replies 35000 test-duration
140.041 s

Connection rate: 249.9 conn/s (4.0 ms/conn, <=688 concurrent
connections)
Connection time [ms]: min 9.1 avg 808.3 max 45025.3 median 10.5 stddev
5910.3
Connection time [ms]: connect 794.4
Connection length [replies/conn]: 1.000

Request rate: 249.9 req/s (4.0 ms/req)
Request size [B]: 77.0

Reply rate [replies/s]: min 0.0 avg 249.9 max 352.8 stddev 153.4 (28
samples)
Reply time [ms]: response 10.1 transfer 3.8
Reply size [B]: header 286.0 content 5955.0 footer 0.0 (total 6241.0)
Reply status: 1xx=0 2xx=35000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 20.61 system 119.19 (user 14.7% system 85.1% total
99.8%)
Net I/O: 1542.4 KB/s (12.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
----------

Result for MochiWeb:
----------
$ httperf --server 10.41.255.201 --port 8000 --uri /web/samples --rate
350 --num-conns 35000 --hog
httperf --hog --client=0/1 --server=10.41.255.201 --port=8000 --uri=/
web/samples --rate=350 --send-buffer=4096 --recv-buffer=16384 --num-
conns=35000 --num-calls=1
Maximum connect burst length: 1

Total: connections 35000 requests 35000 replies 34459 test-duration
122.146 s

Connection rate: 286.5 conn/s (3.5 ms/conn, <=1010 concurrent
connections)
Connection time [ms]: min 9.0 avg 663.5 max 45098.4 median 67.5 stddev
3249.3
Connection time [ms]: connect 583.7
Connection length [replies/conn]: 1.000

Request rate: 286.5 req/s (3.5 ms/req)
Request size [B]: 77.0

Reply rate [replies/s]: min 0.0 avg 286.2 max 382.8 stddev 129.1 (24
samples)
Reply time [ms]: response 146.0 transfer 4.4
Reply size [B]: header 343.0 content 5955.0 footer 0.0 (total 6298.0)
Reply status: 1xx=0 2xx=34459 3xx=0 4xx=0 5xx=0

CPU time [s]: user 11.28 system 110.28 (user 9.2% system 90.3% total
99.5%)
Net I/O: 1757.2 KB/s (14.4*10^6 bps)

Errors: total 541 client-timo 0 socket-timo 0 connrefused 0 connreset
541
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
----------

[mats]

Is the server a 2.2Ghz cpu?
What is in web_samples.erl?
It is strange that Mochiweb have errors. I expected it to perform
better. Here is my result on Ubuntu[4].


I ran some test on Ubuntu with Tsung. Looking at [1], I think the most
impressive thing is the low response time, 6ms at <200 reg/s. At the
moment I'm exploring the thought that low latency will be Nitrogens
biggest advantages. Here is a real Erlang application[2] with 15 ms
response time (~ 10-20 ms will be a normal number).

It's also important to know about YSlow[3] (measurement tool for the
experienced speed in Firefox).

[1] graph nr 8 at http://wiki.github.com/cadar/lfeweb
[2] http://beebole.com/blog/erlang/test-performance-and-scalability-of-your-web-applications-with-tsung
[3] http://developer.yahoo.com/yslow/

[4]
(same hardware as [1] Laptop Thinkpad T61 2.2Ghz)
bash-3.2# erl
Erlang (BEAM) emulator version 5.6.5 [source] [smp:2]
[async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.6.5 (abort with ^G)

bash-3.2# httperf --hog --client=0/1 --server=10.0.1.3 --port=8003
--uri=/web/index --rate=350 --send-buffer=4096 --recv-buffer=16384
--num-conns=35000 --num-calls=1
httperf --hog --client=0/1 --server=10.0.1.3 --port=8003
--uri=/web/index --rate=350 --send-buffer=4096 --recv-buffer=16384
--num-conns=35000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of
open files to FD_SETSIZE
Maximum connect burst length: 7

Total: connections 35000 requests 34921 replies 34911 test-duration 100.005 s

Connection rate: 350.0 conn/s (2.9 ms/conn, <=33 concurrent connections)
Connection time [ms]: min 1.4 avg 5.7 max 93.1 median 3.5 stddev 10.4
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000

Request rate: 349.2 req/s (2.9 ms/req)
Request size [B]: 70.0

Reply rate [replies/s]: min 332.2 avg 349.1 max 354.8 stddev 4.3 (20 samples)
Reply time [ms]: response 5.5 transfer 0.0
Reply size [B]: header 350.0 content 1149.0 footer 0.0 (total 1499.0)
Reply status: 1xx=0 2xx=34911 3xx=0 4xx=0 5xx=0

CPU time [s]: user 22.44 system 76.41 (user 22.4% system 76.4% total 98.8%)
Net I/O: 535.5 KB/s (4.4*10^6 bps)

Errors: total 89 client-timo 0 socket-timo 0 connrefused 79 connreset 10

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
--

I think httperf need to use Erlang processes.


/m

[Rusty Klophaus]

Hey guys,

I am very excited to see this group focusing some long overdue
attention performance tests. I agree that this is one of Nitrogen's
biggest advantages against other frameworks.

Keep it up! If you boil this down to some conclusive, published
numbers (perhaps in a blog post?) within the next week, I'll include
it in my Erlang Factory presentation with shoutouts. Unfortunately I
don't know much at all about measuring web server performance, so you
will have to really spell it out for me. :)

Best,
Rusty

[Tom McNulty]

I've been programming erlang about a year to the day now, and I still
don't think I understand how to take full advantage of profiling and
tracing. That'll definitely help show where optimizations need to
start.

- Tom

[Andreas Stenius]

You know about eper? http://code.google.com/p/eper/

Only used redbug recently to help debug during my parallell rendering testing...

BR,
Andreas

2009/4/21 Tom McNulty <tom.m...@cetiforge.com>

[Tom McNulty]

Cheers, I did not know about these.  Between these and Tsung, it seems I've got some new toys to play with ;-).

I've only briefly played with the 3 profilers in the library, and briefly etop.  

Thanks,

- Tom

[etnt]

Redbug is very easy to use and extremely useful.
I have described redbug here:

http://blog.tornkvist.org/blog.yaws?id=1235118230450969

I also recommend exrefcheck, described here:

http://blog.tornkvist.org/blog.yaws?id=1236148649288620

Cheers, Tobbe

On Apr 21, 6:52 am, Tom McNulty <tom.mcnu...@cetiforge.com> wrote:
> Cheers, I did not know about these.  Between these and Tsung, it seems  
> I've got some new toys to play with ;-).
>
> I've only briefly played with the 3 profilers in the library, and  
> briefly etop.
>
> Thanks,
>
> - Tom
>
> On 20-Apr-09, at 10:23 PM, Andreas Stenius wrote:
>

> > You know about eper?http://code.google.com/p/eper/

>
> > Only used redbug recently to help debug during my parallell  
> > rendering testing...
>
> > BR,
> > Andreas
>

> > 2009/4/21 Tom McNulty <tom.mcnu...@cetiforge.com>

> > >> [2]http://beebole.com/blog/erlang/test-performance-and-scalability-of-yo...

[MS]

Hello Tobbe,

On Tue, Apr 21, 2009 at 9:13 AM, etnt <torbjorn....@gmail.com> wrote:
> I also recommend exrefcheck, described here:
>
>  http://blog.tornkvist.org/blog.yaws?id=1236148649288620

What a great tool! Was about to write the same functionality in the
next days which i can safely skip now.
Thank you for sharing it!

Martin

[vim]

thank!

the examples on the blog are much better than those on the project
wiki ;)

just started to play with it and it looks promising.

vim.

On Apr 21, 10:13 am, etnt <torbjorn.tornkv...@gmail.com> wrote:
> Redbugis very easy to use and extremely useful.

> I have describedredbughere:
>
>  http://blog.tornkvist.org/blog.yaws?id=1235118230450969
>
> I also recommend exrefcheck, described here:
>
>  http://blog.tornkvist.org/blog.yaws?id=1236148649288620
>
> Cheers, Tobbe
>
> On Apr 21, 6:52 am, Tom McNulty <tom.mcnu...@cetiforge.com> wrote:
>
>
>
> > Cheers, I did not know about these.  Between these and Tsung, it seems  
> > I've got some new toys to play with ;-).
>
> > I've only briefly played with the 3 profilers in the library, and  
> > briefly etop.
>
> > Thanks,
>
> > - Tom
>
> > On 20-Apr-09, at 10:23 PM, Andreas Stenius wrote:
>
> > > You know about eper?http://code.google.com/p/eper/
>

> > > Only usedredbugrecently to help debug during my parallell  

[ngocdaothanh]

Hi.

1. Benchmark

I've used Tsung to benchmark:
* Server machine: Core 2 Duo 2.33GHz, 3GB RAM, runs a very simple
Nitrogen template page with no DB access, Nitrogen runs on Yaws
* 3 client machines, create 800 users per second, each user creates 1
GET request to the page
* All machines: 100Mbps LAN, Ubuntu 9.04 server edition, Erlang
R13B01, ulimit -n 1000000, +K true, +P 1000000

Result: http://rapidshare.com/files/245078339/10m-800u.zip

2. Simultaneous Users

I'm curious about the graph of Simultaneous Users:
http://farm4.static.flickr.com/3600/3632027628_3725135e4c.jpg

I think there is something that limits the server from accepting more
than about 550 simultaneous connections. Do you have any advice to
raise this limit (Yaws' config, Ubuntu's config etc.)?

Regards,
Ngoc.

On 4月21日, 午後1:52, Tom McNulty <tom.mcnu...@cetiforge.com> wrote:
> Cheers, I did not know about these. Between these and Tsung, it seems
> I've got some new toys to play with ;-).
>
> I've only briefly played with the 3 profilers in the library, and
> briefly etop.
>
> Thanks,
>
> - Tom
>
> On 20-Apr-09, at 10:23 PM, Andreas Stenius wrote:
>

> > You know about eper?http://code.google.com/p/eper/

>
> > Only used redbug recently to help debug during my parallell
> > rendering testing...
>
> > BR,
> > Andreas
>

> > 2009/4/21 Tom McNulty <tom.mcnu...@cetiforge.com>

> > >> [1] graph nr 8 athttp://wiki.github.com/cadar/lfeweb
> > >> [2]http://beebole.com/blog/erlang/test-performance-and-scalability-of-yo...

[Linh]

I suspect there are failed requests when benchmarking with ab because
TPC listen backlog is not set big enough. I tried to set the listen
backlog of Yaws to 100 (http://yaws.hyber.org/yman.yaws?
page=yaws.conf):
* ab -c 100 -n 10000 http://xxx => no error
* ab -c 200 -n 10000 http://xxx => apr_socket_recv: Connection reset
by peer (54)