1 Million users.. I can't Scale!!
nochiel at gmail.com
Thu Sep 29 08:48:45 CEST 2005
Thanks for the whitepapers and incredibly useful advice. I'm beginning
to get a picture of what I should be thinking about and implementing to
achieve this kind of scalability. Before I go down any particular
route here's a synopsis of the application.
1)User requests are received only during subscription. We currently
don't have any problems with this because subscription rates increase
along a sigmoid curve.
2)Once a user subscribes we begin to send them content as it becomes
3)The content is sports data. Content generation is dependent on the
day. On days when there's a lot of action, we can generate up to 20
separate items in a second every 10 minutes.
4)The content is event driven e.g. a goal is scored. It is therefore
imperative that we send the content to the subscribers within a period
of 5 minutes or less.
>There is a difference between one million users each who make one request once a >month, and one million users who are each hammering the system with ten >requests a second. Number of users on its own is a meaningless indicator of >requirements.
Quite true and this lack of clarity was a mistake on my part. Requests
from users do not really become a significant part of this equation
because, as described above, once a user subscribes the onus is upon us
to generate messages throughout a given period determined by the number
of updates a user has subscribed to receive.
5)Currently, hardware is a constraint (we're a startup and can't afford
high end servers). I would prefer a solution that doesn't have to
result in any changes to the hardware stack. For now, let's assume that
hardware is not part of the equation and every optimization has to be
software based. (except the beautiful network optimizations suggested)
More information about the Python-list