effects of replication on web service performance in websphere

I N T E R N A T I O N A LC O M P U T E R S C I E N C EI N S T I T U T E

1947 Center Street, Suite 600Berkeley, 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 StantchevInternational Computer Science Institute

1947 Center StreetBerkeley, California 94704-1198Email: [email protected]

Abstract

This report evaluates replication possibilities forweb services within IBM WebSphere and what effectsthey have on web service performance. The work ispart of the evaluation of architectural translucency– an approach that defines architectural levels in aservice-oriented architecture and states that similarmeasures, e.g., replication, have different implicationson nonfunctional properties when applied at differentlevels in different ways. The report focuses on theserviceware / middleware level using WebSphere as areference platform. It lists applicable techniques forweb service replication and presents a case study forthe evaluation of replication effects on performance.

1. Introduction

Web Services are emerging as a dominating tech-nology for providing and combining functionality indistributed systems. A service-oriented architecture(SOA) offers native capabilities, such as publication,discovery, selection and binding [1]. It is defined byits components (services), connections and constrains(what other service can consume them and how). Thereare two sides of a successful service offering: to pro-vide the needed functionality and to provide the neededQuality of Service (QoS). QoS parameters are part ofthe nonfunctional properties (NFPs) of a service thatcan be design-time related or run-time related. Design-time related NFPs such as language of service andcompliance are typically set during design time and donot change during runtime. Run-time related NFPs areperformance oriented, e.g., response time, throughput,availability. They can change during runtime – whentimes of extensive usage by many users are followedby times of rare usage, or when failures occur. Anapproach to dynamically adapt service performanceto these changes can ensure continuous meeting of

service levels. This approach should employ servicereconfiguration at runtime, as changes in source codeof a service are not a feasible option. Our approach toidentify possible reconfigurations in a SOA and eval-uate their implication is called architectural translu-cency [2]. In this report we evaluate different replica-tion configurations in WebSphere which correspond tothe operating system (OS) level and the middlewarelevel of the approach. We focus on techniques tointroduce replication alternatives and the effects theyhave on web service performance.

The rest of this work is structured as follows: inSections 2 and 3 we formulate the problem and outlineour approach in the context of related work. Section 4describes the usage of workloads for performanceevaluation, Section 5 presents replication alternativeswithin WebSphere and how we can reconfigure them.In Section 6 we present our case study and evaluatethe test data. Useful insights and our future activitiesare outlined in Section 7.

2. Replication and Performance

We define performance as the system output ω(δ)that represents the number of successfully served re-quests from a total of input requests ι(δ) during aperiod of time δ.

ω(δ) = f(ι(δ)) (1)

The performance of a serial composed service chainthat includes Service N would be:

ωServiceChain ≤ fServiceN (ι1) (2)

The performance of corresponding replicated com-posed service chain would be:

ωServiceChain ≤ 2 ∗ fServiceN (ι1) (3)

This definition corresponds to throughput as NFP.The average response time can be derived from Equa-tion 1 as follows:

RTavg =1ω

(4)

Obviously, replication has advantageous implica-tions on service performance when no replica synchro-nization is required. This applies to throughput andresponse time as NFPs in a SOA.

2.1. Architectural Translucency

The complexity involved in providing a single webservice is often underestimated. A look at hardwareplatforms, even commodity hardware, reveals complexmicroprocessors and processing architecture. StandardOSs are far away from microkernel designs and containa large number of OS extensions. These are calledmodules in a Linux system [3] and drivers in aWindows system [4]. Beside typical device drivers,extensions include network protocol implementations,file systems and virus detectors. Extensions are morethan 70% of the Linux source code [5], while WindowsXP includes over 35,000 drivers with over 120,000versions [6]. Typical component environments suchas .NET and J2EE often serve as the middleware forproviding web services [7]. A look at the applicationprogramming interfaces of these environments revealstheir complexity.

There are two general aspects of translucency withina SOA. One is the layered approach within a sys-tem described in [2], [8]. Here the question is atwhich layer a certain measure should be introduced,so that the highest availability and performance atcertain loads can be assured. The second aspect is toobserve multiple systems and to decide which systemis best suited to host a certain measure. The objectivehere is the same – assure the highest availabilityand performance of the application that is composedfrom services. The first aspect is an extension ofarchitectural approaches that aim to improve NFPs inone location, e.g., reliability at the OS level [9], [6],scalability by clustering of web servers [10] or emailservers [11], as well as introducing software RAIDapproaches [12]. Architectural translucency within asystem defines layers that encompass these approachesand compares replication configurations at the differentlayers.

2.2. Replication of Web Services in WebSphere

This work focuses on replication at the OS andserviceware level. Our hypothesis is that there are

different ways to replicate at these levels and that thereare differences in web service performance when weapply them. Our objective is to define these differentways of replication when dealing with WebSphereas application platform and find reconfiguration tech-niques for them. Furthermore, we need a test setupwhere we can test and evaluate the effects of thesesettings.

3. Related Work

Much work has been done in the area of QoS-awareweb service discovery [13], QoS-aware platforms andmiddleware [14], and context-aware services [15].

There are various efforts to address NFPs in dis-tributed computing environments that look at differentsystem levels. Under the term performability, originallyintroduced in 1997 [16], there are works in the area ofresource control [17] and addressing fault-tolerance atsystem level and application level [18].

A workload observation of IBM WebSphere is pre-sented in [19], implementation and configuration rec-ommendations for high availability and scalability arepresented in various works, e.g., [20], [21], informationabout dynamic caching in [22], a description of theapplication server architecture and the programmingmodel in [23].

4. Workloads

Evaluation of NFP service levels, especially perfor-mance metrics is based on the usage of workloadswith two general applications: evaluation of existingsystems and evaluation of design alternatives for newsystems [24]. The evaluation of design alternativesfor still non-existing systems requires the definition ofworkload models with different levels of abstraction,which is also one possible way to classify work-loads [25]. Examples for abstract workloads are math-ematical models (e.g., probabilistic network routing)or stochastically generated workloads. Two factors areimportant for the quality and applicability of workloadmodels: how well a model matches the observed effectof real workloads; and whether it can predict sucheffects [24]. The first factor requires that the workloadmodel affects the system in the same way as the realworkload will, which does not necessarily precludethat it reproduces all aspects of the real workload. Thesecond aspect means, that an abstract workload wouldnot only explain known observations, but in fact predicteffects not yet observed [24].

Other types of workloads can be live workloadsand collections of synthetic and real jobs. The large

majority of workloads used today in performance eval-uation research are real [24], either sample jobs [26]or traces [27], which can also be used in the contextof data dependencies recovery [28]. When models areused, they are almost always derived from observationsof real systems [24].

Workload validity describes whether a workloadis suited to correctly evaluate system behavior withrespect to the specific response variables. If setting Aperforms X% better that setting B under a valid work-load W, that would mean that a similar performancedifference will be observed in real settings.

This report focuses on evaluation of web services inreal settings. Therefore, an adequate real workload isneeded. A look at performance evaluation techniquesin web server environments [29], [30] reveals severalimportant insights:

1) Typical web workloads show highly variabledemands, resulting in variability in CPU loadsand number of open connections [31].

2) Web reference streams exhibit high variability(e.g., request inter arrivals [32], [33] and filesizes [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 forweb services, (ii) the focus on file sizes and I/Oprocessing at the web server is not of specificconcert for web services, and (iii) typical webserver workloads are unaware of the implicationsof middleware frameworks such as J2EE and.NET on web service performance.

Therefore, this work uses WS-Test 1.1 [36] with therecommended workloads as a generic benchmark forthe performance evaluation of web services.

5. Replication of Web Services in Web-Sphere

In service-oriented computing (SOC) a node re-ceives a stream of requests (node input ι(δ)), processesthem and sends back a stream of results (node outputω(δ)). From an operating system point of view thereexist two general strategies for request processing –threaded request processing and event-driven requestprocessing. Our objective is to optimize performance(improve node output ω(δ)) by reconfiguring settingsin WebSphere. The technique is functional replicationand the question is what possibilities does WebSphereoffer to control functional replication.

5.1. Threaded Request Processing

When implementing pure threaded request process-ing an OS creates a thread for each client request. Thewhole request and maybe its subsequent ones fromthe same client are processed in the context of thisthread. This approach offers good parallelization ofrequest processing and good utilization of availableresources. Main disadvantage is the large overhead ofthe thread lifecycle (creation, management, deletion).Modern OSs address this by employing thread pools– a specific number of request processing threadsare created in advance and left idle. The OS canthen dynamically assign them to incoming threads.Implementations differ in handling new requests if allworker threads are busy.

5.2. Event-driven Request Processing

With pure event-driven processing the OS processesall requests within a single worker thread. Arrivingrequests are stored in a queue which is used as inputfor the thread that fetches and processes the requestsone at a time. The per request overhead here isminimal (managing the request queue) and a queuingpolicy with request priorities can be introduced. Theapproach is nevertheless contradictory with a key goalof architectural translucency – to ensure high resourceutilization. The low degree of parallelism can result inlonger idle times.

5.3. Thread and Process Replication

At operating system level there are two general waysfor behavior replication – replication of threads andreplication of processes. While in the former a nodecreates a new thread to process a client request, in thelatter it creates a new process to handle an incomingrequest. Generally, it can be assumed that a per-threadreplication should be more favorable to performanceas per-process replication, as the overhead of processmanagement is larger from an OS point of view. Inorder to research this hypothesis this work focusedfirst on finding mechanisms to control this type ofreplication at the OS level of typical platforms for webservices.

5.4. Threads and Processes in IBM WebSphere

After a successful installation of IBMWebSphere the administration interface ofthe application server is accessible vianetwork (URL: https://localhost:9043

/ibm/console/logon.jsp, see Figure 1). Onthe left a list with the different administration groupsis available.

Figure 1. IBM WebSphere Administration Inter-face

5.4.1. Configuring Enterprise Archives in IBMWebSphere. Enterprise Archives (EARs) can be con-figured using the Applications menu (see Figure 2).

Figure 2. Configuring Enterprise Archives in IBMWebSphere

When installing specific web services (e.g., theWSTest 1.1 Benchmark [36] used for the case studiesin this work) to evaluate different replication settingsthere are some specifics that we have to account for.

When dealing with replication at the servicewarelevel (see next Section 5.5) the question is how todistribute instances in different Web Containers. Anoverview of Web Containers and strategies to configurespecific applications are given in [37]. Possible waysto distribute instances in different Web Containers areto use another main context (German: Stammkontext)or to change the main context manually within theEARs. Manual change is done by editing the file

application.xml in the META-INF directory.The pairs of names have to be edited so that there is nomatch within a pair, especially concerning the elementsdisplay-name, web-uri and context-root.Names of web archive (WAR) files also have to beadapted accordingly before packing the EAR with jar(see also [38]).

5.4.2. Configuring the Application Server. Config-uration settings for the application server in IBMWebSphere are done using the application server menu(see Figure 3).

Figure 3. Configuring Application Server in IBMWebSphere

The menu item Thread-Pools contains an overviewof the existing thread pools within the applicationserver (see Figure 4). By selecting Web Containerthe specific parameters of the thread pool can beconfigured (see Figure 5).

Figure 4. Overview of Thread Pools in IBM Web-Sphere

5.4.3. Configuring Processes and the Java VirtualMachine. The settings for processes and the Java

Figure 5. Configuring Thread Pools for a WebContainer

Virtual Machine (JVM) are accessible in the groupJava and Process Management, menu Process Defini-tion (see Figure 6). Relevant settings (initial size andmax. size) of the JVM heap size can be configured asdescribed further in this section.

Figure 6. Configuring Processes and the JavaVirtual Machine in IBM WebSphere

5.5. Replication at the Serviceware Level

At the serviceware level a system typically replicatesbehavior in the form of replicated services. In order toidentify different types of such replication we have tolook at the way the serviceware level handles services.

5.5.1. Hosting and Managing Services. Nodes inSOC typically use an application server to manage andhost services. Such an application server correspondsto the middleware /nserviceware level of architecturaltranslucency. It simplifies generic service managementtasks, e.g., service configuration, deployment, con-nection (with other services) or monitoring. These

tasks are often done using service containers. Serviceswithin a service container can be composed using twogeneral structures: direct composition (see Figure 7)and composition via a service bus (see Figure 8).

Figure 7. Direct Composition within a ServiceContainer

Figure 8. Service Bus Composition within a Ser-vice Container

Direct composition of services within a servicecontainer resembles the component programmingparadigm: services are explicitly connected with otherrequired services at deployment time. As preconditionthe required services must be available. The servicebus concept connects all deployed services to a centralbus which is responsible for request routing to the ser-vices. This allows more complex interactions such asthe publish/subscribe approach known from enterpriseapplication integration (EAI) [39].

5.5.2. Replicating Services at the ServicewareLevel. When looking at replication at the servicewarelevel there are two basic alternatives – replicationof service containers (see Figure 9) or replicationof services within service containers (see Figure 10).Thereby a service container can contain only oneservice (e.g., Service 1), or more than one service.

From an object-oriented point of view both thesealternatives can be implemented by instantiating newservice or container objects. An objective of architec-tural translucency is to allow for such reconfigurationswithout reprogramming. Most of the configuration

Figure 9. Replication of a Service Container

Figure 10. Replication of Services within a ServiceContainer

possibilities already described for IBM WebSpherein this section also apply. An example of how thesesettings can be reconfigured without changes in pro-gram source code is shown in the following casestudy. There we use a standard web service benchmark(WS Test 1.1 [36]) and a standard serviceware (IBMWebSphere [40]).

6. Case Study

This case study focuses on effects on web serviceperformance of different replication settings withinWebSphere. Target variable is the system output ω(δ),that represents the number of successfully server re-quests of a total of input ι(δ) requests.

6.1. Test Configuration

The software and hardware configurations are shownin Table 1 and Table 2. Each of the two client machinesis using a dedicated Mercury LoadRunner instance.These instances send requests to the web services ofthe WS Test 1.1 suite [36] that is deployed on theserver.

Type ServerCPU Intel Pentium 4 3GHzRAM 1.536 MBHDD 160 GB, 5400rpmLAN 1000 MBitOS Gentoo Linux (Kernel 2.6.20)

Middleware IBM WebSphere Application Server 6.1.0.0WS Suite WS Test 1.1

Table 1. Configuration for Case Study Replicationat Serviceware Level - Server

Type ClientCPU Intel Celeron M 1,6GHzRAM 512 MBHDD 80 GB, 5400rpmLAN 1000 MBitOS Win XP

Test Driver Mercury LoadRunner

Table 2. Configuration for Case Study Replicationat Serviceware Level - Client (2x)

6.2. Test Scenario

The objective is first to evaluate whether there areother beside the already listed settings within IBMWebSphere [40] that can possibly affect performance.

After an analysis the following settings were iden-tified:

1) Size of the JVM heap2) Changes in load distribution (pauses between

requests)3) Changes in the length of the SOAP requestAfter evaluating these settings the objective is to

compare the following different replication configura-tions with multiple users:

1) One Web Container2) Replication within a Web Container vs. replica-

tion of Web Containers3) One vs. multiple Web Containers4) Replication within a Web Container vs. dedi-

cated replicationThe 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 Thread-

Pool 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,


Pool 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 re-

quests (increasing sleep times: 2, 4, 6, 8, 10 msand 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 Thread-Pool 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,


Pool 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 WebContainer vs. Replication of Web Containers.Objective here is to compare performance when oneweb service is deployed in one Web Container and

serves the requests from four users with performanceof one web service deployed in four Web Containersthat serve dedicated requests from a single user. Everyweb service is tested separately – in each test run userssend requests to one web service.

Settings:• Tested web services: EchoVoid, EchoStruct,


Pool 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 WebContainer vs. Dedicated Replication. The last testcase compares performance of 3 users sending requeststo one Web Container as compared to performance of 4dedicated Web Containers (each web service runs in adedicated Web Container). Furthermore, the influenceof reconfiguring the thread pool is also evaluated.

Settings:• Tested web services: EchoVoid, EchoStruct,


Pool 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 specifiedtest scenarios.

6.3.1. Size of the JVM Heap. Test with JVM heapsize 128 MB provided a similar picture for all web ser-vices. EchoStruct 100 is used as an example to explainthem (see Figure 11). Frequent peaks of ~140 mswere observed, while commonly a request was servedwithin 9 ms.

When setting heap size to 512 MB peaks are rarer,but are ~190 ms long (see Figure 12). There arefewer 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 Size128 MB

JVM heap size 128 MB. When compared to the overallnumber of successfully served requests these peaksare negligible as demonstrated by the histogram inFigure 13.


Figure 13. Case Study Replication in WebSphere:Histogram for EchoStruct 100 with JVM Heap Size512 MB

When further increasing JVM heap size (900 MB)the trend continues – there are fewer peaks, but theyare now ~220 ms long (see Figure 14).

An explanation of this behavior can lie in the JVM


garbage collector – the smaller the JVM heap is con-figured, the more often it is called upon. With growingJVM heap size garbage collection is conducted rarely,but each run takes longer, as there is more memory tobe freed.

When comparing performance (output ω(δ) as trans-actions per second (TPS)) for every web service, witheach setting there is not a significant implication ofchanging JVM heap size on performance (see Fig-ure 15).

Figure 15. Case Study Replication in WebSphere:Results for EchoVoid, EchoStruct 100, EchoList 20and GetOrder with JVM Heap Size 128, 512 and900 MB

Conclusion from evaluating this test case is thatpeaks are caused by the JVM garbage collector andthat changes in the JVM heap size do not influenceperformance significantly. Further test cases of thiscase study are thus conducted with the recommendedheap size of 512 MB.

6.3.2. Changes in Load Distribution. Results for thistest case are presented for each web service: EchoVoid(Figure 16), EchoStruct 100 (Figure 17), EchoList 100(Figure 18) and GetOrder (Figure 19). Again, there areno significant changes in performance with response

times remaining fairly constant. The rare peaks arerandom and comprise fewer than 0.1%, so confidenceinterval is again 100% with all test iterations.

Figure 16. Case Study Replication in Web-Sphere: Results for Changes in Load Distribution -EchoVoid

Figure 17. Case Study Replication in Web-Sphere: Results for Changes in Load Distribution -EchoStruct 100

Figure 18. Case Study Replication in WebSphere:Results for Changes in Load Distribution - EchoList100

6.3.3. Changes in the Length of the SOAP Re-quest. Changes in the length of the SOAP requestresult in a logarithmic increase of response times.This corresponds to a logarithmic decrease of output

Figure 19. Case Study Replication in Web-Sphere: Results for Changes in Load Distribution -GetOrder

ω(δ) as transactions per second (TPS) (see Figure 20).Obviously the impact of serialization / deserializationprocessing is less observable resulting in a very goodscalability of both services. There is also a reversalof processing speed of both services with growinglength – EchoList is processed faster than EchoStructwith length 1-40 while with lengths >50 EchoStruct isfaster. One reason is that list elements are transmittedas nested XML elements within the SOAP request.Contrary, array elements are child nodes of a parentnode and are therefore easier to serialize / deserializewith increasing size.

Figure 20. Case Study Replication in WebSphere:Results for Changes in the Length of the SOAPRequest

6.3.4. Multiple Users: One Web Container. Resultsof this test case show a linear correlation betweennumber of users and transactions per second (seeFigure 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 betweenrequests. Most common cause of a crash was anOutOfMemory error message.

Figure 21. Case Study Replication in WebSphere:Results for Multiple Users – One Web Container

6.3.5. Multiple Users: Replication within a WebContainer vs. Replication of Web Containers. Basedon the instable behavior observed in the previous testcase here the 5 ms sleep time between requests wasalso introduced. These sleep times would distort TPSresults, therefore the response time was measured. Acomparison of the mean processing time in ms for thetwo configurations is shown on Figure 22. There is nosignificant difference between performance, so usingmultiple Web Containers to serve requests from multi-ple users is not advantageous as compared to using oneWeb Container to serve requests from multiple users.

Figure 22. Case Study Replication in WebSphere:Results for Multiple Users – Replication within aWeb Container vs. Replication of Web Containers

6.3.6. Multiple Users: Replication within a WebContainer vs. Dedicated Replication. Results forthis test case are shown on Figure 23. Again, typeof replication or different size of thread pool havea negligible impact on the mean duration of requestprocessing.

One interesting observation within this test caseis the high variance of the specific response times.Figure 24 and Figure 25 show response times ofGetOrder (3 users, 5 threads, 4 Web Container) with a

Figure 23. Case Study Replication in WebSphere:Results for Multiple Users – Replication within aWeb Container vs. Dedicated Replication

specific setting as an example. This high variance wasobserved with all settings and all web services.

Figure 24. Case Study Replication in WebSphere:Results for Multiple Users – Replication withina Web Container vs. Dedicated Replication; Re-sponse Times of all Requests for GetOrder (3users, 5 threads, 4 Web Container)

Figure 25. Case Study Replication in WebSphere:Results for Multiple Users – Replication withina Web Container vs. Dedicated Replication; His-togram for GetOrder (3 users, 5 threads, 4 WebContainer)

6.4. Confidence Intervals

The presented results have mostly very high con-fidence intervals. Tests of JVM heap size (see Fig-ures 11, 12, 13, 14, 15) as well as tests of loaddistribution (see Figures 16, 17, 18, 19) have 100%confidence interval. Same applies to tests with differentlength of SOAP request (see Figure 20). After theintroduction of a 5 ms sleep time between requestsin multi-user mode which prevented server crashingand irresponsive states, thread replication tests alsoprovided fairly high ( ~95%) confidence intervals.One exception was the high variance of the specificresponse times in the tests replication within a WebContainer vs. dedicated replication (see Figure 24 andFigure 25 as examples). In any case, there is no clearrecommendation that can be derived from this test case.

7. Conclusion and Outlook

This work demonstrated that different replicationsettings of web services within WebSphere does nothave unambiguous effects on performance.

There is a certain trade-off associated with largerJVM heap size – delays occur more rarely but thenare of a larger duration. Another important insight wasthat overall throughput can be improved by avoidingcongestions of requests – sometimes introducing waittimes between request processing led to an overallhigher number of processed requests per second. Thusmonitoring of service performance, together with anautomated rerouting to other replicas (or blocking)of extensive requests can help assure certain servicelevels. The use of specific performance optimizationtools to tune up an application instance is also arealistic option. An overview of such techniques ispresented in [41].

Future work is focused on tests in larger settings,as well as on the creation of an environment that willoffer automated reconfiguration of replication settingsin response to changes in load and usage. Furthermore,there is a need for evaluation and definition of for-malisms, that can specify such settings for automateddeployments in datacenters.

References

[1] M. P. Papazoglou, “Service-oriented computing: con-cepts, characteristics and directions,” Web InformationSystems Engineering, 2003. WISE 2003. Proceedingsof the Fourth International Conference on, pp. 3–12,2003.

[2] V. Stantchev and M. Malek, “Architectural Translu-cency in Service-oriented Architectures,” IEE Proceed-ings - Software, vol. 153, no. 1, pp. 31–37, February2006.

[3] D. Bovet and M. Cesati, Understanding the LinuxKernel. O’Reilly Media, Inc., 2005.

[4] D. Solomon and M. Russinovich, Inside MicrosoftWindows 2000. Microsoft Press Redmond, WA, USA,2000.

[5] A. Chou, J. Yang, B. Chelf, S. Hallem, and D. En-gler, “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, “Improv-ing the reliability of commodity operating systems,”ACM Trans. Comput. Syst., vol. 23, no. 1, pp. 77–110,2005.

[7] G. Miller, “The web services debate: .net vs. j2ee,”Commun. ACM, vol. 46, no. 6, pp. 64–67, 2003.

[8] V. Stantchev and M. Malek, “Architectural Translu-cency - Vision and Approach,” in International Con-ference Automatics and Informatics 05, Sofia, Bulgaria,October 2005.

[9] M. Swift, M. Annamalai, B. Bershad, and H. Levy,“Recovering device drivers,” Proceedings of the 6thUSENIX Symposium on Operating Systems Design andImplementation, 2004.

[10] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer, andP. Gauthier, “Cluster-based scalable network services,”in SOSP ’97: Proceedings of the sixteenth ACM sym-posium on Operating systems principles. New York,NY, USA: ACM, 1997, pp. 78–91.

[11] Y. Saito, B. N. Bershad, and H. M. Levy, “Man-ageability, availability, and performance in porcupine:a highly scalable, cluster-based mail service,” ACMTrans. Comput. Syst., vol. 18, no. 3, p. 298, 2000.

[12] A. Brown and D. Patterson, “Towards AvailabilityBenchmarks: A Case Study of Software RAID Sys-tems,” Proceedings of the 2000 USENIX Annual Tech-nical Conference, 2000.

[13] Y. Makripoulias, C. Makris, Y. Panagis, E. Sakkopou-los, P. Adamopoulou, M. Pontikaki, and A. Tsakalidis,“Towards Ubiquitous Computing with Quality of WebService Support,” Upgrade, The European Journal forthe Informatics Professional, vol. VI, no. 5, pp. 29–34,2005.

[14] S. Yau, Y. Wang, D. Huang, and H. In, “Situation-aware contract specification language for middlewarefor ubiquitous computing,” Distributed Computing Sys-tems, 2003. FTDCS 2003. Proceedings. The Ninth IEEEWorkshop on Future Trends of, pp. 93–99, 28-30 May2003.

[15] Y. Tokairin, K. Yamanaka, H. Takahashi, T. Suganuma,and N. Shiratori, “An effective qos control schemefor ubiquitous services based on context informationmanagement,” 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, “Optimaldynamic 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 tosystem-level fault tolerance.” The Journal of Supercom-puting, vol. 16, no. 1-2, pp. 53–68, 2000.

[19] Y. Somin, “Workload characterization for websphereapplication server.” in Int. CMG Conference. Com-puter Measurement Group, 2004, pp. 647–656.

[20] H. Wang, H. Wang, and J. Shen, “Architectural designand implementation of highly available and scalablemedical system with ibm websphere middleware.” inCBMS. IEEE Computer Society, 2004, pp. 174–179.

[21] G. R. Anderson, “Using wlm to manage z/os and os/390websphere 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 dy-namic cache: Improving j2ee application performance.”IBM Systems Journal, vol. 43, no. 2, pp. 351–370, 2004.

[23] E. Bayeh, “The websphere application server architec-ture 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.

[26] G. Cybenko, L. Kipp, L. Pointer, and D. Kuck, “Su-percomputer performance evaluation and the perfectbenchmarks,” in ICS ’90: Proceedings of the 4th inter-national conference on Supercomputing. New York,NY, USA: ACM, 1990, pp. 254–266.

[27] S. Laha, J. Patel, and R. Iyer, “Accurate low-costmethods for performance evaluation of cache memorysystems,” Transactions on Computers, vol. 37, no. 11,pp. 1325–1336, Nov 1988.

[28] S. Tallam and R. Gupta, “Unified control flow and datadependence traces,” ACM Trans. Archit. Code Optim.,vol. 4, no. 3, p. 19, 2007.

[29] P. Barford and M. Crovella, “Generating represen-tative web workloads for network and server per-formance evaluation,” in SIGMETRICS ’98/PERFOR-MANCE ’98: Proceedings of the 1998 ACM SIGMET-RICS joint international conference on Measurementand 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 implica-tions,” 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 serverand its clients,” Technical Report 95/5, DEC WesternResearch Laboratory, Tech. Rep., Oct. 1995.

[32] S. Deng, “Empirical model of www document arrivalsat access link,” Communications, 1996. ICC 96, Confer-ence Record, Converging Technologies for Tomorrow’sApplications. 1996 IEEE International Conference on,vol. 3, pp. 1797–1802 vol.3, 23-27 Jun 1996.

[33] A. Feldmann, “Characteristics of TCP connection ar-rivals,” Self-Similar Network Traffic and PerformanceEvaluation, pp. 367–399, 2002.

[34] M. F. Arlitt and C. L. Williamson, “Web server work-load characterization: the search for invariants,” SIG-METRICS Perform. Eval. Rev., vol. 24, no. 1, pp. 126–137, 1996.

[35] A. Crovella, M.E.; Bestavros, “Self-similarity in worldwide web traffic: evidence and possible causes,” Net-working, 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, .NET1.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, “Thedeployer’s problem: configuring application servers forperformance and reliability,” Proceedings of the 25thinternational conference on Software engineering, pp.484–489, 2003.

[38] S. Bodoff, The J2EE Tutorial. Addison-Wesley Pro-fessional, 2002.

[39] D. Linthicum et al., Enterprise Application Integration.Addison-Wesley Professional, 1999.

[40] I. WebSphere, “The WebSphere Software Platform,”Product home page, 2007.

[41] H. Yu, J. E. Moreira, P. Dube, I.-H. Chung, andL. Zhang, “Performance studies of a websphere appli-cation, trade, in scale-out and scale-up environments.”in IPDPS. IEEE, 2007, pp. 1–8.

effects of replication on web service performance in websphere

Documents