Tips November 2009
http://www.hpts.ws/session9/shoup.pdf
eBay?s Challenges and Lessons (Page last updated October 2009, Added 2009-11-30, Author Randy Shoup, Publisher eBay). Tips:
* Partition everything so that you can scale it as necessary.
* Use asynchrony everywhere, connected through queues.
* Use recovery and reconciliation rather than synchronous transactions.
* Automate everything - components should automatically adjust and the system should learn and improve itself.
* Monitor everything, providing service failover for parts that fail.
* Avoid distributed transactions.
* Design for extensibility, deploy changes incrementally.
* Minimize and control dependencies, use abstract interfaces and virtualization, components should have an SLA.
* Save all (monitoring) data - this provides optimization opportunities, predictions, recommendations.
* Maximize the utilization of every resource.
http://java.dzone.com/news/performance-considerations
Performance Considerations in Distributed Applications (Page last updated September 2009, Added 2009-11-30, Author Alois Reitbauer, Publisher JavaLobby). Tips:
* Many distributed application performance issues stem inefficient serialization of objects (to send across the wire).
* Connection pooling can be an important performance improvement for many types of distributed communications (not just database communications).
* Asynchronous communication is more difficult to design and implement, but is usually more efficient for distributed communications.
* Making too many service calls from the client is a frequent source of performance problems.
* Using a more efficient communication protocol can make a huge difference to overall performance (Wrong Protocol Anti-pattern) - the overhead of SOAP compared to RMI-JRMP is significant. An inefficient protocol can cause a performance degradation by a factor of ten and significantly higher CPU and memory consumption.
* When building distributed applications, make as few remote calls as possible (Chatty Application Anti-pattern).
* Keep message size as small as possible, for example the overhead of serialisation is proportional to the size of the transferred objects (Big Messages Anti-pattern).
* With a high number of deployment units, the interaction of services become more and more difficult to understand. This can lead to a situation where two heavily-interacting services are deployed on different hardware resulting in a high number of remote calls. You need to analyze the frequency of interactions as well as data volume to structure deployment accordingly and avoid inefficent deployment configurations (Distributed Deployment Anti-pattern).