"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