I N T E R N AT I ON AL COM PUT E R SCI E NCE I N S T I T U T E
Effects of Replication on Web Service Performance in WebSphere Vladimir Stantchev
TR-08-003
March, 2008
Abstract This report evaluates replication possibilities for web services within IBM WebSphere and what effects they have on web service performance. The work is part of the evaluation of architectural translucency -- an approach that defines architectural levels in a service-oriented architecture and states that similar measures, e.g., replication, have different implications on nonfunctional properties when applied at different levels in different ways. The report focuses on the serviceware / middleware level using WebSphere as a reference platform. It lists applicable techniques for web service replication and presents a case study for the evaluation of replication effects on performance.
1947 Center Street, Suite 600 Berkeley, CA 94704- 1198 USA (510) 666-2900, (510) 666-2956 fax
w w w. i c s i . b e r k e l e y. e d u
Effects of Replication on Web Service Performance in WebSphere Vladimir Stantchev International Computer Science Institute 1947 Center Street Berkeley, California 94704-1198 Email:
[email protected] Abstract This report evaluates replication possibilities for web services within IBM WebSphere and what effects they have on web service performance. The work is part of the evaluation of architectural translucency – an approach that defines architectural levels in a service-oriented architecture and states that similar measures, e.g., replication, have different implications on nonfunctional properties when applied at different levels in different ways. The report focuses on the serviceware / middleware level using WebSphere as a reference platform. It lists applicable techniques for web service replication and presents a case study for the evaluation of replication effects on performance.
1. Introduction Web Services are emerging as a dominating technology for providing and combining functionality in distributed systems. A service-oriented architecture (SOA) offers native capabilities, such as publication, discovery, selection and binding [1]. It is defined by its components (services), connections and constrains (what other service can consume them and how). There are two sides of a successful service offering: to provide the needed functionality and to provide the needed Quality of Service (QoS). QoS parameters are part of the nonfunctional properties (NFPs) of a service that can be design-time related or run-time related. Designtime related NFPs such as language of service and compliance are typically set during design time and do not change during runtime. Run-time related NFPs are performance oriented, e.g., response time, throughput, availability. They can change during runtime – when times of extensive usage by many users are followed by times of rare usage, or when failures occur. An approach to dynamically adapt service performance to these changes can ensure continuous meeting of
service levels. This approach should employ service reconfiguration at runtime, as changes in source code of a service are not a feasible option. Our approach to identify possible reconfigurations in a SOA and evaluate their implication is called architectural translucency [2]. In this report we evaluate different replication configurations in WebSphere which correspond to the operating system (OS) level and the middleware level of the approach. We focus on techniques to introduce replication alternatives and the effects they have on web service performance. The rest of this work is structured as follows: in Sections 2 and 3 we formulate the problem and outline our approach in the context of related work. Section 4 describes the usage of workloads for performance evaluation, Section 5 presents replication alternatives within WebSphere and how we can reconfigure them. In Section 6 we present our case study and evaluate the test data. Useful insights and our future activities are outlined in Section 7.
2. Replication and Performance We define performance as the system output ω(δ) that represents the number of successfully served requests from a total of input requests ι(δ) during a period of time δ. ω(δ) = f (ι(δ))
(1)
The performance of a serial composed service chain that includes Service N would be: ω ServiceChain ≤ f ServiceN (ι1 )
(2)
The performance of corresponding replicated composed service chain would be: ω ServiceChain ≤ 2 ∗ f ServiceN (ι1 )
(3)
This definition corresponds to throughput as NFP. The average response time can be derived from Equation 1 as follows: 1 (4) ω Obviously, replication has advantageous implications on service performance when no replica synchronization is required. This applies to throughput and response time as NFPs in a SOA. RTavg =
2.1. Architectural Translucency The complexity involved in providing a single web service is often underestimated. A look at hardware platforms, even commodity hardware, reveals complex microprocessors and processing architecture. Standard OSs are far away from microkernel designs and contain a large number of OS extensions. These are called modules in a Linux system [3] and drivers in a Windows system [4]. Beside typical device drivers, extensions include network protocol implementations, file systems and virus detectors. Extensions are more than 70% of the Linux source code [5], while Windows XP includes over 35,000 drivers with over 120,000 versions [6]. Typical component environments such as .NET and J2EE often serve as the middleware for providing web services [7]. A look at the application programming interfaces of these environments reveals their complexity. There are two general aspects of translucency within a SOA. One is the layered approach within a system described in [2], [8]. Here the question is at which layer a certain measure should be introduced, so that the highest availability and performance at certain loads can be assured. The second aspect is to observe multiple systems and to decide which system is best suited to host a certain measure. The objective here is the same – assure the highest availability and performance of the application that is composed from services. The first aspect is an extension of architectural approaches that aim to improve NFPs in one location, e.g., reliability at the OS level [9], [6], scalability by clustering of web servers [10] or email servers [11], as well as introducing software RAID approaches [12]. Architectural translucency within a system defines layers that encompass these approaches and compares replication configurations at the different layers.
2.2. Replication of Web Services in WebSphere This work focuses on replication at the OS and serviceware level. Our hypothesis is that there are
different ways to replicate at these levels and that there are differences in web service performance when we apply them. Our objective is to define these different ways of replication when dealing with WebSphere as application platform and find reconfiguration techniques for them. Furthermore, we need a test setup where we can test and evaluate the effects of these settings.
3. Related Work Much work has been done in the area of QoS-aware web service discovery [13], QoS-aware platforms and middleware [14], and context-aware services [15]. There are various efforts to address NFPs in distributed computing environments that look at different system levels. Under the term performability, originally introduced in 1997 [16], there are works in the area of resource control [17] and addressing fault-tolerance at system level and application level [18]. A workload observation of IBM WebSphere is presented in [19], implementation and configuration recommendations for high availability and scalability are presented in various works, e.g., [20], [21], information about dynamic caching in [22], a description of the application server architecture and the programming model in [23].
4. Workloads Evaluation of NFP service levels, especially performance metrics is based on the usage of workloads with two general applications: evaluation of existing systems and evaluation of design alternatives for new systems [24]. The evaluation of design alternatives for still non-existing systems requires the definition of workload models with different levels of abstraction, which is also one possible way to classify workloads [25]. Examples for abstract workloads are mathematical models (e.g., probabilistic network routing) or stochastically generated workloads. Two factors are important for the quality and applicability of workload models: how well a model matches the observed effect of real workloads; and whether it can predict such effects [24]. The first factor requires that the workload model affects the system in the same way as the real workload will, which does not necessarily preclude that it reproduces all aspects of the real workload. The second aspect means, that an abstract workload would not only explain known observations, but in fact predict effects not yet observed [24]. Other types of workloads can be live workloads and collections of synthetic and real jobs. The large
majority of workloads used today in performance evaluation research are real [24], either sample jobs [26] or traces [27], which can also be used in the context of data dependencies recovery [28]. When models are used, they are almost always derived from observations of real systems [24]. Workload validity describes whether a workload is suited to correctly evaluate system behavior with respect to the specific response variables. If setting A performs X% better that setting B under a valid workload W, that would mean that a similar performance difference will be observed in real settings. This report focuses on evaluation of web services in real settings. Therefore, an adequate real workload is needed. A look at performance evaluation techniques in web server environments [29], [30] reveals several important insights: 1) Typical web workloads show highly variable demands, resulting in variability in CPU loads and number of open connections [31]. 2) Web reference streams exhibit high variability (e.g., request inter arrivals [32], [33] and file sizes [34], [35]). 3) Network traffic can be self-similar[35]. 4) Workloads used for web servers are not generally applicable to web services for three reasons: (i) end user behavior patterns are less important for web services, (ii) the focus on file sizes and I/O processing at the web server is not of specific concert for web services, and (iii) typical web server workloads are unaware of the implications of middleware frameworks such as J2EE and .NET on web service performance. Therefore, this work uses WS-Test 1.1 [36] with the recommended workloads as a generic benchmark for the performance evaluation of web services.
5. Replication of Web Services in WebSphere In service-oriented computing (SOC) a node receives a stream of requests (node input ι(δ)), processes them and sends back a stream of results (node output ω(δ)). From an operating system point of view there exist two general strategies for request processing – threaded request processing and event-driven request processing. Our objective is to optimize performance (improve node output ω(δ)) by reconfiguring settings in WebSphere. The technique is functional replication and the question is what possibilities does WebSphere offer to control functional replication.
5.1. Threaded Request Processing When implementing pure threaded request processing an OS creates a thread for each client request. The whole request and maybe its subsequent ones from the same client are processed in the context of this thread. This approach offers good parallelization of request processing and good utilization of available resources. Main disadvantage is the large overhead of the thread lifecycle (creation, management, deletion). Modern OSs address this by employing thread pools – a specific number of request processing threads are created in advance and left idle. The OS can then dynamically assign them to incoming threads. Implementations differ in handling new requests if all worker threads are busy.
5.2. Event-driven Request Processing With pure event-driven processing the OS processes all requests within a single worker thread. Arriving requests are stored in a queue which is used as input for the thread that fetches and processes the requests one at a time. The per request overhead here is minimal (managing the request queue) and a queuing policy with request priorities can be introduced. The approach is nevertheless contradictory with a key goal of architectural translucency – to ensure high resource utilization. The low degree of parallelism can result in longer idle times.
5.3. Thread and Process Replication At operating system level there are two general ways for behavior replication – replication of threads and replication of processes. While in the former a node creates a new thread to process a client request, in the latter it creates a new process to handle an incoming request. Generally, it can be assumed that a per-thread replication should be more favorable to performance as per-process replication, as the overhead of process management is larger from an OS point of view. In order to research this hypothesis this work focused first on finding mechanisms to control this type of replication at the OS level of typical platforms for web services.
5.4. Threads and Processes in IBM WebSphere After a successful installation of IBM WebSphere the administration interface of the application server is accessible via network (URL: https://localhost:9043
/ibm/console/logon.jsp, see Figure 1). On the left a list with the different administration groups is available.
application.xml in the META-INF directory. The pairs of names have to be edited so that there is no match within a pair, especially concerning the elements display-name, web-uri and context-root. Names of web archive (WAR) files also have to be adapted accordingly before packing the EAR with jar (see also [38]). 5.4.2. Configuring the Application Server. Configuration settings for the application server in IBM WebSphere are done using the application server menu (see Figure 3).
Figure 1. IBM WebSphere Administration Interface
5.4.1. Configuring Enterprise Archives in IBM WebSphere. Enterprise Archives (EARs) can be configured using the Applications menu (see Figure 2).
Figure 3. Configuring Application Server in IBM WebSphere The menu item Thread-Pools contains an overview of the existing thread pools within the application server (see Figure 4). By selecting Web Container the specific parameters of the thread pool can be configured (see Figure 5).
Figure 2. Configuring Enterprise Archives in IBM WebSphere When installing specific web services (e.g., the WSTest 1.1 Benchmark [36] used for the case studies in this work) to evaluate different replication settings there are some specifics that we have to account for. When dealing with replication at the serviceware level (see next Section 5.5) the question is how to distribute instances in different Web Containers. An overview of Web Containers and strategies to configure specific applications are given in [37]. Possible ways to distribute instances in different Web Containers are to use another main context (German: Stammkontext) or to change the main context manually within the EARs. Manual change is done by editing the file
Figure 4. Overview of Thread Pools in IBM WebSphere
5.4.3. Configuring Processes and the Java Virtual Machine. The settings for processes and the Java
tasks are often done using service containers. Services within a service container can be composed using two general structures: direct composition (see Figure 7) and composition via a service bus (see Figure 8).
Figure 5. Configuring Thread Pools for a Web Container Figure 7. Direct Composition within a Service Container Virtual Machine (JVM) are accessible in the group Java and Process Management, menu Process Definition (see Figure 6). Relevant settings (initial size and max. size) of the JVM heap size can be configured as described further in this section.
Figure 8. Service Bus Composition within a Service Container
Figure 6. Configuring Processes and the Java Virtual Machine in IBM WebSphere
5.5. Replication at the Serviceware Level At the serviceware level a system typically replicates behavior in the form of replicated services. In order to identify different types of such replication we have to look at the way the serviceware level handles services. 5.5.1. Hosting and Managing Services. Nodes in SOC typically use an application server to manage and host services. Such an application server corresponds to the middleware /nserviceware level of architectural translucency. It simplifies generic service management tasks, e.g., service configuration, deployment, connection (with other services) or monitoring. These
Direct composition of services within a service container resembles the component programming paradigm: services are explicitly connected with other required services at deployment time. As precondition the required services must be available. The service bus concept connects all deployed services to a central bus which is responsible for request routing to the services. This allows more complex interactions such as the publish/subscribe approach known from enterprise application integration (EAI) [39]. 5.5.2. Replicating Services at the Serviceware Level. When looking at replication at the serviceware level there are two basic alternatives – replication of service containers (see Figure 9) or replication of services within service containers (see Figure 10). Thereby a service container can contain only one service (e.g., Service 1), or more than one service. From an object-oriented point of view both these alternatives can be implemented by instantiating new service or container objects. An objective of architectural translucency is to allow for such reconfigurations without reprogramming. Most of the configuration
Type CPU RAM HDD LAN OS Middleware WS Suite
Server Intel Pentium 4 3GHz 1.536 MB 160 GB, 5400rpm 1000 MBit Gentoo Linux (Kernel 2.6.20) IBM WebSphere Application Server 6.1.0.0 WS Test 1.1
Table 1. Configuration for Case Study Replication at Serviceware Level - Server
Figure 9. Replication of a Service Container
Type CPU RAM HDD LAN OS Test Driver
Client Intel Celeron M 1,6GHz 512 MB 80 GB, 5400rpm 1000 MBit Win XP Mercury LoadRunner
Table 2. Configuration for Case Study Replication at Serviceware Level - Client (2x)
Figure 10. Replication of Services within a Service Container
possibilities already described for IBM WebSphere in this section also apply. An example of how these settings can be reconfigured without changes in program source code is shown in the following case study. There we use a standard web service benchmark (WS Test 1.1 [36]) and a standard serviceware (IBM WebSphere [40]).
6. Case Study This case study focuses on effects on web service performance of different replication settings within WebSphere. Target variable is the system output ω(δ), that represents the number of successfully server requests of a total of input ι(δ) requests.
6.1. Test Configuration The software and hardware configurations are shown in Table 1 and Table 2. Each of the two client machines is using a dedicated Mercury LoadRunner instance. These instances send requests to the web services of the WS Test 1.1 suite [36] that is deployed on the server.
6.2. Test Scenario The objective is first to evaluate whether there are other beside the already listed settings within IBM WebSphere [40] that can possibly affect performance. After an analysis the following settings were identified: 1) Size of the JVM heap 2) Changes in load distribution (pauses between requests) 3) Changes in the length of the SOAP request After evaluating these settings the objective is to compare the following different replication configurations with multiple users: 1) One Web Container 2) Replication within a Web Container vs. replication of Web Containers 3) One vs. multiple Web Containers 4) Replication within a Web Container vs. dedicated replication The rest of this subsection describes the specification of these test cases and their settings. 6.2.1. Size of the JVM Heap. Settings: • Tested web services: EchoVoid, EchoStruct, EchoList and GetOrder • Min. and max. size of the Web Container ThreadPool 20 • 500ms deadline for thread inactivity • One Web Container
• • • • •
One user Test duration: 3 minutes Test iterations: 20 Client side: no sleep intervals between requests Size of the JVM Heap: 128, 512, 900 MB
6.2.2. Changes in Load Distribution. Settings: • Tested web services: EchoVoid, EchoStruct, EchoList and GetOrder • Min. and max. size of the Web Container ThreadPool 20 • 500ms deadline for thread inactivity • One Web Container • One user • Test duration: 11.000 requests • Test iterations: 20 • Client side: variable sleep interval between requests (increasing sleep times: 2, 4, 6, 8, 10 ms and no sleep intervals) • Size of the JVM Heap: 512 MB 6.2.3. Changes in the Length of the SOAP Request. Settings: • Tested web services: EchoStruct, and GetOrder (variable list/array length) • Min. and max. size of the Web Container ThreadPool 20 • 500ms deadline for thread inactivity • One Web Container • One user • Test duration: 3 minutes • Test iterations: 20 • Client side: no sleep intervals between requests • Size of the JVM Heap: 512 MB 6.2.4. Multiple Users: One Web Container. Settings: • Tested web services: EchoVoid, EchoStruct, EchoList and GetOrder • Min. and max. size of the Web Container ThreadPool 20 • 500ms deadline for thread inactivity • One Web Container • 5, 10, 15, 20 users • Test duration: 3 minutes • Test iterations: 20 • Client side: no sleep intervals between requests • Size of the JVM Heap: 512 MB 6.2.5. Multiple Users: Replication within a Web Container vs. Replication of Web Containers. Objective here is to compare performance when one web service is deployed in one Web Container and
serves the requests from four users with performance of one web service deployed in four Web Containers that serve dedicated requests from a single user. Every web service is tested separately – in each test run users send requests to one web service. Settings: • Tested web services: EchoVoid, EchoStruct, EchoList and GetOrder • Min. and max. size of the Web Container ThreadPool 20 • 500ms deadline for thread inactivity • One and four Web Containers • Four users • Test duration: 5 minutes • Test iterations: 20 • Client side: 5 ms sleep intervals between requests • Size of the JVM Heap: 512 MB 6.2.6. Multiple Users: Replication within a Web Container vs. Dedicated Replication. The last test case compares performance of 3 users sending requests to one Web Container as compared to performance of 4 dedicated Web Containers (each web service runs in a dedicated Web Container). Furthermore, the influence of reconfiguring the thread pool is also evaluated. Settings: • Tested web services: EchoVoid, EchoStruct, EchoList and GetOrder • Min. and max. size of the Web Container ThreadPool 5 and 25 • 500ms deadline for thread inactivity • One and four Web Containers • Four users • Test duration: 5 minutes • Test iterations: 20 • Client side: 5 ms sleep intervals between requests • Size of the JVM Heap: 512 MB
6.3. Test Results and Recommendations Test results are presented according to the specified test scenarios. 6.3.1. Size of the JVM Heap. Test with JVM heap size 128 MB provided a similar picture for all web services. EchoStruct 100 is used as an example to explain them (see Figure 11). Frequent peaks of ~140 ms were observed, while commonly a request was served within 9 ms. When setting heap size to 512 MB peaks are rarer, but are ~190 ms long (see Figure 12). There are fewer requests that are served for longer than 9 ms, but these then take generally longer as compared to
Figure 11. Case Study Replication in WebSphere: Results for EchoStruct 100 with JVM Heap Size 128 MB
Figure 14. Case Study Replication in WebSphere: Results for EchoStruct 100 with JVM Heap Size 900 MB
JVM heap size 128 MB. When compared to the overall number of successfully served requests these peaks are negligible as demonstrated by the histogram in Figure 13.
garbage collector – the smaller the JVM heap is configured, the more often it is called upon. With growing JVM heap size garbage collection is conducted rarely, but each run takes longer, as there is more memory to be freed. When comparing performance (output ω(δ) as transactions per second (TPS)) for every web service, with each setting there is not a significant implication of changing JVM heap size on performance (see Figure 15).
Figure 12. Case Study Replication in WebSphere: Results for EchoStruct 100 with JVM Heap Size 512 MB
Figure 15. Case Study Replication in WebSphere: Results for EchoVoid, EchoStruct 100, EchoList 20 and GetOrder with JVM Heap Size 128, 512 and 900 MB
Figure 13. Case Study Replication in WebSphere: Histogram for EchoStruct 100 with JVM Heap Size 512 MB When further increasing JVM heap size (900 MB) the trend continues – there are fewer peaks, but they are now ~220 ms long (see Figure 14). An explanation of this behavior can lie in the JVM
Conclusion from evaluating this test case is that peaks are caused by the JVM garbage collector and that changes in the JVM heap size do not influence performance significantly. Further test cases of this case study are thus conducted with the recommended heap size of 512 MB. 6.3.2. Changes in Load Distribution. Results for this test case are presented for each web service: EchoVoid (Figure 16), EchoStruct 100 (Figure 17), EchoList 100 (Figure 18) and GetOrder (Figure 19). Again, there are no significant changes in performance with response
times remaining fairly constant. The rare peaks are random and comprise fewer than 0.1%, so confidence interval is again 100% with all test iterations.
Figure 19. Case Study Replication in WebSphere: Results for Changes in Load Distribution GetOrder Figure 16. Case Study Replication in WebSphere: Results for Changes in Load Distribution EchoVoid
ω(δ) as transactions per second (TPS) (see Figure 20). Obviously the impact of serialization / deserialization processing is less observable resulting in a very good scalability of both services. There is also a reversal of processing speed of both services with growing length – EchoList is processed faster than EchoStruct with length 1-40 while with lengths >50 EchoStruct is faster. One reason is that list elements are transmitted as nested XML elements within the SOAP request. Contrary, array elements are child nodes of a parent node and are therefore easier to serialize / deserialize with increasing size.
Figure 17. Case Study Replication in WebSphere: Results for Changes in Load Distribution EchoStruct 100
Figure 20. Case Study Replication in WebSphere: Results for Changes in the Length of the SOAP Request
Figure 18. Case Study Replication in WebSphere: Results for Changes in Load Distribution - EchoList 100 6.3.3. Changes in the Length of the SOAP Request. Changes in the length of the SOAP request result in a logarithmic increase of response times. This corresponds to a logarithmic decrease of output
6.3.4. Multiple Users: One Web Container. Results of this test case show a linear correlation between number of users and transactions per second (see Figure 21). As higher loads (15 and 20 simultaneous users) often led to a non-responsive server or even crashes, it was decided to introduce a 5 ms sleep time between requests. Most common cause of a crash was an OutOfMemory error message.
Figure 21. Case Study Replication in WebSphere: Results for Multiple Users – One Web Container
6.3.5. Multiple Users: Replication within a Web Container vs. Replication of Web Containers. Based on the instable behavior observed in the previous test case here the 5 ms sleep time between requests was also introduced. These sleep times would distort TPS results, therefore the response time was measured. A comparison of the mean processing time in ms for the two configurations is shown on Figure 22. There is no significant difference between performance, so using multiple Web Containers to serve requests from multiple users is not advantageous as compared to using one Web Container to serve requests from multiple users.
Figure 23. Case Study Replication in WebSphere: Results for Multiple Users – Replication within a Web Container vs. Dedicated Replication
specific setting as an example. This high variance was observed with all settings and all web services.
Figure 24. Case Study Replication in WebSphere: Results for Multiple Users – Replication within a Web Container vs. Dedicated Replication; Response Times of all Requests for GetOrder (3 users, 5 threads, 4 Web Container)
Figure 22. Case Study Replication in WebSphere: Results for Multiple Users – Replication within a Web Container vs. Replication of Web Containers
6.3.6. Multiple Users: Replication within a Web Container vs. Dedicated Replication. Results for this test case are shown on Figure 23. Again, type of replication or different size of thread pool have a negligible impact on the mean duration of request processing. One interesting observation within this test case is the high variance of the specific response times. Figure 24 and Figure 25 show response times of GetOrder (3 users, 5 threads, 4 Web Container) with a
Figure 25. Case Study Replication in WebSphere: Results for Multiple Users – Replication within a Web Container vs. Dedicated Replication; Histogram for GetOrder (3 users, 5 threads, 4 Web Container)
6.4. Confidence Intervals The presented results have mostly very high confidence intervals. Tests of JVM heap size (see Figures 11, 12, 13, 14, 15) as well as tests of load distribution (see Figures 16, 17, 18, 19) have 100% confidence interval. Same applies to tests with different length of SOAP request (see Figure 20). After the introduction of a 5 ms sleep time between requests in multi-user mode which prevented server crashing and irresponsive states, thread replication tests also provided fairly high ( ~95%) confidence intervals. One exception was the high variance of the specific response times in the tests replication within a Web Container vs. dedicated replication (see Figure 24 and Figure 25 as examples). In any case, there is no clear recommendation that can be derived from this test case.
[2] V. Stantchev and M. Malek, “Architectural Translucency in Service-oriented Architectures,” IEE Proceedings - Software, vol. 153, no. 1, pp. 31–37, February 2006. [3] D. Bovet and M. Cesati, Understanding the Linux Kernel. O’Reilly Media, Inc., 2005. [4] D. Solomon and M. Russinovich, Inside Microsoft Windows 2000. Microsoft Press Redmond, WA, USA, 2000. [5] A. Chou, J. Yang, B. Chelf, S. Hallem, and D. Engler, “An empirical study of operating systems errors,” SIGOPS Oper. Syst. Rev., vol. 35, no. 5, pp. 73–88, 2001. [6] M. M. Swift, B. N. Bershad, and H. M. Levy, “Improving the reliability of commodity operating systems,” ACM Trans. Comput. Syst., vol. 23, no. 1, pp. 77–110, 2005.
7. Conclusion and Outlook
[7] G. Miller, “The web services debate: .net vs. j2ee,” Commun. ACM, vol. 46, no. 6, pp. 64–67, 2003.
This work demonstrated that different replication settings of web services within WebSphere does not have unambiguous effects on performance. There is a certain trade-off associated with larger JVM heap size – delays occur more rarely but then are of a larger duration. Another important insight was that overall throughput can be improved by avoiding congestions of requests – sometimes introducing wait times between request processing led to an overall higher number of processed requests per second. Thus monitoring of service performance, together with an automated rerouting to other replicas (or blocking) of extensive requests can help assure certain service levels. The use of specific performance optimization tools to tune up an application instance is also a realistic option. An overview of such techniques is presented in [41]. Future work is focused on tests in larger settings, as well as on the creation of an environment that will offer automated reconfiguration of replication settings in response to changes in load and usage. Furthermore, there is a need for evaluation and definition of formalisms, that can specify such settings for automated deployments in datacenters.
[8] V. Stantchev and M. Malek, “Architectural Translucency - Vision and Approach,” in International Conference Automatics and Informatics 05, Sofia, Bulgaria, October 2005.
References [1] M. P. Papazoglou, “Service-oriented computing: concepts, characteristics and directions,” Web Information Systems Engineering, 2003. WISE 2003. Proceedings of the Fourth International Conference on, pp. 3–12, 2003.
[9] M. Swift, M. Annamalai, B. Bershad, and H. Levy, “Recovering device drivers,” Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation, 2004. [10] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer, and P. Gauthier, “Cluster-based scalable network services,” in SOSP ’97: Proceedings of the sixteenth ACM symposium on Operating systems principles. New York, NY, USA: ACM, 1997, pp. 78–91. [11] Y. Saito, B. N. Bershad, and H. M. Levy, “Manageability, availability, and performance in porcupine: a highly scalable, cluster-based mail service,” ACM Trans. Comput. Syst., vol. 18, no. 3, p. 298, 2000. [12] A. Brown and D. Patterson, “Towards Availability Benchmarks: A Case Study of Software RAID Systems,” Proceedings of the 2000 USENIX Annual Technical Conference, 2000. [13] Y. Makripoulias, C. Makris, Y. Panagis, E. Sakkopoulos, P. Adamopoulou, M. Pontikaki, and A. Tsakalidis, “Towards Ubiquitous Computing with Quality of Web Service Support,” Upgrade, The European Journal for the Informatics Professional, vol. VI, no. 5, pp. 29–34, 2005. [14] S. Yau, Y. Wang, D. Huang, and H. In, “Situationaware contract specification language for middleware for ubiquitous computing,” Distributed Computing Systems, 2003. FTDCS 2003. Proceedings. The Ninth IEEE Workshop on Future Trends of, pp. 93–99, 28-30 May 2003.
[15] Y. Tokairin, K. Yamanaka, H. Takahashi, T. Suganuma, and N. Shiratori, “An effective qos control scheme for ubiquitous services based on context information management,” cec-eee, vol. 00, pp. 619–625, 2007. [16] C.M.Krishna and Kang.G.Shin, Real-Time Systems. The McGraw-Hill Companies, Inc, New York, 1997. [17] K. G. Shin, C. M. Krishna, and Y.-H. Lee, “Optimal dynamic control of resources in a distributed system,” IEEE Trans. Softw. Eng., vol. 15, no. 10, pp. 1188– 1198, 1989. [18] J. Haines, V. Lakamraju, I. Koren, and C. M. Krishna, “Application-level fault tolerance as a complement to system-level fault tolerance.” The Journal of Supercomputing, vol. 16, no. 1-2, pp. 53–68, 2000. [19] Y. Somin, “Workload characterization for websphere application server.” in Int. CMG Conference. Computer Measurement Group, 2004, pp. 647–656. [20] H. Wang, H. Wang, and J. Shen, “Architectural design and implementation of highly available and scalable medical system with ibm websphere middleware.” in CBMS. IEEE Computer Society, 2004, pp. 174–179. [21] G. R. Anderson, “Using wlm to manage z/os and os/390 websphere performance.” in Int. CMG Conference, 2001, pp. 425–456. [22] R. Bakalova, A. Chow, C. Fricano, P. Jain, N. Kodali, D. Poirier, S. Sankaran, and D. Shupp, “Websphere dynamic cache: Improving j2ee application performance.” IBM Systems Journal, vol. 43, no. 2, pp. 351–370, 2004. [23] E. Bayeh, “The websphere application server architecture and programming model.” IBM Systems Journal, vol. 37, no. 3, pp. 336–348, 1998. [24] A. J. Smith, “Workloads (creation and use),” Commun. ACM, vol. 50, no. 11, pp. 45–50, 2007. [25] D. Ferrari, Computer systems performance evaluation. Prentice-Hall Englewood Cliffs, NJ, 1978.
[29] P. Barford and M. Crovella, “Generating representative web workloads for network and server performance evaluation,” in SIGMETRICS ’98/PERFORMANCE ’98: Proceedings of the 1998 ACM SIGMETRICS joint international conference on Measurement and modeling of computer systems. New York, NY, USA: ACM, 1998, pp. 151–160. [30] C. Arlitt, M.F.; Williamson, “Internet web servers: workload characterization and performance implications,” Networking, IEEE/ACM Transactions on, vol. 5, no. 5, pp. 631–645, Oct 1997. [31] J. Mogul et al., “Network behavior of a busy web server and its clients,” Technical Report 95/5, DEC Western Research Laboratory, Tech. Rep., Oct. 1995. [32] S. Deng, “Empirical model of www document arrivals at access link,” Communications, 1996. ICC 96, Conference Record, Converging Technologies for Tomorrow’s Applications. 1996 IEEE International Conference on, vol. 3, pp. 1797–1802 vol.3, 23-27 Jun 1996. [33] A. Feldmann, “Characteristics of TCP connection arrivals,” Self-Similar Network Traffic and Performance Evaluation, pp. 367–399, 2002. [34] M. F. Arlitt and C. L. Williamson, “Web server workload characterization: the search for invariants,” SIGMETRICS Perform. Eval. Rev., vol. 24, no. 1, pp. 126– 137, 1996. [35] A. Crovella, M.E.; Bestavros, “Self-similarity in world wide web traffic: evidence and possible causes,” Networking, IEEE/ACM Transactions on, vol. 5, no. 6, pp. 835–846, Dec 1997. [36] Microsoft, Comparing Web Service Performance: WS Test 1.1 Benchmark Results for.NET 2.0, .NET 1.1, Sun One/ JWSDP 1.5 and IBM WebSphere 6.0. http://www.theserverside.net/tt/articles/content/NET2Benchmarks, 2006. [37] M. Raghavachari, D. Reimer, and R. Johnson, “The deployer’s problem: configuring application servers for performance and reliability,” Proceedings of the 25th international conference on Software engineering, pp. 484–489, 2003.
[26] G. Cybenko, L. Kipp, L. Pointer, and D. Kuck, “Supercomputer performance evaluation and the perfect benchmarks,” in ICS ’90: Proceedings of the 4th international conference on Supercomputing. New York, NY, USA: ACM, 1990, pp. 254–266.
[38] S. Bodoff, The J2EE Tutorial. fessional, 2002.
[27] S. Laha, J. Patel, and R. Iyer, “Accurate low-cost methods for performance evaluation of cache memory systems,” Transactions on Computers, vol. 37, no. 11, pp. 1325–1336, Nov 1988.
[40] I. WebSphere, “The WebSphere Software Platform,” Product home page, 2007.
[28] S. Tallam and R. Gupta, “Unified control flow and data dependence traces,” ACM Trans. Archit. Code Optim., vol. 4, no. 3, p. 19, 2007.
Addison-Wesley Pro-
[39] D. Linthicum et al., Enterprise Application Integration. Addison-Wesley Professional, 1999.
[41] H. Yu, J. E. Moreira, P. Dube, I.-H. Chung, and L. Zhang, “Performance studies of a websphere application, trade, in scale-out and scale-up environments.” in IPDPS. IEEE, 2007, pp. 1–8.
