> On 2008.04.11, Brett Schwarz <[EMAIL PROTECTED]> wrote: > > So, what I am proposing is that ns_return follows a similar structure. > > I'll suggest the introduction of "ns_return_compress ?on|off?" -- > similar to ns_adp_compress, but for ns_return. It would set the > Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP > context. > > > *If* we do decide to go with a "flag" (similar to ns_adp_compress), I > > would like to see the default to be "on". > > In reality, compression of the output stream doesn't make sense until we > implement better server-side caching, which I briefly discussed with Jim > several years ago. The basic idea is: some requests are "mostly static" > ... generated in response to a dynamic request, but the response across > separate requests is static until some event invalidates that cached > response. In that scenario, compression of the response makes sense: > you compress it once and return the compressed version "many" times. >
I agree that smarter caching will definitely improve things. However, I think it depends on the use case for the web app. For example, my web app is an internal tool...and there are small number of users, hence not many request/sec. However, I am doing DB queries heavily with big payloads and my server is sitting in a remote office with a small pipe to the main office. So, in my case, gzipping definitely makes sense. I did some subjective tests, and for my case, compression seems to help. I have also been reading this book "High Performance Web Sites", by Steve Souders (good book BTW), and he advocates compression. He's an engineer at Yahoo, and they did some detailed studies on this. Here is a cheat sheet for those who are interested: http://developer.yahoo.com/performance/rules.html > However, current AOLserver implementation where all dynamic requests are > generated dynamically, compression almost doesn't make sense: how many > folks are still serving content to narrowband (dialup) users? For the > high-bandwidth users, the "cost" (in time spent) of compressing the > response vs. the savings in transmission time is almost equal (thus the > "minsize" parameter, preventing small responses from even being > compressed at all). IMHO, I think the "cost" vs response time savings will lessen more in the future, so the benefits of compression will become more so. > > This can partially be addressed in current AOLserver by writing a > request handler that checks an NSV cache. On cache misses, the response > is generated, compressed and stored in the NSV cache and returned to the > client. On cache hits, it's simply an NSV fetch from cache and return > the already compressed response. > It would be great if the core server would handle this ;) Thanks, --brett __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
