Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. At the very least, ns_returnz could be a wrapper for what ns_return would do after figuring out the config/compression engine, etc. But it is very unlikely that changing the ns_return API would be a good idea.
You can also use a trie to hold a filter type list mapping file patterns and compression functions. The code for picking a threadpool should be easy to reuse for this. In fact, you might be able to add a new config param to the threadpool to enable compression, but the two groups might not overlap enough to help. tom jackson On Friday 11 April 2008 14:40, Brett Schwarz wrote: > > 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. -- 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.
