Multi-tier architecture performance analysis. Papers covered

Transcription

1 Multi-tier architecture performance analysis Papers covered Emmanuel Cecchet, Julie Marguerie, Willy Zwaenepoel: Performance and Scalability of EJB Applications. OOPSLA 02 Yan Liu, Alan Fekete, Ian Gorton: Predicting the performance of middleware-based applications at the design level. Proceedings of the Fourth International Workshop on Software and Performance (WOSP) 2004:

2 Content Multi-architecture review J2EE J2EE performance analysis: design pattern container design communication layer Performance Evaluation as a mixture of analytical and empirical analysis Multi-tier architecture 2

3 J2EE architecture Appl. Client Web container Browser Java RMI/IIOP Servlets Java JNDI Servlets JTA/JTS JDBC JMS JSP JSP Pages Pages JavaMail JAF JAAS JAX* EJB Browser RMI/IIOP Enterprise Enterprise JNDI JavaBeans JavaBeans JTA/JTS JDBC JMS JavaMail JAF JAAS JAX* J2EE Application Server database and other resources J2EE application server Web container Runtime environment for java Servlet and JSP application Servlet and JSP are used to implement presentation logic. EJB container Runtime environment for EJBs Beans are used to implement business logic or present business data. Each bean access is done through container-generated classes EJB container provides services to EJBs, Each request to an EJB (from external or internal) is intercepted by the container Can do additional steps at these interception points) Services JMS, JTA, JINI, JDBC, etc. 3

4 Stateless Session Bean A stateless session bean must not keep data between client accesses used typically within a service layer: classes and methods that are used often for many different things the container keeps a pool of stateless session beans whenever a client makes a call choose an idle bean bean executes request bean is put back to the pool life time of bean determined by container container creates a bean when there are not enough in the pool container removes a bean when there are too many in the pool preprogrammed, application programmer usually need not do anything for lifecycle management Stateful Session Bean Life time: typically a user session; when user connects to system: create a new session bean when user disconnects: destroy session bean one independent bean for each user; can remember conversational state across several invocations application variables shopping cart note difference between conversational state vs. transactional state no sharing of state between different beans 4

5 Entity Bean Contains your business data in form of objects Usually: one class: one relation one entity bean instance within the class: one tuple each bean within a class must have a unique identifier = primary key Maintaining persistence: each bean has four persistence methods: create (ejbcreate): creates a new bean = new entity = new tuple read (ejbload): read an entity from persistent storage update (ejbstore): write the state to persistent storage delete (ejbremove): delete an entity/tuple from persistent storage Life cycle of entity bean 5

6 Design pattern Servlet only Presentation logic and business logic mixed Design pattern session beans Separation of business logic from presentation logic 6

7 Design pattern Entity beans Data access separation with CMP/BMP Design pattern Session + entity beans (EJB1.1/2.0) Often used design pattern Standard RMI between session façade and entity bean Local RMI between session façade and enitity bean 7

8 EJB container design Pre-compiled approach (JOnAS) the container generates custom implementation of the home and component interfaces at deployment time. Need a specific compiler (GenIC for JOnAS). Direct call of the bean instance Dynamic approach (JBoss) the container uses dynamic proxy technology to generate the home and component interfaces at run time. Generates the classes at run time. Reflection is used to locate the bean or map method signature. Communication layer 8

9 Benchmark RUBis: An auction application similar to ebay. 26 interactions browsing mix made up of only read-only interactions bidding mix 15% read-write interactions Database data (1.4 G) Implementation: From 25 classes (servlets-only) to 107 classes (façade) From 4590 lines of code to lines of code Setup Clients X number of concurrent clients Each client Connects Loops for session time (negative exponential distribution) Submits a request (chosen from the possible requests with a certain probability) Waits for a certain think time (negative exponential distribution) Throughput determined by number of clients Software Apache webserver, Tomcat servlet, JBoss and Jonas, MySQL One machine for each component 9

10 Max. achiev. throughput Session bean implementation 10

11 Entity beans with CMP Entity bean with BMP 11

12 Session bean plus entity bean EJB 2.0 local interfaces 12

13 Overall results Overall results Design pattern: The most important performance factor. Servlet only, session beans, EJB 2.0, session + entity beans, entity beans (CMP and BMP) Container design In general, pre-compile approach performs better than dynamic proxy based. Entity bean pattern is impacted the most. Communication layer Optimized call and local interface perform better 13

14 Empirical vs. Analytcal Previous Paper is an empirical evaluation on a benchmark Very expensive How representative is the benchmark Many analytical approaches E.g., queueing model etc. How realistic do they model the real world Performance Prediction at the Design Level Architecture Modeling: build a model of the architecture Calibrating: modulate and parameterize according to a given infrastructure (e.g., J2EE, CORBA) Application Characterizing: take the application and analyze how often each of the above models is executed; Derive an analytical model from there Micro-Benchmarking Determine the values of relevant parameters through micro-benchmakring 14

15 General Performance Model Calibration for J2EE What happens from request submission to return of result Request dispatching (constant) Server initialization (constant): Ti Pre-method processing (constant within container) Method processing (MP): fc + fd Post-method processing, e.g., commit transaction (constant within container) 15

16 EntityBean access: findbyprimarykey h: cache hit ratio T1: time in container if cache hit T2: time in container if cache miss Tf: time to find tuple in database Tl: time to load tuple Ts: time to write tuple p: probability that a bean state was dirty when bean was replaced Time at container: fc = ht1 + (1-h)T2 Time at database fd = Tf + Tl + (1-p) Ts Similar, but more complex analysis for findbynonprimarykey Entire Model Assume tuples are never inserted/deleted Ps: probability a method of session bean s is accessed Ts: average service time for method of session bean s p(e,o): probability of method o of entity bean e is accessed Container time: C = Ti + ps + Ts + p(e,o)fc s e o Database time: D = p(e,o)fd e o 16

17 Characterizing Stock-Online Session façade design pattern One session bean class, 4 entity beans classes Container managed persistence One session bean: Ti + ps = Ti + pre-processing + post-processing = T0 s 3 entity beans: findbyprimarykey, one entity bean: findbynonprimarykey Have to determine T0, T1, T2, Tf, Tl, Ts, h Benchmarking Run simple application with one session bean and one method, and two entity beans, each with one method (PK, Non-PK), different update rates p Measure: Hit ratio, C, D for p = 0.5, 0.9 Estimation of parameters T1, T2, Tf, Tl, Ts from there 17

18 Result Conclusion Evaluating given architecture (e.g., J2EE) very complex, time-consuming Depends on Application System (Jboss, Jonas) Chosen design patterns. Evaluating performance of an application very complex, time-consuming Use mix of parameterized analytical model Determine values of parameters by microbenchmarking 18