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.
In reply to Re^3: A distributed design challenge
by BrowserUk
in thread A distributed design challenge
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |