Thanks for the article Steve. It left me wondering though.
As you say your metrics looked good except at certain peak times for certain timezones/geography. So what can one do to alviete the burden of those peak times without upgrading the whole box in all deminsions (or the ones peaking)?
Perhaps the developers could identify the jobs that are sucking the most resources at those peak times and scheme up some sort of pre-processing that could be done in times leading up to the peak.
I guess I approach this from a developer point of view. The first thing I'd do is an over the shoulder analysis of the work performed by users at this peak time, it could turn out that roundtrips to the db could be reduced simply by small changes to application design. I have seen apps where the user ends up having to load up a data heavy screen simply to access a link or a button. So the db is doing a bunch of work to deliver data tghat the users doesn't actual care about. Multiple that by 5,000 seats at tax time and I guess it would save cycles simply to offer them a direct link to the info they want.
I guess there are dozens of schemes that developers can employ; pre-processing, distributed processing, or other design changes but in the final analysis weighing developer time versus a shiny new box, the box might be allot cheaper
IT Training B2B Marketplace
(Jobs for IT Instructors)