[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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik - Dev wrote: ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness (the cookie way is intrusive, and the IP way is highly inaccurate). Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Tim Funk wrote: *Changes to tomcat* Add a proxy mode flag to allow for the X- headers to pass authentication and other variables. Add to the manager(?) app and method to expose all the URL spaces availble. Minor changes to fix getRemoteAddr() to show the client, not the apache server. Pros - Simple(?) and not tomcat specific. Cons - Duplicate (re)parsing of headers, probably higher latency than jk. The changes would have to be simple, and non intrusive performance wise. Otherwise, I'm going to prefer AJP ;) Speaking about performance, did anyone do a comparison of mod_proxy against mod_jk to see how good/bad it is ? This is really important information IMO, and I don't see how a decision can be made without it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: really, so then there is no fail over. Yes there are. In Jk default is to fail over always. The JK2 has a routeRedirect to handle such cases (but not strictly). If the routeRedirect is down it will still fail over, which is probably incorrect. cause that is what fail over does, redirects you to another server. and with session replication in place, you should be good to go Sure if you've set up many-to-many session replication. We should have something like: If we have a session route but the worker is down If there is a routeRedirect then If the routeRedirect worker is down return 500 Else return routeRedirect Else Fail over to another worker Else return sessionWorker Basically it means that if the redirection worker is down don't fail over, but rather break the transaction. It enables single session replication node. I don't care if the fail over will be turned on by default or not, but would like to have a control in cases where either there are: A) session replication is in place on all nodes B) session replication is done on a single node C) there is no session replication at all Like said the JK presumes there is A, JK2 handles both A and B cases (but it should C too). MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Filip Hanik wrote: really, so then there is no fail over. Yes there are. In Jk default is to fail over always. The JK2 has a routeRedirect to handle such cases (but not strictly). If the routeRedirect is down it will still fail over, which is probably incorrect. cause that is what fail over does, redirects you to another server. and with session replication in place, you should be good to go Sure if you've set up many-to-many session replication. We should have something like: If we have a session route but the worker is down If there is a routeRedirect then If the routeRedirect worker is down return 500 Else return routeRedirect Else Fail over to another worker Else return sessionWorker Basically it means that if the redirection worker is down don't fail over, but rather break the transaction. It enables single session replication node. I don't care if the fail over will be turned on by default or not, but would like to have a control in cases where either there are: A) session replication is in place on all nodes B) session replication is done on a single node C) there is no session replication at all Like said the JK presumes there is A, JK2 handles both A and B cases (but it should C too). MT. I am looking to get the sessionid: - By reading request_rec-unparsed_uri or request_rec-uri. - By reading the cooky from request_rec-headers_in. How do I read the sessionid in the response? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Speaking about performance, did anyone do a comparison of mod_proxy against mod_jk to see how good/bad it is ? This is really important information IMO, and I don't see how a decision can be made without it. Results a quite impressive, good question Remy :) Tomcat 5.0.27 + Apache 2.0.50 All tests done on a clean startup with empty logs. ProxyPass /servlets-examples/ http://localhost:8080/servlets-examples/ ProxyPassReverse /servlets-examples/ http://localhost:8080/servlets-examples/ Ab -n 1000 Time taken for tests: 4.226077 seconds Mod_jk-1.26 JkWorkersFile conf/workers.properties JkMount /servlets-examples/* ajp13 Time taken for tests: 2.824061 seconds A lot, lot faster. What is more interesting is when you increase the number of loops forom 1000 to 1 Ab -n 1 Time taken for tests: 239.614549 seconds Complete requests: 1 Failed requests:7011 Using mod_jk: Ab -n 1 Time taken for tests: 21.811363 seconds Complete requests: 1 Failed requests:0 So, mod_proxy is a lot slower and doesn't handle load. (Perhaps increasing http listeners on TC would help). MT. smime.p7s Description: S/MIME cryptographic signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
In previous mail I forgot one crucial result: Ab -n 1000 directly to TC Time taken for tests: 1.882708 seconds Ab -n 1 directly to TC Time taken for tests: 17.244797 seconds I'll leave the calculation to others. MT. smime.p7s Description: S/MIME cryptographic signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: I am looking to get the sessionid: - By reading request_rec-unparsed_uri or request_rec-uri. - By reading the cooky from request_rec-headers_in. How do I read the sessionid in the response? Good point. We'll need something like mod_proxy_html or something like that to parse the headers returned from Remote. Cannot speak for sure, cause I still have some problems figuring out the mod_proxy algorithm. It's getting more and more complicated :). MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote, On 7/21/2004 11:33 PM: The changes would have to be simple, and non intrusive performance wise. Otherwise, I'm going to prefer AJP ;) Speaking about performance, did anyone do a comparison of mod_proxy against mod_jk to see how good/bad it is ? This is really important information IMO, and I don't see how a decision can be made without it. I did a couple quick tests using a few different sized static documents using ab, Tomcat 5.0.27, Apache 2.0.50 both on the same single CPU machine. Depending on the document size, mod_proxy was anywhere from 50% (very small document of a few bytes) to 10% (30k document) slower than mod_jk. By comparison, going directly to Tomcat about twice as fast as using mod_jk, and going directly to Apache is another 30% faster than that. Watching CPU utilization when switching between mod_jk and mod_proxy showed that Tomcat uses a lot more CPU when using mod_proxy than when using mod_jk. So while the performance hit isn't negligible, it's not too bad. It does show that it will be worthwhile to a proxy_ajp_module, but at the same time I think that using plain http provides more than enough performance for the majority of users out there, and you can't argue with the fact that the work will benefit a lot more than just Tomcat and lessen development time. I could see people using the proposed load-balancing functionality along with mod_proxy to balance requests to clusters of many other application servers (PHP, perl, CGI, etc) as well. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Filip Hanik - Dev wrote: ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness (the cookie way is intrusive, and the IP way is highly inaccurate). Well it seems the discussion advance quickly and on the right direction, a true ASF members colaboration. I made some benchs yesterday on my laptop between : - TC 3.3.2/Coyote - Apache 2.0.49 alone (simple html file) - Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2 - Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2 - Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1). I'll redo them today on a faster machines since the results where a little too random but the benchs raise some questions : - I'm using ab (ApacheBench) and wonder if the -k (keep alive) if HTTP keep-alive is really used ? - Did mod_proxy keep a connection cache ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Ab -n 1 Time taken for tests: 239.614549 seconds Complete requests: 1 Failed requests:7011 So, mod_proxy is a lot slower and doesn't handle load. (Perhaps increasing http listeners on TC would help). Increasing the maxThreads to 350 and acceptCount to 300 doesn't solve the issue. On large load I'm getting the following using mod_proxy: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed Anyone has a clue where and why those error messages comes from? MT. smime.p7s Description: S/MIME cryptographic signature
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Remy Maucherat wrote: Filip Hanik - Dev wrote: ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness (the cookie way is intrusive, and the IP way is highly inaccurate). Well it seems the discussion advance quickly and on the right direction, a true ASF members colaboration. I made some benchs yesterday on my laptop between : - TC 3.3.2/Coyote - Apache 2.0.49 alone (simple html file) - Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2 - Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2 - Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1). I'll redo them today on a faster machines since the results where a little too random but the benchs raise some questions : - I'm using ab (ApacheBench) and wonder if the -k (keep alive) if HTTP keep-alive is really used ? Why? Remember to run ab on a separate (fast) machine otherwise the results are random ;-) - Did mod_proxy keep a connection cache ? It does not close the socket to the proxy when using HTTP/1.1 and Connection: is not close. - 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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Ab -n 1 Time taken for tests: 239.614549 seconds Complete requests: 1 Failed requests:7011 So, mod_proxy is a lot slower and doesn't handle load. (Perhaps increasing http listeners on TC would help). Increasing the maxThreads to 350 and acceptCount to 300 doesn't solve the issue. On large load I'm getting the following using mod_proxy: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed Anyone has a clue where and why those error messages comes from? Could you try ab -k? - mod_proxy will reuse the socket - MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: I made some benchs yesterday on my laptop between : - TC 3.3.2/Coyote - Apache 2.0.49 alone (simple html file) - Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2 - Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2 - Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1). I'll redo them today on a faster machines since the results where a little too random but the benchs raise some questions : - I'm using ab (ApacheBench) and wonder if the -k (keep alive) if HTTP keep-alive is really used ? I do my testing with -k usually, and with something like -c 20, to get an average load level (I'm using that on Cygwin, so high concurrency does't quite work in localhost). It seems like keepalive is being used often, and this factors out some of the network stack overhead when I'm profiling stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed Anyone has a clue where and why those error messages comes from? Could you try ab -k? - mod_proxy will reuse the socket - Still the same messages. When running ab on the same host where apache and TC are located I'm getting between 3-16 errors on '-n 1000', But when using remote machine and use the ab from remote I'm getting around 50% error requests; cca. 450 - 520 requests gets failed. The number of failed requests gets lower and lower when I run same ab in a series, and it get more and more random, varying from 0 - 50 %. Interesting is that rising concurrency level to 20 or more, lowers the error number, but It's still around 10% (1120 from 1 request are 502). Very strange and totally unusable at least on WIN32. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: jean-frederic clere wrote: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed Anyone has a clue where and why those error messages comes from? Could you try ab -k? - mod_proxy will reuse the socket - Still the same messages. When running ab on the same host where apache and TC are located I'm getting between 3-16 errors on '-n 1000', But when using remote machine and use the ab from remote I'm getting around 50% error requests; cca. 450 - 520 requests gets failed. The number of failed requests gets lower and lower when I run same ab in a series, and it get more and more random, varying from 0 - 50 %. Interesting is that rising concurrency level to 20 or more, lowers the error number, but It's still around 10% (1120 from 1 request are 502). Very strange and totally unusable at least on WIN32. Well ab running on Win32 didn't very stable ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: jean-frederic clere wrote: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed Anyone has a clue where and why those error messages comes from? Could you try ab -k? - mod_proxy will reuse the socket - Still the same messages. When running ab on the same host where apache and TC are located I'm getting between 3-16 errors on '-n 1000', Don't run ab on the same host, otherwise you are benching ab. But when using remote machine and use the ab from remote I'm getting around 50% error requests; cca. 450 - 520 requests gets failed. The number of failed requests gets lower and lower when I run same ab in a series, and it get more and more random, varying from 0 - 50 %. Interesting is that rising concurrency level to 20 or more, lowers the error number, but It's still around 10% (1120 from 1 request are 502). I also I have some (40) errors with concurrency 300 but Tomcat and Apache are in 2 different machines: +++ [Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy: DNS lookup failure for: pgtr0327.mch.fsc.net returned by /examples/servlet/HelloWorldExample +++ Very strange and totally unusable at least on WIN32. Use a real operating system. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
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 + TC 906 req/s Apache 2 + proxy + TC 497.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 ? -- Complete bench results : Apache 2.0.50 alone (simple html file) C:\Program Files\Apache Group\Apache2\binab -k -n 20 -c 16 http://machone/HelloWorldExample.html This is ApacheBench, Version 2.0.40-dev $Revision: 1.121.2.8 $ apache-2.0 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking machone (be patient) Completed 2 requests Completed 4 requests Completed 6 requests Completed 8 requests Completed 10 requests Completed 12 requests Completed 14 requests Completed 16 requests Completed 18 requests Finished 20 requests Server Software:Apache/2.0.50 Server Hostname:machone Server Port:80 Document Path: /HelloWorldExample.html Document Length:459 bytes Concurrency Level: 16 Time taken for tests: 166.299127 seconds Complete requests: 20 Failed requests:0 Write errors: 0 Keep-Alive requests:0 Total transferred: 14580 bytes HTML transferred: 9180 bytes Requests per second:1202.65 [#/sec] (mean) Time per request: 13.304 [ms] (mean) Time per request: 0.831 [ms] (mean, across all concurrent requests) Transfer rate: 856.18 [Kbytes/sec] received Tomcat 3.3.2 using the Coyote 1.1 HTTP connector C:\Program Files\Apache Group\Apache2\binab -k -n 20 -c 16 http://machone:11011/examples/servlet/HelloWorldExample This is ApacheBench, Version 2.0.40-dev $Revision: 1.121.2.8 $ apache-2.0 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking machone (be patient) Completed 2 requests Completed 4 requests Completed 6 requests Completed 8 requests Completed 10 requests Completed 12 requests Completed 14 requests Completed 16 requests Completed 18 requests Finished 20 requests Server Software:Apache-Coyote/1.1 Server Hostname:machone Server Port:11011 Document Path: /examples/servlet/HelloWorldExample Document Length:400 bytes Concurrency Level: 16 Time taken for tests: 226.485671 seconds Complete requests: 20 Failed requests:0 Write errors: 0 Keep-Alive requests:0 Total transferred: 10540 bytes HTML transferred: 8000 bytes Requests per second:883.06 [#/sec] (mean) Time per request: 18.119 [ms] (mean) Time per request: 1.132 [ms] (mean, across all concurrent requests) Transfer rate: 454.46 [Kbytes/sec] received Apache 2.0.50 + jk 1.2.6 + Tomcat 3.3.2 (via Coyote JK2 connector) C:\Program Files\Apache Group\Apache2\binab -k -n 20 -c 16 http://machone/examples/servlet/HelloWorldExample This is ApacheBench, Version 2.0.40-dev $Revision: 1.121.2.8 $ apache-2.0 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking machone (be patient) Completed 2 requests Completed 4 requests Completed 6 requests Completed 8 requests Completed 10 requests Completed 12 requests Completed 14 requests Completed 16 requests Completed 18 requests Finished 20 requests Server Software:Apache/2.0.50 Server Hostname:machone Server Port:80 Document Path: /examples/servlet/HelloWorldExample Document Length:400 bytes Concurrency Level: 16 Time taken for tests: 220.637261 seconds Complete
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Very strange and totally unusable at least on WIN32. Well ab running on Win32 didn't very stable ;( Yeah, sure :) WTF then mod_jk doesn't produce such errors ? BTW, the errors reported comes from mod_proxy. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik - Dev wrote: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Yes. In other words, you start with a list of IPs (supplied by the config, resolved by DNS), and each load balancer module reorders the IP addresses in turn, as needed. So a load balancer module will reorder the IPs least loaded to most loaded. Then the sticky module will either do nothing to list, or it will notice a sticky session, and move the sticky IP address to the top of the list. Thing is for the sticky module to be effective, it must run last, otherwise the load balancer will undo sticky's work. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Tim Funk wrote: I'm not sure of the status so far, but I'd like to summarize a strawman. I have no idea how to code this at this time or if it can be done. No problem, we drill down into the details as we go along :) *Config* [Feel free to change the names] ProxyClient http://server1/config.xml ProxyClient http://server2/config.xml ProxyClient http://server3/another/config.xml ProxyUpdate /proxyconfig The config should follow the established config for proxy, which would be this: ProxyPass /myWebapp ajp://server1/myWebapp At the moment, server1 would resolve to multiple names, however a userful addition would be ability to do this: ProxyPass /myWebapp ajp://server1 server2 server3/myWebapp which is the way LDAP URLs handle multiple possible servers. *Startup* Apache polls each proxy-client for existence and config at the URL defined by te ProxyClient directive. Each proxy-client states the paths/extension/mimetype/??? it can serve as well as its weight. It is the job of proxy_ajp to understand what ajp://server1 server2 server3/myWebapp means. What proxy_ajp can do, if it has not already done so, is poll the servers in the server list and say hey guys, which of you lot serves myWebapp? All of you? Ok cool bananas - the top of the list of IPs I have been given is you server1, so go ahead, knock yourself out. *On going* Apache periodically polls the config URL for changes. --or-- A proxy-client can join, remove, alter URL availability by using making a request to apache defined at ProxyUpdate. proxy_ajp need not poll - it can do so as the request arrives. If proxy_ajp connects to the backend, and that backend returns 5xx, then proxy_ajp says Oops, obviously not serving any more, let me try the next IP in my list and see if that one is willing to serve my request. *Edge cases* Authentication, environment variables, and other system parameters would be passed to the proxy via X-Headers. Apache would need to deny/filter these header names from outside clients. I don't understand - are these headers created by tomcat, and passed towards the client, or created by the client, and passed towards tomcat? Either way, funky header handling would be done by proxy_ajp. *stickyness* unknown how to fix this in a generic manner Using a completely separate and independant module called proxy_sticky, which uses a hook I will be putting into proxy sometime this weekend. :) *Failover* 2 cases 1) server unavailable - easy to recover since a new connection is made 2) server available but doesn't handle request anymore - Proxy-client returns a custom header to let apache move to next node? No need for a custom header - just interpret the response codes correctly. 5xx means try the next server in the list, if you run out of list, pass the error back up to the client. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness Can you describe the jvmRoute method to me? (the cookie way is intrusive, and the IP way is highly inaccurate). I agree on the IP way being inaccurate (and have argued long and hard against people who couldn't understand that the same browser could easily come in from one of many IP addresses, changing all the time as they go). Currently tomcat handles sessions as either a) a cookie or b) a parameter. We could easily teach proxy_sticky that stickiness is based on either of these two. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: - I'm using ab (ApacheBench) and wonder if the -k (keep alive) if HTTP keep-alive is really used ? - Did mod_proxy keep a connection cache ? Proxy's HTTP module will reuse the same connection from previous connections if keepalives are being used, it doesn't keep a connection cache for more than one connection at a time. This behaviour is limited to proxy_http though. There is nothing inside proxy that would prevent proxy_ajp from keeping a connection cache. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: BTW, the errors reported comes from mod_proxy. What are the errors though, and do they come from mod_proxy or mod_proxy_http? It would be a huge help to the people using proxy (ie for non tomcat related stuff) if we could find and fix these error conditions under load. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Remy Maucherat wrote: It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness Can you describe the jvmRoute method to me? It's really dumb: we append the node name to the session id when it's generated (it ends up as the JSESSIONID cookie value). Of course, the downside is that you have to configure stuff on each node :/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: I also I have some (40) errors with concurrency 300 but Tomcat and Apache are in 2 different machines: +++ [Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy: DNS lookup failure for: pgtr0327.mch.fsc.net returned by ^^ /examples/servlet/HelloWorldExample +++ Very strange and totally unusable at least on WIN32. Use a real operating system. Or a decent DNS server :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: jean-frederic clere wrote: I also I have some (40) errors with concurrency 300 but Tomcat and Apache are in 2 different machines: +++ [Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy: DNS lookup failure for: pgtr0327.mch.fsc.net returned by ^^ /examples/servlet/HelloWorldExample +++ Very strange and totally unusable at least on WIN32. Use a real operating system. Or a decent DNS server :) It's not normal there's a DNS lookup on each request. Why does it happen ? +1 on using a real OS ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote:
Mladen Turk wrote:
BTW, the errors reported comes from mod_proxy.
What are the errors though, and do they come from mod_proxy
or mod_proxy_http?
All are exactly the same:
[error] (OS 10048)Only one usage of each socket address (protocol/network
address/port) is normally permitted. : proxy: HTTP: attempt to connect to
127.0.0.1:8080 (localhost) failed
It would be a huge help to the people using proxy (ie for non
tomcat related stuff) if we could find and fix these error
conditions under load.
We had a same problen in jk for over two years now. The problem is that you
will need at least:
Line 1037 in proxy_util.c:
/* make the connection out of the socket */
do {
rv = apr_socket_connect(*newsock, backend_addr);
} while (APR_STATUS_IS_EINTR(rv));
But again it might be just an attemp to connect to an nonclosed connection
(as BTW the error suggests), or perhaps connection beeing in the process of
disconnection, but cause of high load you have a race condition.
MT.
smime.p7s
Description: S/MIME cryptographic signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: +1 on using a real OS ;) Well, you could also use a real programming language for start ;-). MT. smime.p7s Description: S/MIME cryptographic signature
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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: DNS lookup failure for: pgtr0327.mch.fsc.net returned by ^^ It's not normal there's a DNS lookup on each request. Why does it happen ? In the config it was set to connect to a DNS name, which has to be resolved - but httpd doesn't do any caching of this (which in theory would be the job of a caching DNS server), thus a lookup on each request. Perhaps an enhancement to proxy_http would be to support DNS caching for a period of time. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote:
All are exactly the same:
[error] (OS 10048)Only one usage of each socket address (protocol/network
address/port) is normally permitted. : proxy: HTTP: attempt to connect to
127.0.0.1:8080 (localhost) failed
Ok.
We had a same problen in jk for over two years now. The problem is that you
will need at least:
Line 1037 in proxy_util.c:
/* make the connection out of the socket */
do {
rv = apr_socket_connect(*newsock, backend_addr);
} while (APR_STATUS_IS_EINTR(rv));
But again it might be just an attemp to connect to an nonclosed connection
(as BTW the error suggests), or perhaps connection beeing in the process of
disconnection, but cause of high load you have a race condition.
So if I committed the above patch to httpd v2.1.0-dev would you be in a
position to test it?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Graham Leggett wrote: jean-frederic clere wrote: I also I have some (40) errors with concurrency 300 but Tomcat and Apache are in 2 different machines: +++ [Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy: DNS lookup failure for: pgtr0327.mch.fsc.net returned by ^^ /examples/servlet/HelloWorldExample +++ Very strange and totally unusable at least on WIN32. Use a real operating system. Or a decent DNS server :) It's not normal there's a DNS lookup on each request. Why does it happen ? Not for each request but each time http makes a new connection to Tomcat. We have to cache the result of apr_sockaddr_info_get(). +1 on using a real OS ;) Rémy - 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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote:
/* make the connection out of the socket */
do {
rv = apr_socket_connect(*newsock, backend_addr);
} while (APR_STATUS_IS_EINTR(rv));
One further question (I am not 100% clued up on the workings of apr's
socket handling) - would a situation ever arise where
APR-STATUS_IS_EINTR(rv) would always return non zero, causing an
infinite loop?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
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: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: Not for each request but each time http makes a new connection to Tomcat. We have to cache the result of apr_sockaddr_info_get(). Added to bugzilla as a request for enhancement (so this doesn't fall through the cracks). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: So if I committed the above patch to httpd v2.1.0-dev would you be in a position to test it? No, I've tested it. Still has the same error messages. OS error 10048 means: Typically, only one usage of each socket address (protocol/IP address/port) is permitted. This error occurs if an application attempts to bind a socket to an IP address/port that has already been used for an existing socket, or a socket that was not closed properly, or one that is still in the process of closing. For server applications that need to bind multiple sockets to the same port number, consider using setsockopt (SO_REUSEADDR). MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote:
We had a same problen in jk for over two years now. The problem is that you
will need at least:
Line 1037 in proxy_util.c:
/* make the connection out of the socket */
do {
rv = apr_socket_connect(*newsock, backend_addr);
} while (APR_STATUS_IS_EINTR(rv));
Added to bugzilla as 30260.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: OS error 10048 means: Typically, only one usage of each socket address (protocol/IP address/port) is permitted. This error occurs if an application attempts to bind a socket to an IP address/port that has already been used for an existing socket, or a socket that was not closed properly, or one that is still in the process of closing. For server applications that need to bind multiple sockets to the same port number, consider using setsockopt (SO_REUSEADDR). Could this be the problem? Maybe proxy is not closing sockets properly. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: jean-frederic clere wrote: Not for each request but each time http makes a new connection to Tomcat. We have to cache the result of apr_sockaddr_info_get(). Added to bugzilla as a request for enhancement (so this doesn't fall through the cracks). That is PR 30259. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Please help me to unsubscribe me from the tomcat and relatives forum. I already send a lot of mails to the mayordomo with the words unsubscribe but im still receiving mail. Please help me. thanks fernando R Torrijos _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Fernando R. Torrijos wrote: Please help me to unsubscribe me from the tomcat and relatives forum. I already send a lot of mails to the mayordomo with the words unsubscribe but im still receiving mail. Please help me. Please follow the instructions at the bottom of the emails you have received, which are: To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: used for an existing socket, or a socket that was not closed properly, or one that is still in the process of closing. For server applications that need to bind multiple sockets to the same port number, consider using setsockopt (SO_REUSEADDR). Could this be the problem? Maybe proxy is not closing sockets properly. If you turn the loglevel to debug then there is no error messages (although everything is by the order of magnitude slower), so the closing algorithm is correct. The problem is IMHO that you are using a socket (presuming it is free) still served by the bucket brigade, but I may be wrong. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: If you turn the loglevel to debug then there is no error messages (although everything is by the order of magnitude slower), so the closing algorithm is correct. The problem is IMHO that you are using a socket (presuming it is free) still served by the bucket brigade, but I may be wrong. MT. Can you look at the comments at http://issues.apache.org/bugzilla/show_bug.cgi?id=30260 - apparently this may be a Windows specific problem. I'm a unix type, so the windows issues are not something I am familiar with. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Graham Leggett wrote: Remy Maucherat wrote: It's cool to have one less thing to configure, but it seems to me jvmRoute is the most reliable and efficient way of doing stickiness Can you describe the jvmRoute method to me? It's really dumb: we append the node name to the session id when it's generated (it ends up as the JSESSIONID cookie value). Of course, the downside is that you have to configure stuff on each node :/ Or we could have a reasonable default - like the ajp ip/port of the host ( or md5 of it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote:
Can you look at the comments at
http://issues.apache.org/bugzilla/show_bug.cgi?id=30260 -
apparently this may be a Windows specific problem.
Could be, or not.
If for example after connect I write:
if (rv == 730048) {
apr_socket_close(*newsock);
*newsock = NULL;
continue;
}
It goes in an infinite loop, but it should not.
I'm a unix type, so the windows issues are not something I am
familiar with.
Think that has nothing to do with windows (I even lowered the thread count
to 50), but not sure.
If someone wishes to check that on some worker mpm with high thread count.
It serves 1995 conections, either ab -n 2000 or 2 x ab -n 1000 (the first
one has no errors, the second has 5 errors).
After that any attempt to connect to mod_proxy returns 503.
I've spend couple of hours trying to find the bug, or at least the reason,
but I'm slightly loosing the interest.
Regards,
MT.
smime.p7s
Description: S/MIME cryptographic signature
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]
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers), apr_pool_t... Next advanced AJP functions will forward a complete Apache 2 request to a tomcat. Many objects part of the Ap2 request are allready available in the Basic AJP functions, ie for headers the apr_table_entry_t... We could then work on a mod_ajp prototype, using only env var for example, to redirect a request to the correct named ajp instance (don't speak about worker). With such simple prototype we could see which hooks should be implemented, probably only ap_hook_handler/ap_hook_post_config. Actually jk 1.2.x may implements too many hooks, I didn't see any Apache 2 modules with all of these : ap_hook_handler(jk_handler,NULL,NULL,APR_HOOK_MIDDLE);
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Make sense of course. And if proxy_loadbalance and proxy_sticky are somewhat configurable, it will be to the benefits all of Apache 2 users, dependless HTTP/FTP/AJP. BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? That would be up to proxy_ajp to decide, so yes. What happens is that when the config says ProxyPass /myApp ajp://VIRTUALNAME and the user requests the URL /myApp/index.jsp, proxy will give proxy_ajp an URL that looks like this: ajp://VIRTUALNAME/index.jsp It's up to proxy_ajp to understand what that means. Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. Proxy already loops around and tries again on connection failure to a different server in the backend. If proxy cannot handle a 503 or a 400, then it can be made to handle it - again it's a feature that would be really useful regardless of the protocol. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. I don't follow - what does normalisation would lead to nowhere mean? HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. You are missing the purpose of mod_proxy. It is not an HTTP proxy only, but a general protocol proxy that can support both stateless and stateful backends. Proxy supports HTTP keepalives (via a mechanism that can be extended into a full pool), and it supports FTP (a stateful protocol). There is no reason why proxy could not support another stateful protocol like AJP. If httpd is to support another backend protocol, then the proxy frameowrk is the place to do it. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? Considering that httpd already has a framework to connect to various backend protocols (proxy and friends), and already has an established syntax within httpd, I don't see any point in replacing it with another external module like the existing mod_jk2. Are you willing to write the ftp module for mod_jk2? Again, application server != http server. Of course an http server is an application server. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. I think there is a fundamental misunderstanding as to the way proxy works. mod_proxy is a framework - the module is not useful on it's own without helper modules plugged into the back of it. Right now, there are helper modules to support HTTP/1.1, FTP and HTTP/1.1's CONNECT method. mod_proxy currently handles the connection to the backend, it then passes this connection to the protocol handler module for completion. This connection handling can easily be pulled out into a load balancing module, allowing connections to the backend to be reused for HTTP keepalives, FTP session continuation and a connection pool for AJP, or a proxy_sticky module, that is able to ensure the same requests go to the same server. The bottom line is that httpd has an established framework for supporting backend application server protocols like HTTP, FTP, and now AJP. So far I have seen no technical justification whatsoever for putting an AJP protocol module outside of this framework. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? ap_proxy_http_handler() is found in mod_proxy_http, which is the helper module that handles the HTTP protocol in the proxy framework. You will find a corresponding ap_proxy_ftp_handler() inside mod_proxy_ftp. mod_proxy tries each handler in turn until one of the handlers says I can serve this URL, I'll take it. ap_proxy_http_handler() will return DECLINED if the URL of the backend is not http: or https:, allowing mod_proxy_ftp, mod_proxy_connect or a potential mod_proxy_ajp to have a go at trying serve the URL. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. We already have a bunch of modules that can use WTF protocol you wish, but no one can configure or use it without reading 500 page book that doesn't even exists. - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done I'm sure it can, but like I said, you can mimic the mod_proxy inside jk2. It also can be done :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. Remember the end goal of the exercise is to produce software which solves a real world need of end users. One of the biggest real world end user needs is something simple and straightforward that lets me get the job done with the least amount of time wasted messing around. As a user, I would ask why is the config for mod_jk different for mod_proxy?, and in fact as a user that's the exact reason I don't bother to use mod_jk. The easiest way to make the config method for mod_proxy and mod_jk the same is to implement proxy_ajp. There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. Compromises like what? I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. mod_proxy_http communicates with an HTTP server, nothing less, nothing more. It doesn't cache, it doesn't do anything - that's the job of other httpd modules like mod_dir, mod_cache, etc. mod_proxy_ftp communicates with an FTP server, nothing less, nothing more. mod_proxy_ajp would communicate via AJP. Nothing less, nothing more. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. That's all OK. Look at the mail archive and you will see that this is exactly the 'look and feel' that we wish to achieve. Compromises like what? AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? Regards, MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! The tiny performance benefit of a binary protocol is really not worth it. The 'http parsing' part is very small anyway. Most other problems can be solved with mod_proxy - including passing all auth headers and informations about original request in special headers, load balancing with all the flavors, etc. ( and security issues with the custom headers can be resolved as well ). I agree with Mladen that plugable protocol proved to be unnecesary, and it would be a bad idea for mod_proxy. Costin Henri Gomez wrote: Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers),
Re: Invitation to HTTPD commiters in tomcat-dev
- Original Message - From: Mladen Turk [EMAIL PROTECTED] I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). yes, but it is rocket science to actually get jk2 compiled and configured and to work properly. mod_proxy is part of the core, and takes about 5 seconds to setup. That is the biggest difference the current user base is experiencing today. I've been on three commercial projects where mod_jk2 has been dropped and replaced with mod_proxy, (and not on my recommendation). That alone speaks for itself. If the successor of jk2 can be as easy to configure and setup with apache, then go for it. Otherwise I humble suggestion would be to start looking that direction. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? AjpBalancer could be applied to a theoretical proxy_balancer module (all modules can define their own config parameters, even the helper modules, the only guideline is that the config directives are named to give some indication of the scope they're valid for, so instead of a directive called Fred which doesn't mean anything to anybody, it should be ProxyAjpFred). What does AjpWorker do? (Is there docs for mod_jk anywhere, when I last looked I could not find any). There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. Quite willing - the extra params can be defined as valid for the proxy_ajp module only, or extra general parameters can be added to the proxy framework. The idea is that if some feature has general application to all the modules (such as load balancing) then the change should be made to proxy and be applied system wide. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). Because of end user expectation. mod_proxy is currently the shipped with Apache option for backend protocol support. If suddenly mod_proxy and friends were turfed out and replaced with an entirely different module and different set of directives, people's reaction would be huh?. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? You could do that - although if you make changes to mod_proxy itself (which you very likely will have to do to support some of the stuff, like the adding of new hooks, etc) it would be best if these were posted as they happened to the [EMAIL PROTECTED] list, then they could be applied to httpd v2.1-dev, with potential backports going to v2.0. Doing this in bite sized pieces as needed would be a lot easier to review than a single big merge at the end, although keeping a local copy for yourselves to try things out first will also make your lives easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! I also find HTTP to be more than adequate in most cases, but if there is a need for AJP and people are going to use it then I don't see why people can't build and contribute to an ajp module. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? I have tried the following in httpd.conf: +++ Location /examples/ ProxyPass http://pgtr0327.mch.fsc.net:8080/examples/ ProxyPassReverse http://pgtr0327.mch.fsc.net:8080/examples/ /Location +++ pgtr0327.mch.fsc.net:8080 is a normal tomcat and something so simple covers already some needs. Adding load balancing means that we have to define several Tomcats (only changing host and/or port) and use JSESSIONID to find the right Tomcat when getting a request in httpd. This could be done in a modified proxy_http.c Cheers Jean-Frederic - 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: Invitation to HTTPD commiters in tomcat-dev
But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info yes, this is what alot of users want Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:27 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - 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]
Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Filip - Original Message - From: Graham Leggett [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:34 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? There is also a question of development cycle. Are we gonna develop sending patches or what... Suggestions? MT. smime.p7s Description: S/MIME cryptographic signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I didn't say anything about just simple round robin the algorithm for distribution can be entirely separate from the stickiness as they are two separate things. The distribution algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests. Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 11:30 AM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Filip Hanik wrote: The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: I didn't say anything about just simple round robin the algorithm for distribution can be entirely separate from the stickiness as they are two separate things. The distribution algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests. Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). In this case plan B could be simple DNS round robin, or it could be a load balancer, in other words another module entirely. This raises a question - what order do the modules run in? In theory the sticky module should run last, in other words a load balancer (or DNS round robin, or whatever) orders the IPs based on some criteria (load, or round robin, or whatever), and then the sticky module takes the sticky server identified by the cookie/parameter and moves that sticky IP on top of the list. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: GL Mladen Turk wrote: Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. GL In theory sticky sessions shouldn't be tightly coupled like this - it GL should be a case of plan a) stick to the same server, else revert to GL plan b). GL In this case plan B could be simple DNS round robin, or it could be a GL load balancer, in other words another module entirely. GL This raises a question - what order do the modules run in? In theory the GL sticky module should run last, in other words a load balancer (or DNS GL round robin, or whatever) orders the IPs based on some criteria (load, GL or round robin, or whatever), and then the sticky module takes the GL sticky server identified by the cookie/parameter and moves that sticky GL IP on top of the list. GL I suppose in this case the load balancer would run HOOK_MIDDLE, and GL sticky would run HOOK_LAST. GL Regards, GL Graham GL -- -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). Yes, but why would you wish to separate those? The stickiness is the part of load balancer, and merely flags the connection to a particular remote so that the load balancer can skip the Remote selection, cause it already selected the Remote in some previous transaction. Something different is the way the load balancer selects the Remote, and that can be separated if the separation is needed at all, but I doubt that. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: MT Graham Leggett wrote: sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). MT Yes, but why would you wish to separate those? MT The stickiness is the part of load balancer, and merely flags the connection MT to a particular remote so that the load balancer can skip the Remote MT selection, cause it already selected the Remote in some previous MT transaction. MT Something different is the way the load balancer selects the Remote, and MT that can be separated if the separation is needed at all, but I doubt that. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. MT I'm not that familiar with mod_proxy code, so please no hooks, not jet :) MT MT. -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. I would probably use the stickiness long before I started messing around with load balancing. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) So, where do you see a lb code in the mod_proxy tree. Do you have some ideas where will it fit? It would be also good if you could make some p-code of the mod_proxy or some data flow diagram. Also do you need our support on coding? It would be perhaps better that you write the function prototypes that need some lb behavior returnig somethig like not_implemented or just mark some /* TODO: ...*/ in the code. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 1:12 PM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) So, where do you see a lb code in the mod_proxy tree. Do you have some ideas where will it fit? It would be also good if you could make some p-code of the mod_proxy or some data flow diagram. Also do you need our support on coding? It would be perhaps better that you write the function prototypes that need some lb behavior returnig somethig like not_implemented or just mark some /* TODO: ...*/ in the code. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. FHD cool, and then have the server just try them in that order? FHD ie, if the sticky server went down, it just takes the next one FHD from the FHD list (and that list should be ordered well since it comes from the LB algorithm) FHD correct assumption? FHD Filip FHD - Original Message - FHD From: Mladen Turk [EMAIL PROTECTED] FHD To: 'Tomcat Developers List' [EMAIL PROTECTED] FHD Sent: Wednesday, July 21, 2004 1:12 PM FHD Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev FHD Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. FHD OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) FHD So, where do you see a lb code in the mod_proxy tree. Do you have some ideas FHD where will it fit? FHD It would be also good if you could make some p-code of the mod_proxy or some FHD data flow diagram. FHD Also do you need our support on coding? FHD It would be perhaps better that you write the function prototypes that need FHD some lb behavior returnig somethig like not_implemented or just mark some /* FHD TODO: ...*/ in the code. FHD MT. FHD - FHD To unsubscribe, e-mail: [EMAIL PROTECTED] FHD For additional commands, e-mail: FHD [EMAIL PROTECTED] -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Think that it should return 'Server Busy' in case the sticky is not available, cause you may be in the middle of transaction while the other server might have no clue about that. MT. smime.p7s Description: S/MIME cryptographic signature
