Performance Implications of Design Pattern Usage in Distributed Applications Case Studies in J2EE and .NET.

1. Performance Implications of Design Pattern Usage inDistributed Applications CaseStudies in J2EE and .NET. Jakub Rudzki Tarja Systa International Symposium on Software Testing and Analysis pp. 1 - 11 2006 Poster by Tim Crook

2. Summary • A case study was conducted to determine the influence on performance shown by three different design patterns in distributed systems • Different situations call for different design decisions with regard to pattern selection for strictly performance considerations • Determining specific pattern usage requires balanced decisions which consider object complexity, frequency of remote calls, and protocols employed.

3. Background • In this study, three patterns were considered for comparison: Façade, Command, and Combined Command • Performance results were the focus of these comparisons • Multiple versions of a test web application were created – each functionally identical, while employing a different one of these patterns as the interface for the distributed portion of the application

4. Background • Additionally these versions were created under two different platforms: J2EE and .NET • Here is the example of design pattern usage provided in the report by Rudzki and Systa:

5. Results • Four factors were measured – response time, throughput, number of requests exceeding ten seconds (threshold), and the number of successful results. • These experiments were also conducted for both J2EE and .NET in locally deployed environments – in each case there was no indication that these variations on design resulted in significant performance changes. • When comparing these design implementations in a distributed environment, there were significant differences discovered.

6. Results • The slower performance in some circumstances was attributed to the complexity of the objects involved. • The Combined Command pattern is the most complex structure • Command is less complex, though more complex than Façade • Of these three designs Façade is the simplest object structure • The overall results showed that with this increase in complexity, came worse performance results • On the other hand, the Combined Command provided improved performance when an increase in remote calls is necessary.

7. Results • One final discovery regarded the varied results encountered for these experiments when using different protocol. In particular HTTP was a poor performer with regard to creating calls. This lends to the conclusion that Combined Command would be most suitable for use with HTTP when multiple calls are required.

8. Critique • Writing is generally very clear, and easy to follow • Results make sense according to case study conducted • Content is useful and applicable to common situations • Too much time is spent discussing the .NET environment deployed locally considering insignificant impact to results. Also, little comparison was discussed between the parallel trials in the locally deployed J2EE environment. • Generalization when data contradicts expectations. • Small data sets collected – two trials for each test point. More trials may make generalizations hold more weight.

9. Questions • What are the three patterns considered for distributed environment interfaces in this paper? • Of the above patterns, which is ideal when multiple calls are necessary? • Which of these patterns provides the best results when object complexity impacts performance?