"Platonides" wrote:
Okay, so
instead, and only slightly more expensive, go ahead
and hit the counter, but the counter does the randomization check - if
it's
the 1 in 1000, run the code that posts to the database.
But then we fail in the
original problem. A server with billions of
conections... die.
Okay - honestly, I don't have experience with anything approaching that kind
of volume, so I can't speak intelligently about it.
I suppose it would be possible to, instead, only include the counter
javascript in the page (from the server serving the page) one time in 1000,
and use some kind of a shared key system to validate in the counter script.
But at that point, we're adding overhead to the mediawiki server, which is
exactly what we're trying to avoid.
I think it'd be better (and possible) to heuristically identify bad entries
getting posted by malicious users who hack the javascript (although the
shared key solution would be fun to design).
Just to enlighten me: would a gazillion GET requests take down a server
that quickly? I guess it takes a non-insignificant amount of processing
power just to handle the requests...
Aerik