RE: compression?
Hi Mark crisb> P.S.: If a documentation update is recommended, crisb> I would be happy to make the changes, crisb> but I would probably need guidance for that too. ;-) markt> Source file is here: markt> https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml markt> A pull request is fine. Pull request #442 created on http.xml, "clarified compressionMinSize and compressibleMimeType". -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
RE: compression?
Thanks Mark :-) crisb> Is it possible to connect IIS to TC using HTTP instead of AJP? crisb> Several "Tomcat IIS How-To" articles all mention using AJP crisb> (not HTTP) using an ISAPI redirector. markt> In theory, yes. You'd need to find an HTTP reverse proxy component for IIS. markt> This looks like the sort of thing you'd need: markt> https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/ markt> reverse-proxy-with-url-rewrite-v2-and-application-request-routing markt> The downside is that you will need to manually configure a lot of the stuff markt> AJP does "for free". Correctly configuring a reverse proxy is one of those markt> tasks where all sorts of things can catch you out. Yeah, that looks way more complicated than what I was hoping for. Talked with the sysadmin about it and he agreed, even though he implemented it on at least one of our dev servers. We may roll that back in light of your suggestion below. markt> I'd probably look at getting IIS to compress the content instead: markt> https://docs.microsoft.com/en-us/iis/extensions/iis-compression/iis-compression-overview That looks better, much less complex and fragile. I see in the " element in applicationHost.config" that you can specify mimeType's - perfect. We'll see what the SA thinks. The other option the SA and I talked about was dropping IIS altogether. ;-) -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: compression?
On 27/07/2021 13:08, Berneburg, Cris J. - US wrote: Carsten and Mark Thanks for the info. :-) crisb> Weird, when going thru IIS to TC, it's not compressed c.klein> IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). markt> IIS will be using AJP to talk to Tomcat which doesn't support compression. You may be able to get IIS to compress the files. Is it possible to connect IIS to TC using HTTP instead of AJP? Several "Tomcat IIS How-To" articles all mention using AJP (not HTTP) using an ISAPI redirector. In theory, yes. You'd need to find an HTTP reverse proxy component for IIS. This looks like the sort of thing you'd need: https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing The downside is that you will need to manually configure a lot of the stuff AJP does "for free". Correctly configuring a reverse proxy is one of those tasks where all sorts of things can catch you out. I'd probably look at getting IIS to compress the content instead: https://docs.microsoft.com/en-us/iis/extensions/iis-compression/iis-compression-overview Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: compression?
Carsten and Mark Thanks for the info. :-) crisb> Weird, when going thru IIS to TC, it's not compressed c.klein> IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). markt> IIS will be using AJP to talk to Tomcat which doesn't support compression. You may be able to get IIS to compress the files. Is it possible to connect IIS to TC using HTTP instead of AJP? Several "Tomcat IIS How-To" articles all mention using AJP (not HTTP) using an ISAPI redirector. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: compression?
Chris, Weird, when going thru IIS to TC, it's not compressed: HTTP/1.1 200 200 Content-Type: application/json;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 That has likely nothing to do with TC. It's an IIS or reverse proxy thing. IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). It gets a compressed response. What does IIS do next? It just uncompresses the resource and sends it back as response to its client (your browser). So, it's up to IIS or its reverse proxy module (whatever) to fix that. Maybe there is an option to tell IIS not to uncompress the response. Or you could add compression to IIS a well. Yes, in that case, TC compresses, IIS uncompresses and compresses again... :( Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: compression?
On 23/07/2021 18:53, Berneburg, Cris J. - US wrote: Thanks Mark! cb> 1. compressionMinSize - What are the units, bytes? Markt> Yes. cb> 2. compressibleMimeType - If you specify a type explicitly, [...] Are [the defaults] cb> over-ridden, so they need to be specified explicitly too? Or is it cumulative? Markt> Default is over-ridden. OK, that worked when connecting directly to TC: HTTP/1.1 200 vary: accept-encoding Content-Encoding: gzip Content-Type: application/json;charset=UTF-8 Content-Language: en-US Transfer-Encoding: chunked Date: Fri, 23 Jul 2021 16:37:48 GMT Keep-Alive: timeout=20 Connection: keep-alive Weird, when going thru IIS to TC, it's not compressed: IIS will be using AJP to talk to Tomcat which doesn't support compression. You may be able to get IIS to compress the files. Mark HTTP/1.1 200 200 Content-Type: application/json;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 cb> P.S.: If a documentation update is recommended, I would be happy to cb> make the changes, but I would probably need guidance for that too. ;-) Markt> Source file is here: Markt> https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml Markt> A pull request is fine. If you prefer to provide a patch, use "diff -u" Markt> format, create a BZ issue and attach the patch. I'll have a look at it later. Also, I'm quite a newbie with git. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - 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?
Thanks Mark! cb> 1. compressionMinSize - What are the units, bytes? Markt> Yes. cb> 2. compressibleMimeType - If you specify a type explicitly, [...] Are [the defaults] cb> over-ridden, so they need to be specified explicitly too? Or is it cumulative? Markt> Default is over-ridden. OK, that worked when connecting directly to TC: HTTP/1.1 200 vary: accept-encoding Content-Encoding: gzip Content-Type: application/json;charset=UTF-8 Content-Language: en-US Transfer-Encoding: chunked Date: Fri, 23 Jul 2021 16:37:48 GMT Keep-Alive: timeout=20 Connection: keep-alive Weird, when going thru IIS to TC, it's not compressed: HTTP/1.1 200 200 Content-Type: application/json;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 cb> P.S.: If a documentation update is recommended, I would be happy to cb> make the changes, but I would probably need guidance for that too. ;-) Markt> Source file is here: Markt> https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml Markt> A pull request is fine. If you prefer to provide a patch, use "diff -u" Markt> format, create a BZ issue and attach the patch. I'll have a look at it later. Also, I'm quite a newbie with git. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: compression?
On 21/07/2021 15:06, Berneburg, Cris J. - US wrote: Hi Folks :-) Got some questions about turning on compression. Looking at the documentation (I did not read the whole thing, just the portions in question), I still need some clarification. https://tomcat.apache.org/tomcat-8.5-doc/config/http.html 1. compressionMinSize - What are the units, bytes? Yes. 2. compressibleMimeType - If you specify a type explicitly, like "application/json", what does it do with the defaults, like "text/html"? Are they over-ridden, so they need to be specified explicitly too? Or is it cumulative? Default is over-ridden. Thanks for your time. P.S.: If a documentation update is recommended, I would be happy to make the changes, but I would probably need guidance for that too. ;-) Source file is here: https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml A pull request is fine. If you prefer to provide a patch, use "diff -u" format, create a BZ issue and attach the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression for Resources served through DefaultServlet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 11/26/18 18:53, Leon Rosenberg wrote: > On Mon, Nov 26, 2018 at 10:27 PM Mark Thomas > wrote: > >> On 26/11/2018 21:19, Leon Rosenberg wrote: >>> Good time of the day, >>> >>> I am debugging bad page insights reported by google for a >>> mobile versus desktop version of our site and I'm seeing that >>> the static resources, served by the DefaultServlet (aka files) >>> aren't compressed, versus to dynamic resources served by a >>> servlet. Tomcat version in question 8.5.15 and 8.5.31 (tested >>> on both) >> >> http://tomcat.apache.org/tomcat-8.5-doc/config/http.html >> >> Search for sendfile. >> >> ? >> > > I thought sendfile is NIO only, this was probably the mistake. It's for NIO/NIO2 and APR, and on by default. Those are the only connectors available these days, so by default sendFile=true and therefore compression=false. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv8lZsACgkQHPApP6U8 pFg7GhAAnYAlwdMTkpe1i995Q1mFKfOV5GTU8IpqFXFadnaiNov/mpWX64IVSGQB 3B2m0CwHgQE1Nv0lh/3AHleqC54S5i8Hiuhw3YiYBQ6xfKVbctrG2m+97WtgXSzG lwV2pUw1nsJlJ/Wlnc+/Pf1DUN6p5r8IMSIP4NnuhM0KSYwJi60bN2w10ZJsMpDR 6DFkLMT+g3LQ7lvsRsol99AQkpbkeEpUypRr1y5/duvkqz/8A/8WX4kZ7+Ix5oah y+hLmd31nqjE03wAnacLfiMQ4ziUzh0MNKfjJUnccOvK5eXLSpE6uvAtA6nsMuAK 3HxsGsDTc6wdeF6oEU3MY16AdnG6mGOhfASCv5tMqkDYrzKLnznN7dmYCpzikgjR S3SzYGoXm+YE5n0ciA/aKat+701YJZX9N9LJak60A9+eJ9Xr0gG81t/4H6FW8uo2 0M5ukNhBy08M5yqFbz3rQmDEZdOsCOCO9Mb+2ABusnjupnadBCfonUSD+JVNezXm 7im0PiiNuXGigrmURS85xAtE3VJIt9mTCylbLxMDMJw3LdZUrMpd0AK/VuBPK5/0 zjn1JvqB6qosdCqnKvERk85EKY4c4mfqVVVDl0Ok0pJcH5x3rgnmyaysjDaUy0sX ap3plQplGRpJI6J+b9QLrviYEq/4uFYabQIoEJ7p1Lm+Jq8JjhI= =eiE1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression for Resources served through DefaultServlet
On Mon, Nov 26, 2018 at 10:27 PM Mark Thomas wrote: > On 26/11/2018 21:19, Leon Rosenberg wrote: > > Good time of the day, > > > > I am debugging bad page insights reported by google for a mobile versus > > desktop version of our site and I'm seeing that the static resources, > > served by the DefaultServlet (aka files) aren't compressed, versus to > > dynamic resources served by a servlet. > > Tomcat version in question 8.5.15 and 8.5.31 (tested on both) > > http://tomcat.apache.org/tomcat-8.5-doc/config/http.html > > Search for sendfile. > > ? > I thought sendfile is NIO only, this was probably the mistake. Thank you. Leon > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Compression for Resources served through DefaultServlet
On 26/11/2018 21:19, Leon Rosenberg wrote: > Good time of the day, > > I am debugging bad page insights reported by google for a mobile versus > desktop version of our site and I'm seeing that the static resources, > served by the DefaultServlet (aka files) aren't compressed, versus to > dynamic resources served by a servlet. > Tomcat version in question 8.5.15 and 8.5.31 (tested on both) http://tomcat.apache.org/tomcat-8.5-doc/config/http.html Search for sendfile. ? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression with APR connector and SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raul, On 7/28/16 2:25 PM, Martinez Maestre, Raul (CIT-IOEP) wrote: > Hi, > > > > I have configured APR with the following versions for components > > -APR version 1.5.2 > > - Open SSL version openssl-1.0.2h > > - Apache Tomcat Native library 1.2.7 > > > > The HTTPS connector on server.xml is the shown below. All works > properly ex= cept compression, no way to have contents compressed > in client side. Someon= e knows what could be missing? How are you determining that compression is not being used? I'm confused. You seem to be enabling compression at a number of places: > compression=3D"on" This should enable gzip compression of the message bodies. > compressionMinSize="2048" > compressableMimeType="text/html,text/xml,text/plain,text/css,te= > xt/javascript,text/json,application/x-javascript,application/javascrip t,app= > > lication/json" This further configures HTTP-compression. > /> h2 enables compression by default. > I think OpenSSL disabled compression by default to mitigate the CRIME attack. Their changelog[1] indicates that happened between 1.0.1h and 1.1.0, and I can't seem to find a similar change that directly affects your version. Try re-building OpenSSL with zlib support included (use either the "zlib" or "zlib-dynamic" build options). You may also be at the mercy of your OS's OpenSSL package maintainers. If you don't have zlib built-in, then you can't use compression even if you want to. If you DO have zlib built-in, you can configure the library to allow compression, but there is no direct-support for enabling this option from Tomcat. Given the CRIME vulnerability, I don't think you want to enable compression for TLS. Also, the default value for "useSendfile" is "true", and when sendfile is in use, HTTP compression is disabled. So, which compression were you trying to enable? TLS compression is a bad idea, so you should try setting useSendfile="false" and trying again . Hope that helps, - -chris [1] https://www.openssl.org/news/changelog.html (search for CRIME) -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAled8WsACgkQ9CaO5/Lv0PCadACdHhS5/k3gqVis5VeX6nha5W+Y lhoAoKYIjAC0lVOLCfJ47/HM9toFixXk =9GCe -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
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
Re: compression filter
On 4/12/06, Martin Gainty [EMAIL PROTECTED] wrote: Any clues where to acquire jar for compressionFilter ??? source and compiled files are in the servlets-examples webapp... HTH! -- Hassan Schroeder [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compression filter
Thanks ! Martin * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Hassan Schroeder [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org; Martin Gainty [EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 5:15 PM Subject: Re: compression filter On 4/12/06, Martin Gainty [EMAIL PROTECTED] wrote: Any clues where to acquire jar for compressionFilter ??? source and compiled files are in the servlets-examples webapp... HTH! -- Hassan Schroeder [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
