|Perl: the Markov chain saw|
Plus, the load I mention is actually very light. We've restricted the requests for the test. In a full-scale production system, we expect at least two orders of magnitude more requests.
The 40,000 figure I used took that 2-orders increase into account.
You are right that 36 servers is overkill, but we have a large setup of servers designed to handle very large loads and it was easier to put our software on these servers than to design a smaller system.
I can understand the motivation for re-using an existing setup if it is lightly loaded.
That said, the whole problem becomes significantly easier to program by utilising SMP shared memory to hold the budgets; And much easier to guarantee if a dedicated machine handles it rather than relying upon excess capacity on the other systems where spikes in the other applications might break this applications latency requirements.
I'd be tempted to try and concentrate the other application(s) onto 34 boxes and filch 2 to dedicate for this application in a primary + hot failover setup.
Of course, I know nothing of the other applications or the internal politics involved that likely make that impractical.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.