After you've done that, provision resources as follows. Figure out how big your FastCGI processes are. Decide how much RAM you wish to dedicate to FastCGI. The number of processes that you should spin up per box should be RAM/(size + some safety buffer). The number of machines you should have should be based on your peak usage plus some amount of headroom for growth, spikes, etc, with a fixed number of extra machines for failover in case a machine crashes.

If you have less than a million dynamic pages/hour and a reasonably written application, odds are good that the number of machines you will need is more determined by provisioning for failover than it is by the resources needed to meet your load.

Thank you tilly and sundialsvc4. Thats pretty much what I was looking for.

• Are fastcgi processes actually the bottleneck?
• How many visitors are you expecting?
• How many are you expecting at a time?
• How many requests would each visitor typically generate?
• How much memory can you dedicate to running fastcgi processes?
• How long does each process take to run (on average)?
• Can you leave your users hanging round for a second or two?
• What possibilities exist for caching images once they're generated and serving them up statically?

The process-count is really not the issue here, if there is actually an issue here at all.   The first question that I would have is ... “is anything actually hurting?”   (If not, you have No Problem.)   If there actually is pain, then you need to address that by simplifying the amount of work, e.g. by storing thumbnails in a database once they have been generated the first time.   The number of processes that might be “generating a thumbnail” is probably not going to be a significant issue, although if it is, that, too, is controllable.