1 Million users.. I can't Scale!!
Alan Kennedy
alanmk at hotmail.com
Wed Sep 28 14:37:14 EDT 2005
[yoda]
> I really need help because my application currently can't scale. Some
> user's end up getting their data 30 seconds after generation(best case)
> and up to 5 minutes after content generation. This is simply
> unacceptable. The subscribers deserve much better service if my
> startup is to survive in the market.
> My questions therefore are:
> 1)Should I switch to stackless python or should I carry out experiments
> with mutlithreading the application?
> 2)What architectural suggestions can you give me?
> 3)Has anyone encountered such a situation before? How did you deal with
> it?
> 4)Lastly, and probably most controversial: Is python the right language
> for this? I really don't want to switch to Lisp, Icon or Erlang as yet.
I highly recommend reading the following paper on the architecture of
highly concurrent systems.
A Design Framework for Highly Concurrent Systems, Welsh et al.
http://www.eecs.harvard.edu/~mdw/papers/events.pdf
The key principle that I see being applicable to your scenario is to
have a fixed number of delivery processes/threads. Welsh terms this the
"width" of your delivery channel. The number should match the number of
"delivery channels" that your infrastructure can support. If you are
delivering your SMSs by SMPP, then there is probably a limit to the
number of messages/second that your outgoing SMPP server can handle. If
you go above that limit, then you might cause thrashing or overload in
that server. If you're delivering by an actual GSM mobile connected
serially connected to your server/pc, then you should have a single
delivery process/thread for each connected mobile. These delivery
processes/threads would be fed by queues of outgoing SMSs.
If you want to use a multithreaded design, then simply use a python
Queue.Queue for each delivery channel. If you want to use a
multi-process design, devise a simple protocol for communicating those
messages from your generating database/process to your delivery channel
over TCP sockets.
As explained in Welsh's paper, you will get the highest stability
ensuring that your delivery channels only receive as many messages as
the outgoing transmission mechanism can actually handle.
If you devise a multi-process solution, using TCP sockets to distribute
messages from your generating application to your delivery channels,
then it would be very straightforward to scale that up to multiple
processes running on a either a multiple-core-cpu, a
multiple-cpu-server, or a multiple-server-network.
All of this should be achievable with python.
Some questions:
1. How are you transmitting your SMSs?
2. If you disable the actual transmission, how many SMSs can your
application generate per second?
HTH,
--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan
More information about the Python-list
mailing list