From: Jimmie H. <jho...@te...> - 2003-09-16 03:02:09
|
Hello, I am hoping to build a website based on Erlang and Yaws. I was trying to do a small benchmark on my home computer on a static html file to compare with Apache2. The file is a simple file filled with Hello World Wide Web!!! strings. I was benchmarking with httperf. httperf --hog --num-conn 10000 --server squirrel --uri=hellowww.html A similar test was successful serving the root document, index.yaws. I got this error 10,000 times. =ERROR REPORT==== 15-Sep-2003::21:05:16 === Yaws process died: {{case_clause,"hellowww.html"}, [{yaws_server,handle_request,5}, {yaws_server,aloop,3}, {yaws_server,acceptor0,2}, {proc_lib,init_p,5}]} Yaws successfully serves this to Mozilla. Apache2 is successful with the same test. I am running an Athlon machine with Gentoo Linux. Any help greatly appreciated. Jimmie Houchin |
From: Leon S. <lp...@cw...> - 2003-09-16 04:23:28
|
Change your uri to: --uri=/hellowww.html Now, I am not extremely well versed on the URI standard, but my understanding is that your uri isn't technically legit. Browsers always send an absolute uri to a webserver. This is something we should handle more gracefully so as not to pollute error logs. We are working on improving URL handling. We are aware of this issue but I was under the impression this had been fixed. :-) So this does bring up a question for the list... how should Yaws respond to such a uri? Assuming my understanding of the standard is correct, I'm inclined to not pollute the standard and return a 403. best, leon Jimmie Houchin wrote: > Hello, > > I am hoping to build a website based on Erlang and Yaws. > > I was trying to do a small benchmark on my home computer on a static > html file to compare with Apache2. > > The file is a simple file filled with Hello World Wide Web!!! strings. > > I was benchmarking with httperf. > httperf --hog --num-conn 10000 --server squirrel --uri=hellowww.html > > A similar test was successful serving the root document, index.yaws. > > I got this error 10,000 times. > > =ERROR REPORT==== 15-Sep-2003::21:05:16 === > Yaws process died: {{case_clause,"hellowww.html"}, > [{yaws_server,handle_request,5}, > {yaws_server,aloop,3}, > {yaws_server,acceptor0,2}, > {proc_lib,init_p,5}]} > > Yaws successfully serves this to Mozilla. > > Apache2 is successful with the same test. > I am running an Athlon machine with Gentoo Linux. > > Any help greatly appreciated. > > Jimmie Houchin > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: <kl...@hy...> - 2003-09-16 10:43:47
|
On Mon, Sep 15, 2003 at 11:29:38PM -0500, Leon Smith wrote: > Change your uri to: > > --uri=/hellowww.html > > Now, I am not extremely well versed on the URI standard, but my > understanding is that your uri isn't technically legit. Browsers > always send an absolute uri to a webserver. > > This is something we should handle more gracefully so as not to pollute > error logs. We are working on improving URL handling. We are aware of > this issue but I was under the impression this had been fixed. :-) > > So this does bring up a question for the list... how should Yaws respond > to such a uri? Assuming my understanding of the standard is correct, > I'm inclined to not pollute the standard and return a 403. No we shouldn't crash on a malformed URI. On the other hand looking at the webserver logs on a webserver (live on internet) there are many hits for apparently explicitly malformed URIs from all the lame scripts and infected MS software. On the otherhand it's good to respond with something nice instead of just crashing. Another _very_ common situation is to have a slightly broken web tester tool (such as httpload with a bad arg) and debugging what's wrong with the testtool/testtool config can be hairy. I've had a lot of that :-( The Right Thing to do would be: as daemon: (-D) respond 403 Forbidden as (-i or/and -d) respond 403 Forbidden + error_logger:format(.....) /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Jimmie H. <jho...@te...> - 2003-09-16 12:51:22
|
Leon Smith wrote: > Change your uri to: > > --uri=/hellowww.html > > Now, I am not extremely well versed on the URI standard, but my > understanding is that your uri isn't technically legit. Browsers > always send an absolute uri to a webserver. > This is something we should handle more gracefully so as not to pollute > error logs. We are working on improving URL handling. We are aware of > this issue but I was under the impression this had been fixed. :-) > > So this does bring up a question for the list... how should Yaws respond > to such a uri? Assuming my understanding of the standard is correct, > I'm inclined to not pollute the standard and return a 403. > > best, > leon Thanks Leon. I didn't know how httperf was handling things, so the first forward slash didn't even occur to me. But I will agree it shouldn't crash Yaws. I just posted in another messages a question about the successful tests. Thanks again. Jimmie [snip] |
From: Jimmie H. <jho...@te...> - 2003-09-16 13:01:53
|
Hello, Below is the output from script for some simple benchmarking with httperf. This is on an Athlon 700mhz 1.25gb ram, machine running Gentoo Linux, Erlang 9C-0 and Yaws 1.3. I know my machine isn't the fastest, but Apache2 and Yaws are on level ground. With the same static file which is the html output from the simple_ex3.yaws script, Apache cleaned up. Apache got about 800+ rps. Yaws got about 58 rps. On the 25k hellowww.html file. Apache 1100 rps. Yaws 53 rps. Multiple tests were consistent. Yaws didn't change much regardless whether it was the simple_ex3.yaws (dynamic) or the simple_ex3.yaws.html (static). The simple.yaws and simple_ex2.yaws yielded similar results on Yaws. I am not seeing the results I had hoped for from reading this list and the website. ie: 1000s of dynamic rps. Not even seeing 100s yet on my machine. Could I be doing something wrong? Am I misunderstanding something? Am I doing something wrong with httperf? It is new to me. I used to use ab, but ab is broken with the Apache2 install. :( I thought Erlang/Yaws would outperform Apache2/mod_python. It still might. :) Any enlightenment greatly appreciated. Jimmie Houchin Yaws Benchmark for a static simple_ex3.yaws.html [01;32mroot@squirrel [01;34mjimmie # [00mhttperf --hog --num-conn 10000 --server squirrel --uri=/simple_ex3.yaws.html httperf --hog --client=0/1 --server=squirrel --port=80 --uri=/simple_ex3.yaws --send-buffer=4096 --recv-buffer=16384 --num-conns=10000 --num-calls=1 Maximum connect burst length: 1 Total: connections 10000 requests 10000 replies 10000 test-duration 172.687 s Connection rate: 57.9 conn/s (17.3 ms/conn, <=1 concurrent connections) Connection time [ms]: min 1.6 avg 17.3 max 128.8 median 19.5 stddev 6.9 Connection time [ms]: connect 0.7 Connection length [replies/conn]: 1.000 Request rate: 57.9 req/s (17.3 ms/req) Request size [B]: 74.0 Reply rate [replies/s]: min 49.2 avg 58.0 max 332.2 stddev 48.4 (34 samples) Reply time [ms]: response 16.5 transfer 0.0 Reply size [B]: header 151.0 content 1656.0 footer 2.0 (total 1809.0) Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0 CPU time [s]: user 49.08 system 119.81 (user 28.4% system 69.4% total 97.8%) Net I/O: 106.4 KB/s (0.9*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 Apache2 Benchmark for a static simple_ex3.yaws.html [01;32mroot@squirrel [01;34mjimmie # [00mhttperf --hog --num-conn 10000 --server squirrel --uri=/simple_ex3.yaws.html httperf --hog --client=0/1 --server=squirrel --port=80 --uri=/simple_ex3.yaws.html --send-buffer=4096 --recv-buffer=16384 --num-conns=10000 --num-calls=1 Maximum connect burst length: 1 Total: connections 10000 requests 10000 replies 10000 test-duration 12.388 s Connection rate: 807.2 conn/s (1.2 ms/conn, <=1 concurrent connections) Connection time [ms]: min 1.1 avg 1.2 max 163.7 median 1.5 stddev 1.8 Connection time [ms]: connect 0.5 Connection length [replies/conn]: 1.000 Request rate: 807.2 req/s (1.2 ms/req) Request size [B]: 79.0 Reply rate [replies/s]: min 780.1 avg 801.9 max 823.8 stddev 30.9 (2 samples) Reply time [ms]: response 0.7 transfer 0.0 Reply size [B]: header 284.0 content 1656.0 footer 0.0 (total 1940.0) Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0 CPU time [s]: user 0.99 system 2.61 (user 8.0% system 21.1% total 29.1%) Net I/O: 1591.6 KB/s (13.0*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 |
From: Mickael R. <mic...@er...> - 2003-09-16 13:38:07
|
* Jimmie Houchin <jho...@te...> [2003-09-16 08:01:51 -0500]: > I am not seeing the results I had hoped for from reading this list and=20 > the website. ie: 1000s of dynamic rps. Not even seeing 100s yet on my=20 > machine. I did not do this test with latest version of Yaws. The performance used to be outstanding. I will check on the last version on my machine to this if the result is still in the same order of magnitude. > I thought Erlang/Yaws would outperform Apache2/mod_python. > It still might. :) I hope so :-) --=20 Micka=EBl R=E9mond |
From: <kl...@hy...> - 2003-09-16 14:33:26
|
On Tue, Sep 16, 2003 at 08:01:51AM -0500, Jimmie Houchin wrote: > Hello, > > Below is the output from script for some simple benchmarking with > httperf. This is on an Athlon 700mhz 1.25gb ram, machine running Gentoo > Linux, Erlang 9C-0 and Yaws 1.3. > > I know my machine isn't the fastest, but Apache2 and Yaws are on level > ground. > > With the same static file which is the html output from the > simple_ex3.yaws script, Apache cleaned up. > > Apache got about 800+ rps. > Yaws got about 58 rps. > Doesn't look so good: I get completely different numbers. Much faster than apache. Something is seriously wrong. I'm running gentoo linux, a 2.2Ghz machine, erl R9B, httperf 0.8, and yaws out of CVS and getting approx 1400 pages/sec, regardless of static or dynamic. Apache 1.3.27 gives me approx 320 static pages/sec. Didn't even bother to meassure num php pages/sec. Weird, /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Nicolas N. <nicolas.niclausse@IDEALX.com> - 2003-09-16 14:43:36
|
>>>>> "klacke" =3D=3D klacke <kl...@hy...> =E9crivait: klacke> On Tue, Sep 16, 2003 at 08:01:51AM -0500, Jimmie Houchin wrote: >> Hello, >>=20 >> With the same static file which is the html output from the >> simple_ex3.yaws script, Apache cleaned up. >>=20 >> Apache got about 800+ rps. Yaws got about 58 rps. In this setup, there is non concurrency: httperf is configured to run a single user, and for every HTTP request, it start a new TCP connection (HTTP keepalive is not used). Maybe Yaws is slow to handle new tcp connections ? klacke> Doesn't look so good: I get completely different numbers. Much klacke> faster than apache. Something is seriously wrong. klacke> I'm running klacke> gentoo linux, a 2.2Ghz machine, erl R9B, httperf 0.8, and yaws klacke> out of CVS klacke> and getting approx 1400 pages/sec, regardless of static or klacke> dynamic. Apache 1.3.27 gives me approx 320 static klacke> pages/sec. Didn't even bother to meassure num php pages/sec. What is your httperf setup ? --=20 Nicolas NICLAUSSE IDEALX S.A.S. T=E9l:01 44 42 00 00 http://IDEALX.com/ |
From: <kl...@hy...> - 2003-09-16 15:09:07
|
> > In this setup, there is non concurrency: httperf is configured to run a > single user, and for every HTTP request, it start a new TCP connection > (HTTP keepalive is not used). Maybe Yaws is slow to handle new tcp > connections ? > Yes, I can reproduce it. It's extremely weird though. Some observations: 1. It never happens with --num-conn=1000 2. When it happens, beam is consumin 5% of the cpu. 3. It doesn't happen all the time: (Here is a run over the network) # httperf --hog --num-conn 10000 --server=tita --port=8000 --uri=/spacer.gif httperf --hog --client=0/1 --server=tita --port=8000 --uri=/spacer.gif --send-buffer=4096 --recv-buffer=16384 --num-conns=10000 --num-calls=1 Maximum connect burst length: 1 Total: connections 10000 requests 10000 replies 10000 test-duration 7.467 s Connection rate: 1339.2 conn/s (0.7 ms/conn, <=1 concurrent connections) Connection time [ms]: min 0.5 avg 0.7 max 3.5 median 0.5 stddev 0.0 Connection time [ms]: connect 0.2 Connection length [replies/conn]: 1.000 Request rate: 1339.2 req/s (0.7 ms/req) Request size [B]: 65.0 Reply rate [replies/s]: min 1338.3 avg 1338.3 max 1338.3 stddev 0.0 (1 samples) Reply time [ms]: response 0.6 transfer 0.0 Reply size [B]: header 210.0 content 43.0 footer 0.0 (total 253.0) Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0 CPU time [s]: user 2.37 system 5.09 (user 31.7% system 68.2% total 99.9%) Net I/O: 415.9 KB/s (3.4*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 4. httperf consumes 99.9 cpu while running. This can't be right since it is running unthreaded and setting up tearing down sockets sequentially. (I can't seem to see no way to instruct it to run in parallel) Later I'll try with some other load generator. Some while ago I run generator galled http_load (or something) To be continued .... /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Nicolas N. <nicolas.niclausse@IDEALX.com> - 2003-09-16 15:37:54
|
>>>>> "klacke" =3D=3D klacke <kl...@hy...> =E9crivait: klacke> Yes, I can reproduce it. It's extremely weird though. Some klacke> observations: klacke> 1. It never happens with --num-conn=3D1000=20 klacke> 2. When it happens, beam is consumin 5% of the cpu. klacke> 3. It doesn't happen all the time: Weird, maybe the system is running out of ressources, and has to wait for them ? Since beam is single threaded, it may runs out of file descriptors ? (usually, the limit is set to 1024 ) Dows Yaws close the connection as soon as he received the close from the client ? klacke> 4. httperf consumes 99.9 cpu while running. This can't be right klacke> since it is running unthreaded and setting up tearing down klacke> sockets sequentially.=20 It's not a bug, it's a feature :)=20 From http://www.hpl.hp.com/personal/David_Mosberger/httperf/ : =ABTo avoid depending on OS scheduling granularity, httperf executes in a tight loop that checks for network I/O activity via select() and keeps track of real time via gettimeofday(). This means that httperf consumes all available CPU cycles (on a multiprocessor client, only one CPU will be kept busy in this way). This approach works fine because the only other important activity is the asynchronous receiving and processing of network packets. Since this activity executes as a (soft-) interrupt handler, no scheduling problem arises. However, executing in a tight loop does imply that only one httperf process can run per client machine (per client CPU, to be more precise). It also means that care should be taken to avoid unnecessary background tasks on the client machine while a test is in progress.=BB --=20 Nicolas NICLAUSSE IDEALX S.A.S. T=E9l:01 44 42 00 00 http://IDEALX.com/ |
From: <kl...@hy...> - 2003-09-16 18:22:21
|
On Tue, Sep 16, 2003 at 05:37:50PM +0200, Nicolas Niclausse wrote: > >>>>> "klacke" =3D=3D klacke <kl...@hy...> =E9crivait: >=20 > klacke> Yes, I can reproduce it. It's extremely weird though. Some > klacke> observations: >=20 > klacke> 1. It never happens with --num-conn=3D1000=20 > klacke> 2. When it happens, beam is consumin 5% of the cpu. > klacke> 3. It doesn't happen all the time: >=20 > Weird, maybe the system is running out of ressources, and has to wait > for them ? Since beam is single threaded, it may runs out of file > descriptors ? (usually, the limit is set to 1024 ) How could that be, httperf open/close fds serially. Another resouce is TCP connections in boring WAIT states, this did't seem to be the problem either. Not as reported by netstat anyway. >=20 > Dows Yaws close the connection as soon as he received the close from th= e > client ? Two cases, 1. client is HTTP 1.1 and does not send Connection-Close header Yaws will not close the socket, client will then close socket and yaws may end up in LAST-ACK state i client doesn't do the right thing 2. client is 1.0, yaws will ship data and immediataly close=20 the socket. This gives lots of sockets in TIME-WAIT which I didn't see >=20 > klacke> 4. httperf consumes 99.9 cpu while running. This can't be righ= t > klacke> since it is running unthreaded and setting up tearing down > klacke> sockets sequentially.=20 >=20 > It's not a bug, it's a feature :)=20 ok .. maybe >=20 > >From http://www.hpl.hp.com/personal/David_Mosberger/httperf/ : >=20 > =ABTo avoid depending on OS scheduling granularity, httperf executes in= a > tight loop that checks for network I/O activity via select() and keeps > track of real time via gettimeofday(). This means that httperf consumes > all available CPU cycles (on a multiprocessor client, only one CPU will > be kept busy in this way). This approach works fine because the only > other important activity is the asynchronous receiving and processing o= f > network packets. Since this activity executes as a (soft-) interrupt > handler, no scheduling problem arises. However, executing in a tight > loop does imply that only one httperf process can run per client machin= e > (per client CPU, to be more precise). It also means that care should be > taken to avoid unnecessary background tasks on the client machine while > a test is in progress.=BB I don't buy that at all. Executing in a tight loop seems real stupid to me. select/poll is there for a reason.=20 /klacke --=20 Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control = =20 |
From: <kl...@hy...> - 2003-09-16 18:50:06
|
The plot thickens, I cannot reproduce it on my home boxen. All my home boxen are gentoo, and .... well i cannot get into that weird idling state I saw earlier today at work. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Nicolas N. <nicolas.niclausse@IDEALX.com> - 2003-09-17 08:13:16
|
>>>>> "klacke" =3D=3D klacke <kl...@hy...> =E9crivait: klacke> How could that be, httperf open/close fds serially. Another klacke> resouce is TCP connections in boring WAIT states, this did't klacke> seem to be the problem either. Not as reported by netstat klacke> anyway. I was thinking of half closed TCP connections maybe, but it should be reported by netstat indeed =20 >> Dows Yaws close the connection as soon as he received the close >> from the client ? klacke> Two cases, klacke> 1. client is HTTP 1.1 and does not send Connection-Close header klacke> Yaws will not close the socket, client will then close socket klacke> and yaws may end up in LAST-ACK state i client doesn't do the klacke> right thing httperf always used HTTP/1.1 unless specified. With the options used by Jimmie Houchin, it will not use KeepAlive and close the connection after each request, but without sending a Connection-Close header. from the RFC: =AB Clients and servers SHOULD both constantly watch for the other side o= f the transport close, and respond to it as appropriate. If a client or server does not detect the other side's close promptly it could cause unnecessary resource drain on the network. =BB When does Yaws close the connection in that case ? After a timeout expiration ? klacke> I don't buy that at all. Executing in a tight loop seems real klacke> stupid to me. select/poll is there for a reason. I am not convinced either :) --=20 Nicolas NICLAUSSE IDEALX S.A.S. T=E9l:01 44 42 00 00 http://IDEALX.com/ |
From: <kl...@hy...> - 2003-09-17 13:26:14
|
On Wed, Sep 17, 2003 at 10:13:12AM +0200, Nicolas Niclausse wrote: >=20 > I was thinking of half closed TCP connections maybe, but it should be > reported by netstat indeed =20 Yep, > httperf always used HTTP/1.1 unless specified. With the options used by > Jimmie Houchin, it will not use KeepAlive and close the connection afte= r > each request, but without sending a Connection-Close header. I get no Conneciton-Close header, just the Host and the User-Agent header= s. httpperf FINs me after it has read the full page. Looks good. >=20 > from the RFC: >=20 > =AB Clients and servers SHOULD both constantly watch for the other side= of > the transport close, and respond to it as appropriate. If a client or > server does not detect the other side's close promptly it could cause > unnecessary resource drain on the network. =BB >=20 Well, as I said, httperf does send Yaws the FIN, thus forcing Yaws to also close the HTTP 1.1 connection. There is one Yaws process/socket, so if there were many pending half closed sessions I would: 1. see that in netstat 2. see that in erlang shell using i(). What's even more interesting is that I can now reproduce (intermittent al= so) similar bahaviour with apache. Plot thickens .... > When does Yaws close the connection in that case ? After a timeout > expiration ? configurable (default =3D 30 secs) /klacke --=20 Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control = =20 |
From: Jimmie H. <jho...@te...> - 2003-09-17 15:04:14
|
kl...@hy... wrote: > On Wed, Sep 17, 2003 at 10:13:12AM +0200, Nicolas Niclausse wrote: [snip] I am not knowledgeable enough to keep up with you on this. Are you discovering problems with Yaws or with the way httperf does benchmarking? Also while benchmarking a file with this at the top of the file: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> I repeatedly got this error: =ERROR REPORT==== 16-Sep-2003::17:13:38 === Yaws process died: {error,einval} =ERROR REPORT==== 16-Sep-2003::17:13:38 === Failed to send 10240 bytes: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transi....." on socket #Port<0.4943>: {error, einval} Am I just good at coming up with stupid user errors or what? :) My errors, that is. Hopefully this will be profitable for Yaws. Jimmie |
From: Carsten S. <ca...@gn...> - 2003-09-17 15:47:34
|
On Wed, Sep 17, 2003 at 10:04:09AM -0500, Jimmie Houchin wrote: > Also while benchmarking a file with this at the top of the file: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <html xmlns=3D"http://www.w3.org/1999/xhtml" xml:lang=3D"en" lang=3D"en"> I do not think that this matters. > I repeatedly got this error: >=20 > =3DERROR REPORT=3D=3D=3D=3D 16-Sep-2003::17:13:38 =3D=3D=3D > Yaws process died: {error,einval} First of all let me note that a yaws process dying is not necessarily something to worry about. It won't affect the functioning of the server. I have to agree that not in all cases a log report should be written. Maybe this should be done depending on the debugging mode as Claes suggested for certain bad requests. > =3DERROR REPORT=3D=3D=3D=3D 16-Sep-2003::17:13:38 =3D=3D=3D > Failed to send 10240 bytes: > "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transi....." on socket=20 > #Port<0.4943>: {error, einval} Looks like the client requested the document but then closed the connection. Is that possible? Please keep on posting what is worrying you. Greetings, Carsten --=20 Carsten Schultz (2:40, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers,=20 fingerprint on my home page. |
From: Nicolas N. <nicolas.niclausse@IDEALX.com> - 2003-09-19 20:19:14
|
>>>>> "klacke" =3D=3D klacke <kl...@hy...> =E9crivait: klacke> What's even more interesting is that I can now reproduce klacke> (intermittent also) similar bahaviour with apache. Plot klacke> thickens .... I have installed yaws and can not reproduce this behaviour. My server is a 2xPIII 1ghz using httperf --hog --num-conn 10000 on a 2.9KB static file: with yaws-1.30: 820 req/s with apache-1.3.27: 1000 req/s (but Apache use both CPU) --=20 Nicolas NICLAUSSE IDEALX S.A.S. T=E9l:01 44 42 00 00 http://IDEALX.com/ |