Hi all,
Most of the content that we serve up using Apache is gziped either using Apache's mod_deflate ( we used mod_gzip with apache 1.3) or using PHP's output buffering capabilities. My users have become accustom to the quick download times of our web biased applications. Gziping content makes a huge difference with our applications. Does Kom support this? If it does not appear that it would be a huge undertaking. Any pointers on where to begin ? Does anyone know if Apache can act a a gzip proxy ? Gziping non-ziped content served from seaside. Has any one done this? Any examples? The only idea I had was to use mod_php/mod_perl to handle the proxying and gziping from a seaside image. I am not sure what the performance hit would be but it just feels hackish to me. In my mind the best solution would be Gzip support in Kom. Any ideas? Thanks Will _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Gziping content makes a huge difference with our applications. Does
> Kom support this? If it does not appear that it would be a huge > undertaking. Any pointers on where to begin ? You could subclass WAKom and start with something like: WAKomCompressed>>convertResponse: aResponse | response gzip stream | response := super convertResponse: aResponse. response fieldAt: 'Content-Encoding' put: 'gzip'. gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). gzip nextPutAll: aResponse contents contents; close. ^ response contents: stream reset This code does not check if the user-agent supports compressed responds, most todays user-agents do that anyway and one could add it easily. However I doubt that this will make the web-application any snappier, I guess it is even much slower because the stream has to be copied to a compressed one. After all the XHTML of Seaside is already quite dense, there are no unnecessary spaces as with most other frameworks. It is a bit trickier and requires some modifications to Seaside if you want to directly stream you answer into a compressed stream, tough it should be possible. > Does anyone know if Apache can act a a gzip proxy ? Gziping non-ziped > content served from seaside. Has any one done this? Any examples? I never felt the need to do anything like that, the bottleneck is usually the persistency backend or the domain-model itself, not the network connection. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Mar 23, 2006, at 3:55 AM, Lukas Renggli wrote: > > You could subclass WAKom and start with something like: > ... > > However I doubt that this will make the web-application any snappier, > I guess it is even much slower because the stream has to be copied to > a compressed one. After all the XHTML of Seaside is already quite > dense, there are no unnecessary spaces as with most other frameworks. After some quick testing the diffrence it to small either way to make much of a difference. If I was on a 56k modem it might make a difference but none of our users are. It might be a good idea to do anyway. I can't see it hurting anything and for large pages it would make a difference. Thanks for the sample code. Will. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
I just tested it over an apache proxy doing SSL and it doubled the download speed of my application. It appears that in my situation it is quicker for Squeak to compress the contents and apache to encrypt the compressed content than it it to encrypt the non-compressed content. I would highly recommend to anyone to give the below code a try in your situation. Why waste the bandwidth, your users on slower connections will see a big increase in download speed, your users on faster connections will have more bandwidth for other things, and you might save a few bucks on your ISP costs. I don't see there being much or any downside to doing this (maybe a bug or two) and you get to be a good net citizen by conserving bandwidth. Personally I would love to see it's widespread adoption. Thanks Will On Mar 23, 2006, at 3:55 AM, Lukas Renggli wrote: >> Gziping content makes a huge difference with our applications. Does >> Kom support this? If it does not appear that it would be a huge >> undertaking. Any pointers on where to begin ? > > You could subclass WAKom and start with something like: > > WAKomCompressed>>convertResponse: aResponse > | response gzip stream | > response := super convertResponse: aResponse. > response fieldAt: 'Content-Encoding' put: 'gzip'. > gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). > gzip nextPutAll: aResponse contents contents; close. > ^ response contents: stream reset > > This code does not check if the user-agent supports compressed > responds, most todays user-agents do that anyway and one could add it > easily. > > However I doubt that this will make the web-application any snappier, > I guess it is even much slower because the stream has to be copied to > a compressed one. After all the XHTML of Seaside is already quite > dense, there are no unnecessary spaces as with most other frameworks. > > It is a bit trickier and requires some modifications to Seaside if you > want to directly stream you answer into a compressed stream, tough it > should be possible. > >> Does anyone know if Apache can act a a gzip proxy ? Gziping non-ziped >> content served from seaside. Has any one done this? Any examples? > > I never felt the need to do anything like that, the bottleneck is > usually the persistency backend or the domain-model itself, not the > network connection. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |