Re: Optimal Settings to use Tomcat as a HTTP File Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sriram, On 6/11/2011 4:00 AM, Sriram Narayanan wrote: On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: Sriram, On 6/10/2011 1:49 PM, Sriram Narayanan wrote: Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Sure, but it's not always necessary. More moving parts when they aren't necessary just results in tougher management and greater opportunity for security mistakes. For those that need it, this is what is done. Phrases such as moving parts, etc give the impression that it's all going to be very complicated when it's not. My point is that most don't need it. It's evidently become so standard that people do it because it's what everybody does, instead of for some specific reason. For instance, we use Apache httpd in front of Apache Tomcat because we need a single web server process to proxy to multiple back-end Apache Tomcat instances. We also have multiple back-end servers and use httpd as a load-balancer. If we had an F5 out front, we would probably remove Apache httpd from the mix. Configuring two web servers is (debatably) double the complexity. I didn't say it was very complicated... I just said it was more complicated. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. I'm not sure I would say the vast majority, but certainly many are. There's no need to give the impression that some other web server in front of Tomcat is a best practice: it's merely a common practice. This is not giving an impression. There's a reason that this is common practice. Enlighten me: what is the reason that this is common practice? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32aIoACgkQ9CaO5/Lv0PCRcwCcD3dtgWWo5LjQoYCdYGxD6eut qjAAn2DH2dXpwCGXuiM84qc4YbofgWHn =w0j7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Optimal Settings to use Tomcat as a HTTP File Server
Enlighten me: what is the reason that this is common practice? The most obvious reason for having HTTP server in front of an Application Server (Tomcat) is that there are many things that you can do at/in the HTTP server that you don't have available to you inside Tomcat. Things like: -Caching -Proxy -Load balancing -Static image serving (much more economical because the HTTP server is much lighter weight than a JVM/App server) -etc... The most common/safest configuration is the HTTP server being directly available to the internet and the Application Servers being hidden behind firewalls with only 1 port per IP address forwarded through the firewall. The most common reason for this is that an Application Server requires usually requires access to many more things than a simple HTTP server (Databases, Network Disk space, etc..) and those other things are MUCH more difficult to secure against external intrusions. Also if you want to do clustering with failover or sequential updates it is better to have something in front of the actual application server that doesn't need to be changed much. It will just simplify ongoing daily maintenance (it looks more complicated but in the long run it makes things a lot simpler). HTTP servers are also much more efficient at processing HTTP connections and HTTPS traffic than Application Servers. Besides, if you want an outage message, where would you serve that from if not from an HTTP server? Bill -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: June 13, 2011 3:44 PM To: Tomcat Users List Subject: Re: Optimal Settings to use Tomcat as a HTTP File Server -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sriram, On 6/11/2011 4:00 AM, Sriram Narayanan wrote: On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: Sriram, On 6/10/2011 1:49 PM, Sriram Narayanan wrote: Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Sure, but it's not always necessary. More moving parts when they aren't necessary just results in tougher management and greater opportunity for security mistakes. For those that need it, this is what is done. Phrases such as moving parts, etc give the impression that it's all going to be very complicated when it's not. My point is that most don't need it. It's evidently become so standard that people do it because it's what everybody does, instead of for some specific reason. For instance, we use Apache httpd in front of Apache Tomcat because we need a single web server process to proxy to multiple back-end Apache Tomcat instances. We also have multiple back-end servers and use httpd as a load-balancer. If we had an F5 out front, we would probably remove Apache httpd from the mix. Configuring two web servers is (debatably) double the complexity. I didn't say it was very complicated... I just said it was more complicated. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. I'm not sure I would say the vast majority, but certainly many are. There's no need to give the impression that some other web server in front of Tomcat is a best practice: it's merely a common practice. This is not giving an impression. There's a reason that this is common practice. Enlighten me: what is the reason that this is common practice? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32aIoACgkQ9CaO5/Lv0PCRcwCcD3dtgWWo5LjQoYCdYGxD6eut qjAAn2DH2dXpwCGXuiM84qc4YbofgWHn =w0j7 -END PGP SIGNATURE- - 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
Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)
-Original Message- From: Bill Miller [mailto:millebi.subscripti...@gmail.com] Sent: Monday, June 13, 2011 3:58 PM Enlighten me: what is the reason that this is common practice? ... -Static image serving (much more economical because the HTTP server is much lighter weight than a JVM/App server) -etc... I've heard this claim before, but I'm not so sure I believe it. Apache httpd is a web server implemented in C that runs directly on the OS. Apache Tomcat is a web server written in Java that runs on a JVM. I'd hope both are written near-optimally for their respective environments, and there's no good reason Java needs to be slow. I just tried a trivial benchmark of a static file (187 bytes) that yielded 3,223 req/sec from httpd, and 3,172 req/sec from Tomcat. That's a difference under 2%. A 2% performance difference isn't compelling enough to me to make an architectural decision one way or the other. I haven't benchmarked larger files, but I can imagine that APR's sendfile support would give Tomcat an assist there. On the other hand, there are other good reasons to use Java as a web server in favor of httpd. Security, for one--I shouldn't need to worry about e.g. stack buffer overflow exploits when running a Java server. My hope is that Tomcat and its ilk will slowly replace older web server technology for static and dynamic content alike. That's not just for simplicity's sake, but that I also see the difference between static and dynamic requests starting to evaporate. We serve a lot of cacheable requests from our application, all idempotent requests, and they are not normally backed by file system content. They could just as well be a row in a database or search engine results. The distinction of static content (i.e. content served by files on a file system) isn't useful to me because it's not very different than content served from other sources. But, unlike Apache httpd, Tomcat is built on a technology that is very easy to extend for e.g. database access. The architectural shift away from file content seems to be accelerated by adoption of distributed and (especially) cloud computing, in which a central read/write file system is not always convenient or available. Distributed file systems exist but have not proven to be as effective as relational databases or any of the No-SQL technologies such as Hadoop. Hence the traditional static vs. dynamic distinction is most likely becoming obsolete. -Jeff
Re: Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)
On 13 June 2011 21:41, Jeff Sturm jeff.st...@eprize.com wrote: From: Bill Miller [mailto:millebi.subscripti...@gmail.com] -Static image serving (much more economical because the HTTP server is much lighter weight than a JVM/App server) -etc... [...] I just tried a trivial benchmark of a static file (187 bytes) that yielded 3,223 req/sec from httpd, and 3,172 req/sec from Tomcat. That's a difference under 2%. A 2% performance difference isn't compelling enough to me to make an architectural decision one way or the other. I haven't benchmarked larger files, but I can imagine that APR's sendfile support would give Tomcat an assist there. http://tomcat.apache.org/articles/benchmark_summary.pdf I seem to recall some more recent benchmarks as well? The summary I've seen is you'll run out of network bandwidth long before you run out of the capacity to serve static files in any modern system, whether you're using httpd or Tomcat. - Peter
Re: Optimal Settings to use Tomcat as a HTTP File Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill, This is fun. On 6/13/2011 3:58 PM, Bill Miller wrote: Enlighten me: what is the reason that this is common practice? The most obvious reason for having HTTP server in front of an Application Server (Tomcat) is that there are many things that you can do at/in the HTTP server that you don't have available to you inside Tomcat. Fair enough, but you shouldn't just throw httpd in the mix because those features are available. You should only turn to Apache httpd when you actually need one of those features. I'm just suggesting that httpd/Tomcat as a standard setup is a thing of the past. Sure, lots of people do it, but lots of those people shouldn't be doing it. Things like: -Caching -Proxy -Load balancing -Static image serving (much more economical because the HTTP server is much lighter weight than a JVM/App server) Really? What benchmarking have you done? Because I have benchmarked httpd against Tomcat's NIO and APR connectors and I can tell you that Tomcat scales just as well (better under certain conditions). Why shouldn't it? It's the same code in the case of APR. Here's my data and writeup: http://people.apache.org/~schultz/ApacheCon%20NA%202010/ -etc... Wait, there's /more/? You must be right, then. The most common/safest configuration is the HTTP server being directly available to the internet and the Application Servers being hidden behind firewalls with only 1 port per IP address forwarded through the firewall. The safest usable configuration has the application servers not directly accessible from the Internet, or any other dangerous place. There's no reason that a full-blown http server has to be in between them. Load balancers, proxies, etc. are all other options that are equally viable. Also if you want to do clustering with failover or sequential updates it is better to have something in front of the actual application server that doesn't need to be changed much. Agreed, but there's no reason for that thing to be httpd. HTTP servers are also much more efficient at processing HTTP connections and HTTPS traffic than Application Servers. References, please? You do know that the APR connector runs the same code as Apache httpd, right? Note that I didn't benchmark HTTPS speeds for the above presentation, though my expectation is that JSSE will be easily out-performed by both Apache httpd and Tomcat/APR, unless some JSSE-friendly hardware SSL acceleration is available (which would presumably be usable by OpenSSL, anyway, probably giving the slight edge back to httpd/APR/OpenSSL). Besides, if you want an outage message, where would you serve that from if not from an HTTP server? Load balancer, proxy, etc. You don't have to use Apache httpd + mod_jk or whatever just to get a down page showing when you are having an outage. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32i60ACgkQ9CaO5/Lv0PAuhwCgwW2eeB/PgcDUSTLWwQAcV5bm usQAnj9NeFpA80ZrFXrtQGNCI1l5g47u =/2yD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff, On 6/13/2011 4:41 PM, Jeff Sturm wrote: -Original Message- From: Bill Miller [mailto:millebi.subscripti...@gmail.com] Sent: Monday, June 13, 2011 3:58 PM Enlighten me: what is the reason that this is common practice? ... -Static image serving (much more economical because the HTTP server is much lighter weight than a JVM/App server) -etc... I've heard this claim before, but I'm not so sure I believe it. I just tried a trivial benchmark of a static file I have better benchmarks, I think: http://people.apache.org/~schultz/ApacheCon%20NA%202010/ On the other hand, there are other good reasons to use Java as a web server in favor of httpd. Security, for one +1 One could argue (and others have, in another thread) that the app server (with it's usually more-privileged role among servers) is inappropriate to be Internet-facing, and I agree. Were Tomcat to include an HTTP proxying capability (which it doesn't) that performed well (which it could), I might even recommend replacing Apache httpd with Tomcat for static file-serving for just security reasons. Apache httpd is pretty secure, though, in it's default configuration when kept up-to-date. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32jNYACgkQ9CaO5/Lv0PAHSgCfdWzzez5DQ3CknIuJnhot30mI 8YwAn3aRepmkLQ071mosobQj0CGfiTV6 =opVW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Optimal Settings to use Tomcat as a HTTP File Server
On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sriram, On 6/10/2011 1:49 PM, Sriram Narayanan wrote: Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Sure, but it's not always necessary. More moving parts when they aren't necessary just results in tougher management and greater opportunity for security mistakes. For those that need it, this is what is done. Phrases such as moving parts, etc give the impression that it's all going to be very complicated when it's not. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. I'm not sure I would say the vast majority, but certainly many are. There's no need to give the impression that some other web server in front of Tomcat is a best practice: it's merely a common practice. This is not giving an impression. There's a reason that this is common practice. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ydCIACgkQ9CaO5/Lv0PDRRACfeZ7jW2zSaKy6yf+CZejb46JX DSUAoJbNc3ZABf/19X5fjQveE4MjAbDh =KY1q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- == Belenix: www.belenix.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Optimal Settings to use Tomcat as a HTTP File Server
I re-read my own responses. It looks like some context has not come across in the non-interative nature of email. I myself agree that common practice is not the same as best practice, though in my experience as a developer + sysadmin for the past few years, it is indeed ideal to separate the serving of static content from the service of application responses. -- Sriram On Sat, Jun 11, 2011 at 1:30 PM, Sriram Narayanan sriram...@gmail.com wrote: On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sriram, On 6/10/2011 1:49 PM, Sriram Narayanan wrote: Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Sure, but it's not always necessary. More moving parts when they aren't necessary just results in tougher management and greater opportunity for security mistakes. For those that need it, this is what is done. Phrases such as moving parts, etc give the impression that it's all going to be very complicated when it's not. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. I'm not sure I would say the vast majority, but certainly many are. There's no need to give the impression that some other web server in front of Tomcat is a best practice: it's merely a common practice. This is not giving an impression. There's a reason that this is common practice. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ydCIACgkQ9CaO5/Lv0PDRRACfeZ7jW2zSaKy6yf+CZejb46JX DSUAoJbNc3ZABf/19X5fjQveE4MjAbDh =KY1q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- == Belenix: www.belenix.org -- == Belenix: www.belenix.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Optimal Settings to use Tomcat as a HTTP File Server
From: Sriram Narayanan [mailto:sriram...@gmail.com] Subject: Re: Optimal Settings to use Tomcat as a HTTP File Server I myself agree that common practice is not the same as best practice, though in my experience as a developer + sysadmin for the past few years, it is indeed ideal to separate the serving of static content from the service of application responses. Your opinion; mine's the opposite (with 40+ years of experience). Simpler is pretty much always better, if it can get the job done. - 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: Optimal Settings to use Tomcat as a HTTP File Server
On Sat, Jun 11, 2011 at 7:54 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Sriram Narayanan [mailto:sriram...@gmail.com] Subject: Re: Optimal Settings to use Tomcat as a HTTP File Server I myself agree that common practice is not the same as best practice, though in my experience as a developer + sysadmin for the past few years, it is indeed ideal to separate the serving of static content from the service of application responses. Your opinion; mine's the opposite (with 40+ years of experience). Simpler is pretty much always better, if it can get the job done. I guess it depends on what you've had to face, then. There are all these static content serving strategies and technologies being developed. There certainly is a reason for those. - Chuck -- Sriram - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Optimal Settings to use Tomcat as a HTTP File Server
On Fri, Jun 10, 2011 at 11:18 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Caldarale, Charles R Subject: RE: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. I have to qualify my statement: if the *only* thing you're using Tomcat for is delivering static content, then httpd would be better. If you have other reasons to use Tomcat (e.g., running servlets or JSPs), then by all means use it as your static content server as well. You will generally see better performance overall by not having two servers in the mix forced to communicate with each other. Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Given that we have binary communication between httpd and tomcat, and that this allows for Tomcat to be installed and used in all manner of ways (dedicated instances for specific web apps, or load balanced instances, for e.g.), I don't think forced is the right term at all. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. -- Sriram - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Optimal Settings to use Tomcat as a HTTP File Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 6/9/2011 9:40 PM, Caldarale, Charles R wrote: From: Anand HS [mailto:anan...@gmail.com] Subject: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. +1 If you don't need Java for anything else, skip Tomcat altogether. There are faster HTTP servers than both Apache Tomcat and Apache httpd. However, if you really want to use Tomcat, and you expect a heavy load, install the APR connector (especially important if you're using SSL). If you don't need SSL, the NIO connector is a good bet, too. Both APR and NIO support sendFile which allows higher-throughput static file serving. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3yc3kACgkQ9CaO5/Lv0PBiHACePaG1u57geBMBY+5nN46e7jcr KlwAn08b0nwm0NgqVVWA2za3VSgON5tM =Dm40 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Optimal Settings to use Tomcat as a HTTP File Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sriram, On 6/10/2011 1:49 PM, Sriram Narayanan wrote: Having one application serve static content, and having other applications serve other content (accept http requests, perform some processing, and send back responses, for e.g.), is actually a widely accepted and tested mechanism of using various stacks for various tasks. Sure, but it's not always necessary. More moving parts when they aren't necessary just results in tougher management and greater opportunity for security mistakes. In fact, the vast majority of websites out there specifically stick in proxies and such in front of tomcat for SSL termination, load balancing, and static content serving. I'm not sure I would say the vast majority, but certainly many are. There's no need to give the impression that some other web server in front of Tomcat is a best practice: it's merely a common practice. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ydCIACgkQ9CaO5/Lv0PDRRACfeZ7jW2zSaKy6yf+CZejb46JX DSUAoJbNc3ZABf/19X5fjQveE4MjAbDh =KY1q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Optimal Settings to use Tomcat as a HTTP File Server
From: Anand HS [mailto:anan...@gmail.com] Subject: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. However, if you really want to use Tomcat, and you expect a heavy load, install the APR connector (especially important if you're using SSL). The other major configuration setting would be the Java heap size, but you'll have to experiment to determine what's optimal for your platform and load. - 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: Optimal Settings to use Tomcat as a HTTP File Server
On Fri, Jun 10, 2011 at 7:10 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Anand HS [mailto:anan...@gmail.com] Subject: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. However, if you really want to use Tomcat, and you expect a heavy load, install the APR connector (especially important if you're using SSL). The other major configuration setting would be the Java heap size, but you'll have to experiment to determine what's optimal for your platform and load. +1. Let Apache / Nginx / etc serve the static content and let Tomcat focus on running your webapplication. -- Sriram == Belenix: www.belenix.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Optimal Settings to use Tomcat as a HTTP File Server
From: Caldarale, Charles R Subject: RE: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. I have to qualify my statement: if the *only* thing you're using Tomcat for is delivering static content, then httpd would be better. If you have other reasons to use Tomcat (e.g., running servlets or JSPs), then by all means use it as your static content server as well. You will generally see better performance overall by not having two servers in the mix forced to communicate with each other. - 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: Optimal Settings to use Tomcat as a HTTP File Server
Thanks Charles and Sriram for your inputs. Since my requirement is to just serve static content, I will consider apache httpd for it. Thanks.! Anand On Thu, Jun 9, 2011 at 10:48 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Caldarale, Charles R Subject: RE: Optimal Settings to use Tomcat as a HTTP File Server We plan to use tomcat to let users download static content ( media, executables etc.. ). As much as I like Tomcat, I have to think it might be more appropriate to use Apache httpd rather than Tomcat for pure static content. I have to qualify my statement: if the *only* thing you're using Tomcat for is delivering static content, then httpd would be better. If you have other reasons to use Tomcat (e.g., running servlets or JSPs), then by all means use it as your static content server as well. You will generally see better performance overall by not having two servers in the mix forced to communicate with each other. - 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
