1 Million users.. I can't Scale!!

Alan Kennedy alanmk at hotmail.com
Wed Sep 28 20:37:14 CEST 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