OT: Warning to Firefox users when developing web integration

[Fairlight]

On Sat, Feb 03, 2007 at 10:13:39AM -0800, Bill Campbell, the prominent pundit,
witicized:
> How would your throttling mechanism work if people are running
> multiple systems though squid or other proxy?

Depends on the settings and version of my software.

AOL used to cache -everything-...and I mean -everything-, ignoring cache
pragmas entirely.  People that used to use my old bulletin board system on
the psych sites from AOL used to end up with the same board contents for
days.  So it's possible for proxies to be written to explicitly ignore what
they are technically not supposed to.

I don't believe in proxies, honestly.  I mean, I know they exist, I'm just
not in favour of them.  :)  Therefore, I've dealt with them very, very
little.  I've worked briefly with apache's mod_proxy, and I really never
touched squid personally.

That said, if the proxy caches by default unless told to otherwise with
Cache-Control, then it's going to be like every other document and get
cached, only touching the server my software is on once every so often when
it needs refreshing.

If it pays attention to "Cache-Control: no-cache", as of version 4.x of
OneGate (in alpha, headed for beta) this will be an option available to
people running OG.  It's specifically going in for AJAX support, along
with most of the other features that went in, but it should apply to any
reasonable proxy.

If it doesn't pay attention to that header (which was never available in OG
3.x, so it's the same situation), it'll do whatever it's configured to do.
It seems most proxies seem to be fairly intelligent about not caching CGI,
or we'd have a lot more problems than have ever been reported to me--which
is none since some old, old stuff pre-1998 with AOL users.  I've never had
anyone complain about proxies with OG, so either the proxies out there are
being sensible, or I've gotten lucky enough that it's never been an issue.

fPCGI apparently got equally as lucky, as I see it doesn't use
Cache-Control either.  Just checked.

My throttling doesn't look at where the request is coming from.  It's
basically connection-driven.  It doesn't care -where- the other
connections are coming from.  All it cares about is that if you define
max_session_count to N, and you get N+X connections, the connections that
are a part of X all hang around for wait_interval*wait_attempts (1*30 by
default) seconds for a chance at running the application underneath my
program.  If a job under the N count "falls off" (completes, one way or
another), one from X takes its place, you have X=X-1, so on, so forth.  It
adds protection for the user license in that you can reserve a segment of
your user license for non-web use (ie., development, cron jobs, etc.), and
it also "extends" the license artificially by acting as a definable queue
that can extend the capacity for receiving request beyond what your user
license is.  Depending on the speed of your processing (or any programs'
runtimes--OG isn't limited to fP by any means), in filePro's case you can
extend your license out probably 30-80% depending how fast your code is in
and out and what settings you give the retry queue.

In the sense that those connections are still made to httpd, and that my
software has an incarnation running for each one accessing applications run
under it, my software is -not- a QoS model, obviously.  Resources can still
be eaten.  It's not meant to act as a QoS service.  It's meant to protect
and extend user licenses by defer/retry.

If 80 hosts and 80 proxies all slam the server at once, they're all going
to slam it at once.  How well things can be serviced depends on the
underlying programs' performance, beefiness of system hardware, etc.  My
code does the best job possible to make sure it will service as many of
those 160 simultaneous requests as possible.  Which...is more than fPCGI
did last I knew.  It just flat-out gives up if there's no seat available.
I don't think that's ever changed.  They added a customisable page at one
point, but I do believe it still just gives up immediately, even in v2.0.

mark->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!