Re: Performance of APR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. We have multiple Tomcats running behind Apache, so this is a requirement for us, now. Making AJP work is pretty much a joke: compile, deploy, configure with JkMounts. I've never had any problems with it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmJ0QcACgkQ9CaO5/Lv0PDk4QCfa3LYOIzp4XiHrpoYZ2ioivdA fLsAoI6qEwafqJkcePLs7mUski1hGZum =V5mA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, Peter Crowther wrote: From: Leon Rosenberg [mailto:rosenberg.l...@googlemail.com] Well, actually when it comes to IO performance Java outperforms C, so I wouldn't place my money on old bets like C is faster because its C. It isn't. Specifics! Agreed. Leon, can you provide some justification for that claim? Presumably, the JVM uses the standard C library calls so coding C directly to the C library will be faster than the JVM intervening and translating those calls into C-library calls. The JIT can only optimize so much. I'm not saying that Java is definitely slower just because it's Java, but I suspect that Java outperforms C for I/O is just as apocryphal. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmJ0wEACgkQ9CaO5/Lv0PBv/QCgu5OFz0WXP/kN1eGy7kGvDhlB Yl4AoKZjSEC9l26M15fHF1xswaSRZh3J =uapP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
You should all just switch to perl. It's much less complicated that all this JVM, JIT, Gcs, memory leaks, classloaders, commons logging and and all that stuff. You would not even need Tomcat. You could go to ApacheCON, skip half the sessions with a clear conscience and have good beer instead. ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
On Wed, Feb 4, 2009 at 6:45 PM, André Warnier a...@ice-sa.com wrote: You should all just switch to perl. *yuck* - coding in perl always make my eyes squint and my hair stick out =8| You could go to ApacheCON, skip half the sessions with a clear conscience and have good beer instead. well, there's still room for that :) Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Performance of APR
From: Leon Rosenberg [mailto:rosenberg.l...@googlemail.com] Well, actually when it comes to IO performance Java outperforms C, so I wouldn't place my money on old bets like C is faster because its C. It isn't. Specifics! Which platform(s), which compiler(s), which runtime(s), which algorithm(s), by what amount, using what measure. What is the source of the performance claim you are asserting? I also wouldn't place bets. I would measure instead. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
David Boreham wrote: Jess Holle wrote: David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. You can make your own LB using Tomcat. Yes, I /could/, but Apache already does it. I don't want to invest enough of my own time in such a thing to put it on an equal footing with mod_jk and mod_proxy_ajp. Until someone does, though, Apache is a really necessary piece in a lot of configurations. -- Jess Holle
Re: Performance of APR
Mladen Turk wrote: When it comes to the large file serving then the OS sendfile support in Tomcat Native outperforms the standard Java IO by an order of magnitude (In some of my tests up to 4 times), and with constant memory usage regardless of file size. There is also some other advanced features like Thread per request processing model, and much faster OpenSSL compared to JSSE. I have a presentation from ApacheCon EU 2007 that has some performance figures: http://people.apache.org/~mturk/tc6apconneu07.pdf Which is all cool. If you have to support lots of different platforms, though, APR seems to be hassle than its worth -- especially given that I already need Apache for load balancing. Pure Java is really, really nice if you're in this boat. That's not knocking APR -- just wishing we'd get the whole problem licked really well in Java and wouldn't have to deal with native code messes (like building/linking on AIX or learning enough about Apache's guts to make substantive patches). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Well, if you don't want to deal with the APR (which I don't think is all that complicated), maybe new NIO-connector is worth a try: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html However, I haven't seen any benchmarks comparing NIO with APR, especially when it comes to SSL Btw., a hardware-loadbalancer is not all that expensive... Cheers Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Gregor Schneider wrote: Well, if you don't want to deal with the APR (which I don't think is all that complicated), maybe new NIO-connector is worth a try: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html However, I haven't seen any benchmarks comparing NIO with APR, especially when it comes to SSL Btw., a hardware-loadbalancer is not all that expensive... It is when you're talking commercial software using Tomcat. If this was an internal usage of Tomcat, fine and good. Telling everyone that uses your product on Tomcat to use a hardware load balancer just to have more than one Tomcat serving the load is a non-starter, though. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Performance of APR
From: Gregor Schneider [mailto:rc4...@googlemail.com] Subject: Re: Performance of APR However, I haven't seen any benchmarks comparing NIO with APR, especially when it comes to SSL SSL handling is the same for the NIO and the traditional Java connector, so APR wins there. Filip has reported that the NIO connector is slightly slower than the traditional one in terms of overall throughput (likely due to extra thread context switching), but has much better scalability. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Jess Holle wrote: You can make your own LB using Tomcat. Yes, I /could/, but Apache already does it. I don't want to invest enough of my own time in such a thing to put it on an equal footing with mod_jk and mod_proxy_ajp. Until someone does, though, Apache is a really necessary piece in a lot of configurations. I took the opposite view. It is worth my time to write it. If it ends up being reasonably generic (not sure about that yet) then I'll open source it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
David Boreham wrote: Jess Holle wrote: You can make your own LB using Tomcat. Yes, I /could/, but Apache already does it. I don't want to invest enough of my own time in such a thing to put it on an equal footing with mod_jk and mod_proxy_ajp. Until someone does, though, Apache is a really necessary piece in a lot of configurations. I took the opposite view. It is worth my time to write it. If it ends up being reasonably generic (not sure about that yet) then I'll open source it. Perhaps it would be... I also had a strong multi-LDAP requirement, though, which is not addressed until 6.0.19. Then there's the remaining question about 3rd-party security plug-ins our customers might be using... -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Christopher Schultz wrote: I can't help but suspect that Apache httpd will outperform Tomcat even when it's running APR for static content, merely due to the overhead of the JVM, heap management, etc. (which I realize are fairly minimal). Can anyone give a non-flame comment or point to an actual performance comparison with decent data? Serving static content is an I/O-limited task. So whether the server code takes 450ns or 500ns to do the processing required is not significant. Provided the interface with the kernel is optimal, any server will perform roughly the same because it's the kernel doing all the work. I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Performance of APR
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Performance of APR due to the overhead of the JVM, heap management, etc. Actually, object allocation these days is quite a bit faster than a malloc(), and objects that quickly become unreachable quickly cost almost nothing at GC time. Some JVMs can determine that objects are truly thread local and don't even allocate them on the heap but instead treat them like local variables in C. Can anyone give a non-flame comment or point to an actual performance comparison with decent data? The last trustworthy study I saw on this specific topic was the one from Peter Lin: http://tomcat.apache.org/articles/benchmark_summary.pdf Note that it predates APR use in Tomcat. There are some other interesting papers here: http://tomcat.apache.org/resources.html#Articles - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
On Thu, Jan 29, 2009 at 9:34 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I often hear folks on the list mentioning that since the APR library is the same as that which runs under Apache httpd, the performance of the two ought to be the same for static content. I'm not so sure, so I'm asking about it. according to this free chapter of Tomcat: The Definitive Guide, Second Edition book http://oreilly.com/catalog/9780596101060/chapter/index.html tomcat's JIO (old plain java connector) outperforms apache httpd in nearly all tests, so don't bother playing with APR:) Since Tomcat's request processing is all in Java (right?), the request must first be processed by Java, including creating all those objects that are included in the request. I realize that some of those objects are created on demand (for instance, Tomcat doesn't parse all the GET and POST parameters from the request until the handling servlet actually requests one of them), but all that stuff still happens. Before the request is handed-off to APR. Is the same true of Apache httpd; that is, since Apache must do a bunch of pre-processing of the request before the bytes are actually streamed, does the performance of the two actually end up being the same? I can't help but suspect that Apache httpd will outperform Tomcat even when it's running APR for static content, merely due to the overhead of the JVM, heap management, etc. (which I realize are fairly minimal). Well, actually when it comes to IO performance Java outperforms C, so I wouldn't place my money on old bets like C is faster because its C. It isn't. Can anyone give a non-flame comment or point to an actual performance comparison with decent data? yeah, check the link (and buy the book :-)) regards Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. Also Apache 2.2 allows easy configurable authentication (or a single resource/URL) against multiple authentication repositories, e.g. multiple LDAPs. Last I investigated Tomcat did not. I'd love to see a simple world of only needing Tomcat and no front-end web server. For starters Tomcat should provide high-performance load-balancing from one front-end Tomcat to multiple backend Tomcats and easy authentication against multiple LDAPs. After that there are other issues, e.g. security providers that provide Apache but not Tomcat plug-ins, but these would seemingly impact far fewer folk. In fact, I'd bet fairly few of us need the multi-LDAP stuff -- just giving good, high-performance load balancing over Tomcats by a Tomcat would be huge. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Jess Holle wrote: David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. Also Apache 2.2 allows easy configurable authentication (or a single resource/URL) against multiple authentication repositories, e.g. multiple LDAPs. Last I investigated Tomcat did not. The new combined realm (as of 6.0.19) will let you do this. No Tomcat only load balancing though. Mark I'd love to see a simple world of only needing Tomcat and no front-end web server. For starters Tomcat should provide high-performance load-balancing from one front-end Tomcat to multiple backend Tomcats and easy authentication against multiple LDAPs. After that there are other issues, e.g. security providers that provide Apache but not Tomcat plug-ins, but these would seemingly impact far fewer folk. In fact, I'd bet fairly few of us need the multi-LDAP stuff -- just giving good, high-performance load balancing over Tomcats by a Tomcat would be huge. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Jess Holle wrote: David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. You can make your own LB using Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Leon Rosenberg wrote: On Thu, Jan 29, 2009 at 9:34 PM, Christopher Schultz I can't help but suspect that Apache httpd will outperform Tomcat even when it's running APR for static content, merely due to the overhead of the JVM, heap management, etc. (which I realize are fairly minimal). Well, actually when it comes to IO performance Java outperforms C, so I wouldn't place my money on old bets like C is faster because its C. It isn't. When it comes to the large file serving then the OS sendfile support in Tomcat Native outperforms the standard Java IO by an order of magnitude (In some of my tests up to 4 times), and with constant memory usage regardless of file size. There is also some other advanced features like Thread per request processing model, and much faster OpenSSL compared to JSSE. I have a presentation from ApacheCon EU 2007 that has some performance figures: http://people.apache.org/~mturk/tc6apconneu07.pdf Regards -- ^(TM) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
