Monday 21 December 2009

Sizing systems based on very little input data

Are there any tried and tested methods of sizing a replacement JavaEE-based system based on typical non-functional requirements (e.g. Active User Session Capacity, Response-Times) coupled to a view of business volumes in transaction-per-minute from, say a DECS/Alpha system?

I was working through this for a couple of days at the end of last year and the point I struggle was the normalisation of one legacy transaction profile (going through terminal session transaction data) into an entirely different Java-based architecture where the end-state transaction and benchmarks will be very different. Does everyone use approximate gearing-factors (e.g. 10x a business transaction) to get to a tpm-C number or are there better approaches to size replacement systems such as using existing system benchmarks like SAP-SD benchmarks. Clearly, the only way is to load-test and profile but what happens if you've only got 1/2-day; you're doing this pre-contract before a line of code can be cut and you barely know what the target architecture will be?

Happy to work through the approach I took but interested in your thoughts.

No comments:

Post a Comment