The document PI Best Practices: Sizing & Performance Tuning located at SDNhave just been released this October.
Since I have not been able to work with sizing of servers, I’m unable to make any comments about that part.
On the other hand i have worked a lot with performance tuning of interfaces. The guide mentions all the areas where the PI can be tuned to make processing faster, and gives easy access to more information to be used when applied.
There is though one area the guide does not mention. It is that a lot of performance can be gained in the development process. The reason for this is that the developers can make the solution more optimized for running high volumes. In the development phase of the PI projects is it possible to design toward performance, instead of readability.
When facing batch integration with high volume I would considerer the following two issues.
Bundling of messages
The message packing works when it is not possible to make modifications in the interface. If it is possible to change the interface to accept more lines pr document, then it is possible to increase the performance much more then by using message packing. This can be drived from the benchmark data on page 13-14.
| Message Size | 11 KB | 245 KB | 2.37 MB |
| Number of lines | 2 | 100 | 1000 |
| Messages pr hour | 300.000 | 155.000 | 32.000 |
| Lines pr hour | 600.000 | 1.550.000 | 32.000.000 |
When using message packaging it will increase the throughput with a factor 2.6 for the 11 KB message and less for the higher messages sizes. This can be compared with the factor of 53 when going from 2 lines file to the 1000 lines file. It therefore makes sense to change the message size in the development cycle instead of in the performance tuning.
Shorter XMLThe XML representation of the data can make the documents explode in size. If there is used tag names with a lot of meaning, the XML size will explode i.e. PaymentCurrencyPartialPaymentAmount is 35 characters long. PaymentCurrencyPartialPaymentAmount is used in an enterprice service, but it could also be used in a batch scenario. If this was reduced to a five character log field would it save (35-5)*2 = 60 characters. If the field length of amount is 10 characters is the total length of the field reduced from 60 + 10 + 5(xml characters) = 75 to 10 + 10 + 5 = 25 or one third. If we reduce the XML to in the area of 1/3 then the processing time must also increase. We might not be able to get more XML Gb/h, but we will get data Gb/h. A simpler XML structure will remove some of the loosely coupling of systems and make it more difficult for other to change and debug the scenario. It is a decision which needs to be agreed on with the project management, before the solution is implemented. 
