Jim Sims wrote:
I'm discussing the development of a promotional marketing tool with
someone who services the internet gaming industry here in Malta
(poker, bingo, casino, etc.). About ten years ago he did something
similar with a software company that went on to sell a license to the
BBC. They had problems when they tried to scale to the large numbers
of users the BBC threw at them. So, a few thousand users would be the
starting point. Most gambling companies have around 3-6,000 hardcore
users but tons of occasional users.
What I have already concocted is the text file only contains the name
of the last version presented (the name is the milliseconds plus
.txt), when the users application gets that number it checks locally
with a userProp that contains the name of the last version they saw.
I've been thinking of having the polling take place very five minutes
or so as this is not a life threatening situation or crucial (although
Marketing guys can be 'life threatening' ;-)
That sounds pretty good. 6000 users spread over 5 minutes is only 20
requests per second - easy-peasy.
Now if they have "tons" of occasional users, and a successful marketing
campaign, does that 6000 turn overnight into 600,000? And if so, do
they have servers capable of dealing with a continual load of 2000
requests per second PLUS the load of sending each of those 600,000 users
the update when it happens ?
If I understand you, then UDP is probably not going to get the job
done as there will be a wide variety of users, all with individual ISP
and firewall setups that are not in my control. Maybe my original
design is close to the mark (polling). Polling every 20 - 30 minutes
is a possibility. Being consistent with the timing so every user has
equal odds is the important thing. I suppose they could poll once an
hour if need be, but being able to say more frequently helps my
Marketing message in selling this ;-)
Extending the polling cycle can help; in fact, you could consider making
it dynamic, for instance by allowing the server to put into that
one-line file not just the name of the latest update, but also the
polling cycle to be used. Then you can (some time in the future, if
needed) either just increase it, or allow the server to dynamically
update it. (Marketing - "you can tune the update frequency based on
number of users to minimize the delay during quiet times while avoiding
getting overloaded during busy times".)
btw - are the updates/events truly random timing ? or could the
server have some idea of when the next update will be available ? If
so, have the reply to the polls include an estimated 'next event
time', so the client can vary his polling cycle.
Totally random - when the Marketing dudes want to release some
promotion then they will use this. I would anticipate it only being
used a handful of times per day.
And also consider trying to keep the polling times random. You want
to avoid the case where the clients will align their query times,
causing surges of queries (and indeed of eventual updates); the
simplest way is probably to make the pollling times be (say) 120
seconds +/- random(20 seconds).
As the polling will initiate according to when they start their
application then it should be random anyway.
Ahhh. How random will it be ?
There is one phenomenon (which may or may not be an Urban Myth)
associated with this kind of scalability that could hit you.
The Super-Bowl surge
During the first minute of the half-time break in the televised Super
Bowl, something like 25% of homes in the US switch on a significant
appliance (kettle, coffee maker, microwave, pop-corn maker, etc.). This
leads to one of the sharpest spikes in electrical demand. (Also known
as the Super Bowl flush - a similar percentage of houses flush at least
one toilet in that same time interval, leading to unusually high load on
the sewer system).
I doubt if you'd suffer that kind of uneven demand, certainly not from
the Super Bowl (I stayed up till 3am to watch it, but I doubt if many in
Europe did :-) But you may well see your users unevenly spread over
time, say because of TV schedules or the World Cup final or other such
events; in the US where almost all programs start/finish on the
hour/half-hour boundary, you may well see over 50% of your users start
their app during the 00-05 minute interval, with a smaller peak in 30-35
minute interval. In that case, changing your polling time from 5 minutes
to 30 minutes may make little difference ..... but then including some
randomisation will help.
Of course, the second issue is that it's not just the polling you need
to worry about, it's actually satisfying the demand when there *is* an
update available. Do all 6000 users (or 600,000) then download some real
file or data ? Can you cope with that ? (This is where load-balancing
might come into its own).
-- Alex.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
