Oh by the way it would be in your best interest to select a ‘peak’ day.
In order to really know what day is a peak day, I think you might want to do this exercise for more than one day.
The real trouble with using the SMAT files is:
1. If you don’t have SMAT turned on – forget it.
2. You have SMAT turned on but don’t archive or regularily cycle (you either don’t have sufficient number of days to find the peak day or the data you have is inaccurate).
3. You cycle and archive. Now you need to gather all of the files (.idx) together and do the work. Depending on the number of inbound threads and the frequency of cycling/archiving this could be a lot of files.
I think you are doing yourself a dis-serviceif you only look at the inbound.
For example if you have a single inbound message routed to 5 destinations, assuming no cross site activity, then the engine is really handling 5 or 6 messages. That load is different than if you have one in and one out (then there is only one message).
What about the acknowledgments? Although the handling may b minimal there is still work to be done.
If you decide to only look at the inbound and take the one to one approach – add a fudge factor or you will end up sucking air in the near future.
Also what about future growth?
Do you know what additinal integrations will be required during the proposed life cycle of this machine?