Re: WebServer: caching responses

[Richard Frith-Macdonald]

On 21 Jul 2011, at 14:36, David Ayers wrote:

> Hello Richard,
> 
> we are currently prototyping a conversion of our application from out
> old GSWeb Snapshots we are using to WebServer.
> 
> We are not sure yet whether we want to use WebServer as a replacement
> for Apache or whether we will try implement an Apache module to merely
> pass us the application specific requests.
> 
> One thing I noticed though ist that the delegate's API for generating
> responses:
> 
> - (BOOL) processRequest: (GSMimeDocument*)request
>               response: (GSMimeDocument*)response
>                    for: (WebServer*)http;
> 
> - (BOOL) preProcessRequest: (GSMimeDocument*)request
>                  response: (GSMimeDocument*)response
>                       for: (WebServer*)http;
> 
> - (void) postProcessRequest: (GSMimeDocument*)request
>                   response: (GSMimeDocument*)response
>                        for: (WebServer*)http;
> 
> 
> already provides a response which must be modified.  If we took the
> route of trying to fully replace apache, we'd definitely need a way to
> cache and reuse responses for static resources.  But sometimes we may
> even want to cache some dynamic responses in the module case.
> 
> Did I miss an API to accomplish this, or would you consider augmenting
> the API to allow the Application to reuse responses?


The WebServer class is specifically designed for dynamic pages, not static ones 
(normal usage is to have apache serve static pages and WebServer serve the 
dynamic ones).
That being said, it's trivial to cache the body of static responses (I would 
just use an instance of GSCache to store the body, and put that in the 
response) ... which gets you a reasonably fast result, but will still produce 
rather more cpu load than using apache would.

I don't mind extending the API if you really don't want to use WebServer in 
conjunction with apache ... I would expect existing performance is good for 
most purposes, but it could be faster (and I've been thinking about adding 
support for streaming video, which is the other case the existing code isn't 
really designed to deal with).