[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Security fix that started all this
- Subject: Re: Security fix that started all this
- From: Jason Rodrigues <..hidden..>
- Date: Fri, 8 Sep 2006 16:53:43 -0400
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
> 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.