womble's answer is awesome, albeit a bit hard to understand and apply for the unexperienced. I'd like to give some empirical numbers, and "simple content" versus "e-commerce" application comparison.
There isn't much material around setting different use cases in relation to their appropriate configuration of mod_wsgi, so I hope it's okay to use a little prose here.
A) CMS Sites & Microsites
We run several customer websites, most of them mainly content sites or micro sites hosting django CMS, some custom forms, and sometimes Celery for scheduled background tasks. These sites aren't hungry for resources, several of them run happily in parallel on a single 4 Core Intel Xeon with 32 GB RAM. Here's the configuration we use for each of this kind of sites:
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
I'm talking about roughly 40 sites on a single server, most of them with their Staging site running in standby. With 2 processes (having 15 threads each, by default) the sites are well-off, albeit limited in their capability of allocating server resources. Why this setup is sufficient can be justified with the simple nature of the (CMS) application: No request is ever expected to take more than a couple of milliseconds to complete. Apache will always stay relaxed, and so will be the CPU load.
B) E-Commerce Sites
More complex sites we do are characterized by still computationally inexpensive local operations but external dependencies (e.g. web services providing booking data) that are expensive in terms of transaction time. Operations with external requests occupy threads for much longer time, so you need more threads to cater the same number of users (compared to a simple CMS site from above). Even worse, threads are occasionally blocked when an external service can't answer a request immediately, sometimes for a couple of seconds. This can lead to the unpleasant side-effect that threads placing requests to the same service queue up, until all available mod_wsgi threads are used up and blocked waiting.
For those scenarios we have tried to use 6
processes without seeing much difference, and we ended up with 12
seeing an incomparable boost in performance and operational stability:
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
Some simple load tests with 150, and 250 parallel users are easily handled by the site staying well responsive (while with 2
processes the site is unusable catering 50 users in parallel). The 2 CPU 6 Core Intel Xeon with 32 GB RAM runs well below 25% CPU usage under that load, RAM usage almost stays constant at less than 25%, too. Note that we use a dedicated machine just for a single site here, so we won't steal resources that other sites may need.
Conclusion
Using a higher number of processes is a trade-off between allowing Apache to make use of available system resources or not. If you want to keep a stable server system (not website!) under "attack" conditions keep the number low. If you want Apache to help you out using system resources (CPU, RAM) when needed choose a higher number. How high you can go calculates somewhat like outlined in the accepted answer above, and is ultimately constrained by the available CPU power and RAM.
(P.S.: I keep the ConfigurationDirectives section of the modwsgi project wiki under my pillow for Apache-like background reading. Also be sure to understand and monitor your Apache server's open connections.)