Re: Security fix that started all this

[Jason Rodrigues <..hidden..>]

On Friday 08 September 2006 16:35, Christopher Murtagh wrote:
>  Yes, but a difference of 50 milliseconds and .5 seconds is negligible
> to a user sitting behind their browser (and I doubt it would be that
> much of a difference). Serving css as a cgi has other advantages,
> including tweaking the css depending on the http_user_agent.  We did
> the same thing for www.mcgill.ca, and it really helped keep display
> logic (tweaking for browser odities, etc) away from the core code and
> allowed us to make the pages look the same in a lot of browsers.

Oh yea, the difference is negligible on a single request, and I'd say that 
communicating w/ the server is the most expensive time-wise part of a css 
request transaction. 

> Yes, again there is more overhead, but are these machines really being
> taxed? I might be completely misjudging how this software is being
> used, but I would imagine that in many cases it is a dedicated box for
> the accounting software, in which case even a PIII could do this
> without blinking. In the cases where the machine is doing other things
> as well, again, it's a matter of scoping out the hardware for the job.
> Are people running their installations on near capacity?

I only bring up this technique because at my 'day job' we used to have css 
served a cgi-registry script, and we had to handle all the little header 
things.  We moved to a 2-server setup, w/ a Apache2 proxy server on the front 
handling static content where it can (css files, images) and a passing 
dynamic scripts back to the Mod_perl  server.  This frees up mod_perl servers 
for handling more dynamic content, since they don't have to be idle serving 
static files to slow clients.  it also saved us a bit of bandwidth, our .cgi 
wasn't handling not-modified responses, and spewed out the whole 3/4k 
stylesheet @ every request.  It added up over the course of a day ...

The real gain, is letting apache handle things like timestamps, 302 not 
modified responses, headers, and what not.

Someone brought up on the list that it is unlikely that *really* large 
organizations are using SQL-ledger for their accounting.  The company I'm 
supporing using this app only has 3-4 users *AT MOST* using the software @ 
the same time.  That's not even req/sec, more like req/min.  Our 1.6ghz p4 
hardly breaks a sweat on this.  And they're doing fairly well revenue wise.

Jason