Re: Compression and SSL
Jeffrey Janner wrote: Thanks for all the suggestions so far guys. Are there any other tips I could provide to the developers that they can do to improve throughput? Should they hard-code the http:// for all the static elements to avoid passing them over SSL, If these items are not sensitive, that /could/ be a good idea, except that IE is probably going to bother your users no-end, popping up friendly warnings that this site is switching between secure and non-secure pages, so they'll probably wonder which brain-dead designer came up with this scheme. or do my security constraints take care of that? (I doub it.) You're right to doubt, they will do nothing of the kind. The original URL gets redirected to https immediately, so I'm thinking everything from there on out is SSL. Correct? Yes, inasfar as links in html pages are concerned. You have to look at it from the browser's point of view. When it sees an incomplete link, it completes it using the protocol and hostname from which the current page was obtained, and then it requests that object. Can I get more granular? I'd be happy for a pointer to a good reference on the subject. There are probably tons on Google, if you look for website optimi[z,s]ation or the like. Personally, I have found that a very large proportion of websites on the WWW are slow because their designers just /don't think/. If loading each page requires 10 or more requests to the server and you fail to organise stuff so that it can be cached by the browser, then you should not be surprised that your site feels slow. But it never ceases to amaze me how many sites ignore the simple common-sense principles. I would bet that carefully examining what you are actually sending in your pages and cleaning it up would yeld more benefits, faster, than playing around with protocols, compression and the like. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
On 02/11/2009 23:34, Jeffrey Janner wrote: Pid - Windows 64-bit Dual Quad-Core w/32G RAM. Do I really need bigger? App's not really slow-- works great here. But with a 300ms latency (one-way) to The Orient, you can see why I might want to send as few bits as possible. Jeff Indeed. Was just asking. What portion of the resources sent are static, and have you considered hosting those physically closer to your clients? If you've got a typical web page type setup, then most of the response time is made up of the (bi)sequential download of the extra resources served after the browser has processed the HTML. A quick look at the network profiler in Firebug ought to make it clear what's happening. If you can expect an average of 250ms for *every* resource, then even the cost of a little big of logic, to set a different server URL for those static resources, will probably pay off big time. Even a cheap low power server might offer a better service if the resources are small enough, and it's in the locality. p -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 02, 2009 12:12 PM To: Tomcat Users List Subject: Re: Compression and SSL On 02/11/2009 16:48, Jeffrey Janner wrote: OK, another newbie-ish question here. I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or Windows 2008 x64 to serve applications from the US to Asia-based clients. We encrypt everything using SSL, from Login page onward, with transport-guarantee of CONFIDENTIAL. All URLs are configured as relative, i.e., /images/picture.png, /APP1?param1=value, etc. We use Tomcat as the web server with no intervening proxies, load-balancers, accelerators, etc. Response time is noticeably slow (based on complaint level) and I am looking for ways to improve it. Bigger server? Will setting the HTTPS connector compression=on actually compress the data for HTTPS? What makes you think that compressing things is going to improve matters? Doing the compression is an overhead itself. What's slow about your app and how do you know it? Does it compress before or after applying the encryption? And, in case it's relevant, here is the relevant excerpt from the web.xml file we use: security-constraint web-resource-collection web-resource-nameEverything/web-resource-name url-pattern*.jsp/url-pattern url-pattern*.html/url-pattern url-pattern*.js/url-pattern Brevity: url-pattern/*/url-pattern url-pattern/APP1/url-pattern url-pattern/APP2/url-pattern If those actually represent real webapps, with their own WEB-INF/web.xml, the lines above don't do anything. p /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Any assistance would be much appreciated. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
2009/11/2 George Sexton geor...@mhsoftware.com You didn't read the original post very closely. to serve applications from the US to Asia-based clients. It's bandwidth and latency. Actually, yes, I did. And I saw that, and I suspected latency would be the answer. Suspicion is not confirmation however :-). One thing I've learned over the last 35 years is to confirm the problem rather than guess at a solution based on incomplete information. Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I agree that bandwidth/latency is the one to solve, as the rest of the thread's been working on while I've been asleep! - Peter
Re: Compression and SSL
Peter Crowther wrote: ... Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I agree that bandwidth/latency is the one to solve, as the rest of the thread's been working on while I've been asleep! Elaborating a bit on what I mentioned before, and sorry Jeffrey if this sounds elementary. But my experience is that this kind of thing is often overlooked, and people spend time looking at all kinds of esoteric solutions when the real problem stares them in the face. It does not take much to check this, and you need do nothing at the server side. Get Firefox, and the HttpFox add-on (or any similar combination that allows you to see what is really going back and forth between browser and server). - open the browser, and start HttpFox in it's own window - clear the HttpFox trace, and start capturing - in the borwser, call up the first page of your site - look at the HttpFox trace, to see how many requests/responses this really generated, and for what. Pay particular attention to all the accessory things, like images, stylesheets, images called up by stylesheets, javascript libraries, etc.. You also see the size of each of these things. - also pay attention to any 4xx status responses (like 404 not found). It is often the case that, as an application is developed, people change the names of images, stylesheets etc.. without adapting the links in the pages which load these things. Each 404 means that one request went to the server, the server did not find it, and sent back a 404 response. Over a long/slow link, these things count. (Another good source for this is the server access logs) That was all for your first page, but I'd bet it may already be an eye-opener as to what is really going on. - now call the second page, and do the same examination. If the design and the caching are correct, then you should see quite a few of 30x responses (not modified). That means that the browser sent a request to the server for some object, conditional upon the fact that that object had been modified since the browser got it last. And the server may just answer no, it was not modified, use your cached version. That saves bandwidth when it works as it should, because instead of resending the same object to the browser (an image, a stylesheet, a javascript library, a java applet), the server just sends one status line. If you do not see a lot of 30x responses, but a lot of new requests for images, stylesheets, background images, etc.. with 200 OK responses, then maybe ask yourself why this second page needs so many things different from the first page. Maybe the server has 5 identical (in content) stylesheets stored, but under different names. - it is also often the case that people endlessly duplicate the same style and graphic elements in many directories and sub-directories, because it is easier to have links like images/image1.jpg in all your pages (and it is also easier for the graphic designers). If these images (or other things) have different URL paths on the server, then for the browser they all look different, and have to be gotten and cached separately. If a given image is only in one (URL) place on the server, then it is retrieved and cached only once). (If such is the case and you do not want to revise all your pages, then there are things that can be done at the server side to mitigate the effects - like aliases, and URL rewrite rules). And so on.. No kidding, I have seen cases where the graphic designer of the site thought it nice to have a different background picture for each page, à 250 KB or more per picture. That may look very nice, and be justified for some kinds of websites where graphics are a main concern, but for most business appplications it is less important than latency. YMMV. Now when you do that, and tell these designers and programmers to clean up their act, you are not going to be loved. Nobody likes to clean up. But you may be able to save 50% of your bandwidth and reclaim a significant percentage of duplicate files on your servers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
On 03/11/2009 10:40, André Warnier wrote: Peter Crowther wrote: ... Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I agree that bandwidth/latency is the one to solve, as the rest of the thread's been working on while I've been asleep! Elaborating a bit on what I mentioned before, and sorry Jeffrey if this sounds elementary. But my experience is that this kind of thing is often overlooked, and people spend time looking at all kinds of esoteric solutions when the real problem stares them in the face. It does not take much to check this, and you need do nothing at the server side. Get Firefox, and the HttpFox add-on (or any similar combination that allows you to see what is really going back and forth between browser and server). - open the browser, and start HttpFox in it's own window - clear the HttpFox trace, and start capturing - in the borwser, call up the first page of your site - look at the HttpFox trace, to see how many requests/responses this really generated, and for what. Pay particular attention to all the accessory things, like images, stylesheets, images called up by stylesheets, javascript libraries, etc.. You also see the size of each of these things. - also pay attention to any 4xx status responses (like 404 not found). It is often the case that, as an application is developed, people change the names of images, stylesheets etc.. without adapting the links in the pages which load these things. Each 404 means that one request went to the server, the server did not find it, and sent back a 404 response. Over a long/slow link, these things count. (Another good source for this is the server access logs) That was all for your first page, but I'd bet it may already be an eye-opener as to what is really going on. - now call the second page, and do the same examination. If the design and the caching are correct, then you should see quite a few of 30x responses (not modified). That means that the browser sent a request to the server for some object, conditional upon the fact that that object had been modified since the browser got it last. And the server may just answer no, it was not modified, use your cached version. That saves bandwidth when it works as it should, because instead of resending the same object to the browser (an image, a stylesheet, a javascript library, a java applet), the server just sends one status line. If you do not see a lot of 30x responses, but a lot of new requests for images, stylesheets, background images, etc.. with 200 OK responses, then maybe ask yourself why this second page needs so many things different from the first page. Maybe the server has 5 identical (in content) stylesheets stored, but under different names. - it is also often the case that people endlessly duplicate the same style and graphic elements in many directories and sub-directories, because it is easier to have links like images/image1.jpg in all your pages (and it is also easier for the graphic designers). If these images (or other things) have different URL paths on the server, then for the browser they all look different, and have to be gotten and cached separately. If a given image is only in one (URL) place on the server, then it is retrieved and cached only once). (If such is the case and you do not want to revise all your pages, then there are things that can be done at the server side to mitigate the effects - like aliases, and URL rewrite rules). Seconded. We minimised the requirements for nth requests, use CSS, cache static resources as much as possible and substantially improved response times for remote clients. Course, there's always more you can do... p And so on.. No kidding, I have seen cases where the graphic designer of the site thought it nice to have a different background picture for each page, à 250 KB or more per picture. That may look very nice, and be justified for some kinds of websites where graphics are a main concern, but for most business appplications it is less important than latency. YMMV. Now when you do that, and tell these designers and programmers to clean up their act, you are not going to be loved. Nobody likes to clean up. But you may be able to save 50% of your bandwidth and reclaim a significant percentage of duplicate files on your servers. - 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: Compression and SSL
Well, we already have filters in place to make sure our images, javascript, and other statics go out as cacheable. In fact, the only thing that should not be cached at this point are the results of the jsp pages themselves. Did see something recently about combining images into a single file, and then having something on the client end pick out what it needed per page. Didn't read it all, since it sounds like it requires a bit of coding to support it. Might be something to tell the dev team about. I'm just looking at it from changes that an admin can implement. -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, November 03, 2009 2:07 AM To: Tomcat Users List Subject: Re: Compression and SSL Can I get more granular? I'd be happy for a pointer to a good reference on the subject. There are probably tons on Google, if you look for website optimi[z,s]ation or the like. Personally, I have found that a very large proportion of websites on the WWW are slow because their designers just /don't think/. If loading each page requires 10 or more requests to the server and you fail to organise stuff so that it can be cached by the browser, then you should not be surprised that your site feels slow. But it never ceases to amaze me how many sites ignore the simple common-sense principles. I would bet that carefully examining what you are actually sending in your pages and cleaning it up would yeld more benefits, faster, than playing around with protocols, compression and the like. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
André - Yep, it does sound quite elementary, but pointing out a good tool is appreciated. Since I am also the deployment god (we both host and distribute the app), I usually keep a tight a lid on these things. Nothing like having to make a bunch of changes to the installer to make my day. I do my best to make sure there's not a lot of duplication. So far, my developers do a good job of it as well. And before I get flack about sticking it in a WAR file, some bonehead decisions by the original developers make this not a very practical option for installing at a customer site, i.e. we have to customize some files that would be in the WAR. Jeff -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, November 03, 2009 4:41 AM To: Tomcat Users List Subject: Re: Compression and SSL Peter Crowther wrote: ... Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I agree that bandwidth/latency is the one to solve, as the rest of the thread's been working on while I've been asleep! Elaborating a bit on what I mentioned before, and sorry Jeffrey if this sounds elementary. But my experience is that this kind of thing is often overlooked, and people spend time looking at all kinds of esoteric solutions when the real problem stares them in the face. *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
On 03/11/2009 14:33, Jeffrey Janner wrote: Well, we already have filters in place to make sure our images, javascript, and other statics go out as cacheable. In fact, the only thing that should not be cached at this point are the results of the jsp pages themselves. Did see something recently about combining images into a single file, and then having something on the client end pick out what it needed per page. Didn't read it all, since it sounds like it requires a bit of coding to support it. Might be something to tell the dev team about. I'm just looking at it from changes that an admin can implement. This sounds like the Sprite CSS technique. Doesn't require active code on the client, just a bit of cunning CSSery. p -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, November 03, 2009 2:07 AM To: Tomcat Users List Subject: Re: Compression and SSL Can I get more granular? I'd be happy for a pointer to a good reference on the subject. There are probably tons on Google, if you look for website optimi[z,s]ation or the like. Personally, I have found that a very large proportion of websites on the WWW are slow because their designers just /don't think/. If loading each page requires 10 or more requests to the server and you fail to organise stuff so that it can be cached by the browser, then you should not be surprised that your site feels slow. But it never ceases to amaze me how many sites ignore the simple common-sense principles. I would bet that carefully examining what you are actually sending in your pages and cleaning it up would yeld more benefits, faster, than playing around with protocols, compression and the like. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - 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: Compression and SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/3/2009 3:06 AM, André Warnier wrote: You have to look at it from the browser's point of view. When it sees an incomplete link, it completes it using the protocol and hostname from which the current page was obtained, and then it requests that object. It takes more than just that: * if the partial URL starts with a /, it uses procotol and hostname as André suggests * otherwise, it takes the URL of the current page, trims the right-hand side of the URL until it hits a /, then appends whatever you have as your partial URL Can I get more granular? I'd be happy for a pointer to a good reference on the subject. There are probably tons on Google, if you look for website optimi[z,s]ation or the like. http://www.stevesouders.com/blog/ Personally, I have found that a very large proportion of websites on the WWW are slow because their designers just /don't think/. If loading each page requires 10 or more requests to the server and you fail to organise stuff so that it can [not?] be cached by the browser, then you should not be surprised that your site feels slow. +1 Lots of requests = site feels slow. We intentionally limit the amount of junk we have in our UI so that everything feels snappy. Use CSS liberally and avoid lots of images. Also, avoid tables that require a large amount of data to load before the page can be laid-out correctly. Also remember that many web browsers will not cache anything retrieved via HTTPS, so you might want to play with some of your headers so things like CSS files, images, etc. are in fact being cached by your clients. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrwf4YACgkQ9CaO5/Lv0PD/4wCbBQJUpqEA0WxL3Dyrvqj4Obqu t4AAn142sF9lwdLrIw0IlgwTlrHrFsoD =A9i7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
-Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Monday, November 02, 2009 5:18 PM To: Tomcat Users List Subject: RE: Compression and SSL Thanks for all the suggestions so far guys. Are there any other tips I could provide to the developers that they can do to improve throughput? Here's a reference : Best Practices for Speeding Up Your Web Site http://developer.yahoo.com/performance/rules.html Should they hard-code the http:// for all the static elements to avoid passing them over SSL, or do my security constraints take care of that? (I doub it.) The original URL gets redirected to https immediately, so I'm thinking everything from there on out is SSL. Correct? Can I get more granular? I'd be happy for a pointer to a good reference on the subject. Jeff George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
On 02/11/2009 16:48, Jeffrey Janner wrote: OK, another newbie-ish question here. I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or Windows 2008 x64 to serve applications from the US to Asia-based clients. We encrypt everything using SSL, from Login page onward, with transport-guarantee of CONFIDENTIAL. All URLs are configured as relative, i.e., /images/picture.png, /APP1?param1=value, etc. We use Tomcat as the web server with no intervening proxies, load-balancers, accelerators, etc. Response time is noticeably slow (based on complaint level) and I am looking for ways to improve it. Bigger server? Will setting the HTTPS connector compression=on actually compress the data for HTTPS? What makes you think that compressing things is going to improve matters? Doing the compression is an overhead itself. What's slow about your app and how do you know it? Does it compress before or after applying the encryption? And, in case it's relevant, here is the relevant excerpt from the web.xml file we use: security-constraint web-resource-collection web-resource-nameEverything/web-resource-name url-pattern*.jsp/url-pattern url-pattern*.html/url-pattern url-pattern*.js/url-pattern Brevity: url-pattern/*/url-pattern url-pattern/APP1/url-pattern url-pattern/APP2/url-pattern If those actually represent real webapps, with their own WEB-INF/web.xml, the lines above don't do anything. p /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Any assistance would be much appreciated. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
Jeffrey Janner wrote: OK, another newbie-ish question here. Then a dummy-ish answer may be sufficient : Will setting the HTTPS connector compression=on actually compress the data for HTTPS? It will compress all data it would compress it it wasn't HTTPS. Does it compress before or after applying the encryption? Before. HTTPS is at a lower level, at the connection level. I'm not even sure that Tomcat is really involved. As far as responses are concerned, Tomcat probably just hands them over to the socket (in clear, normal), and it is the socket which does the SSL encryption. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
-Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 02, 2009 11:12 AM To: Tomcat Users List Subject: Re: Compression and SSL On 02/11/2009 16:48, Jeffrey Janner wrote: OK, another newbie-ish question here. I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or Windows 2008 x64 to serve applications from the US to Asia-based clients. We encrypt everything using SSL, from Login page onward, with transport-guarantee of CONFIDENTIAL. All URLs are configured as relative, i.e., /images/picture.png, /APP1?param1=value, etc. We use Tomcat as the web server with no intervening proxies, load-balancers, accelerators, etc. Response time is noticeably slow (based on complaint level) and I am looking for ways to improve it. Bigger server? Will setting the HTTPS connector compression=on actually compress the data for HTTPS? What makes you think that compressing things is going to improve matters? Doing the compression is an overhead itself. In general, Compressing HTML can help a great deal for any case besides a local network. A typical HTML page will compress by a factor of 6 or so. Compressing a 42 K page can result in a 7K page. This reduces the typical packet count from 28 or so to around 5. Even with the overhead of compressing the HTML on the server, and decompressing it, this can yield a great performance improvement for any user. If there are fewer packets, there are fewer lost packets. Additionally, you're reducing the overhead of sending the packets through the OS. If you're serving a great deal of data, through a pipe of a fixed size, this effectively makes your pipe 6 times bigger (assuming it's mostly HTML you move). So, your pipe isn't as full, and you're not paying for as much bandwidth. So, compression of HTML is a really valid technique that will be helpful for any case beyond the local network. The one caveat is the compressability of the data. For example, you're not going to get much improvement attempting to compress JPG images. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
2009/11/2 George Sexton geor...@mhsoftware.com In general, Compressing HTML can help a great deal for any case besides a local network. ... or a CPU-limited server. To the OP: What's the bottleneck in your environment? CPU? Disk I/O? Network bandwidth? Measure the problem, *then* look for solutions to the problem that actually exists. If you've measured and you have CPU to spare but are bandwidth-limited, then compression will help a great deal! - Peter
RE: Compression and SSL
-Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Monday, November 02, 2009 12:35 PM To: Tomcat Users List Subject: Re: Compression and SSL 2009/11/2 George Sexton geor...@mhsoftware.com In general, Compressing HTML can help a great deal for any case besides a local network. You didn't read the original post very closely. to serve applications from the US to Asia-based clients. It's bandwidth and latency. ... or a CPU-limited server. To the OP: What's the bottleneck in your environment? CPU? Disk I/O? Network bandwidth? Measure the problem, *then* look for solutions to the problem that actually exists. If you've measured and you have CPU to spare but are bandwidth-limited, then compression will help a great deal! - Peter George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression and SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 11/2/2009 11:48 AM, Jeffrey Janner wrote: We encrypt everything using SSL, from Login page onward, with transport-guarantee of CONFIDENTIAL. [snip] Response time is noticeably slow (based on complaint level) and I am looking for ways to improve it. The real question is: how much slower is it than non-secure HTTP? If the answer is a lot slower, then you should focus your efforts on improving the SSL performance. Here are some suggestions in that vein (from most significant to least, IMO): 1. [Per Pid] Get a bigger machine. More CPU cycles are always helpful 2. Get an SSL accelerator board/appliance. That's what they're there for 3. Switch architectures to something that is better. This is getting to be hard to do since it looks like x86 and x86-64 are pretty much going to be the way of the future. My experience in the past was that a single Sun server could handle a significantly higher load more quickly than (roughly) equivalent CPU x86 horsepower. 4. Choose a simpler SSL cipher. Some ciphers take much more CPU than others. Similar to #3, this is less likely to be useful, as simpler ciphers suck, which is why they are faster :) If compressing HTTP-only traffic yields a significant improvement, then go ahead and compress your HTML. Will setting the HTTPS connector compression=on actually compress the data for HTTPS? Any reason to suspect it wouldn't? Does it compress before or after applying the encryption? HTTPS is defined to be HTTP-over-SSL which means that the encryption is preformed on the whole connection. So, your HTML gets compressed, then encrypted. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvPK4ACgkQ9CaO5/Lv0PA5HgCdEwrU7Ie8YrJDQLROxH5YPdHN ALUAoLKVSGnrCfS0TgBhjFr5PJdUQ00I =MG89 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
Pid - Windows 64-bit Dual Quad-Core w/32G RAM. Do I really need bigger? App's not really slow-- works great here. But with a 300ms latency (one-way) to The Orient, you can see why I might want to send as few bits as possible. Jeff -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 02, 2009 12:12 PM To: Tomcat Users List Subject: Re: Compression and SSL On 02/11/2009 16:48, Jeffrey Janner wrote: OK, another newbie-ish question here. I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or Windows 2008 x64 to serve applications from the US to Asia-based clients. We encrypt everything using SSL, from Login page onward, with transport-guarantee of CONFIDENTIAL. All URLs are configured as relative, i.e., /images/picture.png, /APP1?param1=value, etc. We use Tomcat as the web server with no intervening proxies, load-balancers, accelerators, etc. Response time is noticeably slow (based on complaint level) and I am looking for ways to improve it. Bigger server? Will setting the HTTPS connector compression=on actually compress the data for HTTPS? What makes you think that compressing things is going to improve matters? Doing the compression is an overhead itself. What's slow about your app and how do you know it? Does it compress before or after applying the encryption? And, in case it's relevant, here is the relevant excerpt from the web.xml file we use: security-constraint web-resource-collection web-resource-nameEverything/web-resource-name url-pattern*.jsp/url-pattern url-pattern*.html/url-pattern url-pattern*.js/url-pattern Brevity: url-pattern/*/url-pattern url-pattern/APP1/url-pattern url-pattern/APP2/url-pattern If those actually represent real webapps, with their own WEB-INF/web.xml, the lines above don't do anything. p /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Any assistance would be much appreciated. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
André - Thanks for the nice answer. Precisely what I was looking for to make a decision. I'll try turning it on for one customer tonight and see if we really improve things. Jeff -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, November 02, 2009 12:59 PM To: Tomcat Users List Subject: Re: Compression and SSL Jeffrey Janner wrote: OK, another newbie-ish question here. Then a dummy-ish answer may be sufficient : Will setting the HTTPS connector compression=on actually compress the data for HTTPS? It will compress all data it would compress it it wasn't HTTPS. Does it compress before or after applying the encryption? Before. HTTPS is at a lower level, at the connection level. I'm not even sure that Tomcat is really involved. As far as responses are concerned, Tomcat probably just hands them over to the socket (in clear, normal), and it is the socket which does the SSL encryption. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
Peter - It's primarily the network bandwidth. The best-case latency to Asia from the US is about 150ms (assuming speed-of-light, no hardware delays). What we see on bi-directional traceroutes is an across-the-ocean delay of 200ms to 300ms on a good day. That translates to adding roughly 1 second to response time. Depending on the page, we probably run from 8k to 1-2 Mb of text. And that doesn't include uploads/downloads of user's files. Jeff -Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Monday, November 02, 2009 1:35 PM To: Tomcat Users List Subject: Re: Compression and SSL 2009/11/2 George Sexton geor...@mhsoftware.com In general, Compressing HTML can help a great deal for any case besides a local network. ... or a CPU-limited server. To the OP: What's the bottleneck in your environment? CPU? Disk I/O? Network bandwidth? Measure the problem, *then* look for solutions to the problem that actually exists. If you've measured and you have CPU to spare but are bandwidth-limited, then compression will help a great deal! - Peter *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Compression and SSL
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Will setting the HTTPS connector compression=on actually compress the data for HTTPS? Any reason to suspect it wouldn't? Some result from a Google search I did trying to find a solution to this issue led me to infer that it didn't. I figured it was wrong but thought I'd ask the gurus. Does it compress before or after applying the encryption? HTTPS is defined to be HTTP-over-SSL which means that the encryption is preformed on the whole connection. So, your HTML gets compressed, then encrypted. That's what I figured it should do. *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments.
RE: Compression and SSL
Thanks for all the suggestions so far guys. Are there any other tips I could provide to the developers that they can do to improve throughput? Should they hard-code the http:// for all the static elements to avoid passing them over SSL, or do my security constraints take care of that? (I doub it.) The original URL gets redirected to https immediately, so I'm thinking everything from there on out is SSL. Correct? Can I get more granular? I'd be happy for a pointer to a good reference on the subject. Jeff -Original Message- From: George Sexton [mailto:geor...@mhsoftware.com] Sent: Monday, November 02, 2009 1:56 PM To: 'Tomcat Users List' Subject: RE: Compression and SSL -Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Monday, November 02, 2009 12:35 PM To: Tomcat Users List Subject: Re: Compression and SSL 2009/11/2 George Sexton geor...@mhsoftware.com In general, Compressing HTML can help a great deal for any case besides a local network. You didn't read the original post very closely. to serve applications from the US to Asia-based clients. It's bandwidth and latency. ... or a CPU-limited server. To the OP: What's the bottleneck in your environment? CPU? Disk I/O? Network bandwidth? Measure the problem, *then* look for solutions to the problem that actually exists. If you've measured and you have CPU to spare but are bandwidth-limited, then compression will help a great deal! - Peter George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
