[Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
It seems we didn't got this CC in tc-dev : ---BeginMessage--- Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2 alone 1202 req/s TC/Coyote 883 req/s One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? Brian ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Henri Gomez wrote: It seems we didn't got this CC in tc-dev : Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2 alone 1202 req/s TC/Coyote 883 req/s One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Remy Maucherat wrote, On 7/28/2004 7:54 AM: One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. stat is a Unix system call which retrives the status information of a file or directory. Each stat call can potentially hit the disk, so this can be a very expensive system call to make if you have deep directory trees and could explain some of the performance differences between Apache and Tomcat. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where Filip - Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 11:08 AM Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev] Remy Maucherat wrote, On 7/28/2004 7:54 AM: One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. stat is a Unix system call which retrives the status information of a file or directory. Each stat call can potentially hit the disk, so this can be a very expensive system call to make if you have deep directory trees and could explain some of the performance differences between Apache and Tomcat. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Filip Hanik - Dev wrote: The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where Ok. Well, I think there's no such thing, as the test was about a servlet. There's also a cache, so it won't go to the HD too often, but of course, I don't know how it really works. Also something to remember is that the HelloWorld example servlet is a very bad throughtput test: it has a very expensive i18n operation (it retrieves a resource bundle on each request), which Apache doesn't do. So it would be better to either test with a static file, or write a new servlet with the same output (minus i18n). It would be good to test with HEAD (the test was done with 3.3) to see if the stat issue occurs. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
- Original Message - From: Filip Hanik - Dev [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 9:13 AM Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev] The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where My guess would be File.getCanonicalPath() in FileDirContext. Filip - Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 11:08 AM Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev] Remy Maucherat wrote, On 7/28/2004 7:54 AM: One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. stat is a Unix system call which retrives the status information of a file or directory. Each stat call can potentially hit the disk, so this can be a very expensive system call to make if you have deep directory trees and could explain some of the performance differences between Apache and Tomcat. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Remy Maucherat wrote: Filip Hanik - Dev wrote: The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where Ok. Well, I think there's no such thing, as the test was about a servlet. There's also a cache, so it won't go to the HD too often, but of course, I don't know how it really works. Also something to remember is that the HelloWorld example servlet is a very bad throughtput test: it has a very expensive i18n operation (it retrieves a resource bundle on each request), which Apache doesn't do. So it would be better to either test with a static file, or write a new servlet with the same output (minus i18n). I was testing the delivery of a static file, not a servlet, when I found the stat calls. The stats don't happen with servlets in general; it's just the default static-file handler service that has this overhead (in Tomcat 5.0.25 and 5.0.27; I haven't tried any other versions). Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Bill Barker wrote: My guess would be File.getCanonicalPath() in FileDirContext. There's a cache for that, so canonicalization will happen only once in a while. I don't understand how it can possibly be a performance issue. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
From: Bill Barker [EMAIL PROTECTED] From: Filip Hanik - Dev [EMAIL PROTECTED] The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where My guess would be File.getCanonicalPath() in FileDirContext. I can confirm from the SCSL 1.4 jdk source that File.getCanonicalPath() eventually calls realpath(3) in the jdk src. On OpenBSD (and probably all unixes) realpath(3) causes an lstat on each dir in the path. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
There's a cache for that, so canonicalization will happen only once in a while. I don't understand how it can possibly be a performance issue. maybe I am reading the code wrong, but the method file() in FileDirContext creates a new file object each time, so there is no caching there. So I guess the caching is on a higher level? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Tim Funk wrote: Try siege: http://joedog.org/siege/ Despite what the docs say, it runs pretty sweet on cygwin too. (with 2.60b5) Well I've got problem with release 2.59 and 2.60b5, siege seems to sleep ? (using HTTP 1.1) siege -u http://machone/HelloWorldExample.html -b -r10 -c16 ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Tim Funk wrote: Try siege: http://joedog.org/siege/ Despite what the docs say, it runs pretty sweet on cygwin too. (with 2.60b5) Well I've got problem with release 2.59 and 2.60b5, siege seems to sleep ? (using HTTP 1.1) siege -u http://machone/HelloWorldExample.html -b -r10 -c16 ;( The problems disappears when i change connection = keep-alive to connection = close Bad, I wanted to test HTTP 1.1 with keep-alive ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2.0.50 in - Apache 2.0.50 alone (simple html file) - TC 3.3.2/Coyote 1.1 - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2 JkMount /examples/* local worker.local.port=8009 worker.local.host=localhost worker.local.type=ajp13 worker.local.cachesize=16 worker.local.cache_timeout=600 worker.local.socket_keepalive=1 worker.local.socket_timeout=300 - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1). ProxyPass /tc3/ http://localhost:11011/ ProxyPassReverse /tc3/ http://localhost:11011/ Apache Bench is running on another machine, Windows 2000 P3 1Ghz, and both systems are on a switched 100Mbps network : Apache 2 alone 1202 req/s TC/Coyote 883 req/s Apache 2 + jk + TC906 req/s Apache 2 + proxy + TC497.req/s(but with 8000 errors ;( Constatation : - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower than the Apache 2 native HTTP. - mod_proxy is 50% slower than mod_jk and that's a really bad news. Also many errors appears, about 4% errors. - Tomcat via jk or mod_proxy, when on the same machine make a cpu load of 60% system and 30% user. Tomcat alone is 33% system and 10% user. How could we optimize mod_proxy settings since I'm using the standard httpd.conf ? It's quite bad :( Did you check everything was ok using verbose ? ab -n 1 -v 10 All your tests show Keep-Alive requests:0 in the result. It should work ok with Tomcat standalone (to be honest, I didn't try 3.3 with the current HTTP/1.1 connector), and with Apache as well. ab uses HTTP/1.0 keepalive with the -k option. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2.0.50 in - Apache 2.0.50 alone (simple html file) - TC 3.3.2/Coyote 1.1 - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2 JkMount /examples/* local worker.local.port=8009 worker.local.host=localhost worker.local.type=ajp13 worker.local.cachesize=16 worker.local.cache_timeout=600 worker.local.socket_keepalive=1 worker.local.socket_timeout=300 - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1). ProxyPass /tc3/ http://localhost:11011/ ProxyPassReverse /tc3/ http://localhost:11011/ Apache Bench is running on another machine, Windows 2000 P3 1Ghz, and both systems are on a switched 100Mbps network : Apache 2 alone 1202 req/s TC/Coyote 883 req/s Apache 2 + jk + TC906 req/s Apache 2 + proxy + TC497.req/s(but with 8000 errors ;( Constatation : - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower than the Apache 2 native HTTP. - mod_proxy is 50% slower than mod_jk and that's a really bad news. Also many errors appears, about 4% errors. - Tomcat via jk or mod_proxy, when on the same machine make a cpu load of 60% system and 30% user. Tomcat alone is 33% system and 10% user. How could we optimize mod_proxy settings since I'm using the standard httpd.conf ? It's quite bad :( Did you check everything was ok using verbose ? ab -n 1 -v 10 All your tests show Keep-Alive requests:0 in the result. It should work ok with Tomcat standalone (to be honest, I didn't try 3.3 with the current HTTP/1.1 connector), and with Apache as well. ab uses HTTP/1.0 keepalive with the -k option. Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it with JMeter :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
the nightly build of jmeter has an alpha sampler that uses Commons HTTPClient. you may want to try that one instead, if you use jmeter peter On Thu, 22 Jul 2004 15:09:19 +0200, Henri Gomez [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2.0.50 in - Apache 2.0.50 alone (simple html file) - TC 3.3.2/Coyote 1.1 - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2 JkMount /examples/* local worker.local.port=8009 worker.local.host=localhost worker.local.type=ajp13 worker.local.cachesize=16 worker.local.cache_timeout=600 worker.local.socket_keepalive=1 worker.local.socket_timeout=300 - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1). ProxyPass /tc3/ http://localhost:11011/ ProxyPassReverse /tc3/ http://localhost:11011/ Apache Bench is running on another machine, Windows 2000 P3 1Ghz, and both systems are on a switched 100Mbps network : Apache 2 alone 1202 req/s TC/Coyote 883 req/s Apache 2 + jk + TC906 req/s Apache 2 + proxy + TC497.req/s(but with 8000 errors ;( Constatation : - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower than the Apache 2 native HTTP. - mod_proxy is 50% slower than mod_jk and that's a really bad news. Also many errors appears, about 4% errors. - Tomcat via jk or mod_proxy, when on the same machine make a cpu load of 60% system and 30% user. Tomcat alone is 33% system and 10% user. How could we optimize mod_proxy settings since I'm using the standard httpd.conf ? It's quite bad :( Did you check everything was ok using verbose ? ab -n 1 -v 10 All your tests show Keep-Alive requests:0 in the result. It should work ok with Tomcat standalone (to be honest, I didn't try 3.3 with the current HTTP/1.1 connector), and with Apache as well. ab uses HTTP/1.0 keepalive with the -k option. Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it with JMeter :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Peter Lin wrote: the nightly build of jmeter has an alpha sampler that uses Commons HTTPClient. you may want to try that one instead, if you use jmeter peter made some tests with JMeter 2.0.1 but my laptop is way to slow. I need another smaller stress tool ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
you can run it in non-Gui mode with -n option. http://jakarta.apache.org/jmeter/usermanual/get-started.html#non_gui might help, or not. peter On Thu, 22 Jul 2004 15:33:41 +0200, Henri Gomez [EMAIL PROTECTED] wrote: Peter Lin wrote: the nightly build of jmeter has an alpha sampler that uses Commons HTTPClient. you may want to try that one instead, if you use jmeter peter made some tests with JMeter 2.0.1 but my laptop is way to slow. I need another smaller stress tool ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Remy Maucherat wrote: Henri Gomez wrote: I made some benchs on my Linux Fedora Core 2 on a P4 2.8ghz / 1Gb RAM : Apache 2.0.50 in - Apache 2.0.50 alone (simple html file) - TC 3.3.2/Coyote 1.1 - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2 JkMount /examples/* local worker.local.port=8009 worker.local.host=localhost worker.local.type=ajp13 worker.local.cachesize=16 worker.local.cache_timeout=600 worker.local.socket_keepalive=1 worker.local.socket_timeout=300 - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1). ProxyPass /tc3/ http://localhost:11011/ ProxyPassReverse /tc3/ http://localhost:11011/ Apache Bench is running on another machine, Windows 2000 P3 1Ghz, and both systems are on a switched 100Mbps network : Apache 2 alone 1202 req/s TC/Coyote 883 req/s Apache 2 + jk + TC906 req/s Apache 2 + proxy + TC497.req/s(but with 8000 errors ;( Constatation : - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower than the Apache 2 native HTTP. - mod_proxy is 50% slower than mod_jk and that's a really bad news. Also many errors appears, about 4% errors. - Tomcat via jk or mod_proxy, when on the same machine make a cpu load of 60% system and 30% user. Tomcat alone is 33% system and 10% user. How could we optimize mod_proxy settings since I'm using the standard httpd.conf ? It's quite bad :( Did you check everything was ok using verbose ? ab -n 1 -v 10 All your tests show Keep-Alive requests:0 in the result. It should work ok with Tomcat standalone (to be honest, I didn't try 3.3 with the current HTTP/1.1 connector), and with Apache as well. ab uses HTTP/1.0 keepalive with the -k option. Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it with JMeter :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is 1.1 is that correct? The request was (from ab): +++ GET /examples/ HTTP/1.0^M User-Agent: ApacheBench/2.0.40-dev^M Connection: Keep-Alive^M Host: localhost:7779^M Accept: */*^M ^M +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is 1.1 is that correct? The request was (from ab): +++ GET /examples/ HTTP/1.0^M User-Agent: ApacheBench/2.0.40-dev^M Connection: Keep-Alive^M Host: localhost:7779^M Accept: */*^M ^M +++ I'm still looking for a bench tester supporting HTTP 1.1, jmeter is too hog for my PIII 1Ghz ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Hi, Does wget support HTTP/1.1? Yoav Shapira Millennium Research Informatics -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 12:36 PM To: Tomcat Developers List Subject: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev jean-frederic clere wrote: mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is 1.1 is that correct? The request was (from ab): +++ GET /examples/ HTTP/1.0^M User-Agent: ApacheBench/2.0.40-dev^M Connection: Keep-Alive^M Host: localhost:7779^M Accept: */*^M ^M +++ I'm still looking for a bench tester supporting HTTP 1.1, jmeter is too hog for my PIII 1Ghz ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Try siege: http://joedog.org/siege/ Despite what the docs say, it runs pretty sweet on cygwin too. (with 2.60b5) -Tim Henri Gomez wrote: jean-frederic clere wrote: mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is 1.1 is that correct? The request was (from ab): +++ GET /examples/ HTTP/1.0^M User-Agent: ApacheBench/2.0.40-dev^M Connection: Keep-Alive^M Host: localhost:7779^M Accept: */*^M ^M +++ I'm still looking for a bench tester supporting HTTP 1.1, jmeter is too hog for my PIII 1Ghz ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
