Apache Tomcat 5.x : Determining Server side response times June 17, 2009
Posted by Aditya Thatte in Performance Modeling, Web services.Tags: Tomcat
add a comment
This article explains the method of finding the server side response times for Apache Tomcat 5.x. The idea is to modify the server.xml configuration file located in the “conf” folder. Adding the required parameters to the server.xml file forces Tomcat to spit out data in the log files. The values are not debatable since we query the Tomcat server logs.
There is a list of parameters that can be queried, however this article only considers response time at the server side. We will be able to determine which servlet acts as a bottleneck at run-time by analyzing the server side response times.
The AccessLogValve component in Catalina creates the server logs. This creates a log file containing timestamps, performance metrics and other related information. The configuration can be changed according to the users requirements. Lets take a look at a part of the server.xml file.
An important aspect here is to know that the AccessLogValve node in the xml file is “commented” by default. It needs to be “un-commented” so that the log file is created in the logs folder.
Here is a snapshot of a part of the server.xml showing the AccessLogValve node. The default configuration shows pattern= “common”. The common pattern corresponds to “%h %l %u %t “%r” %s %b”, where
%h – Remote host name (or IP address if resolveHosts is false)
%l – Remote logical username from identd (always returns ‘-‘)
%u – Remote user that was authenticated (if any), else ‘-‘
%t – Date and time, in Common Log Format
%r – First line of the request (method and request URI)
%s – HTTP status code of the response
%b – Bytes sent, excluding HTTP headers, or ‘-‘ if zero
We shall also consider the response times at the server side, which is represented by ” %D “. We need to modify the server.xml accordingly.
It is interesting to note that some request show a value of ” 0 ” . This may be because of the fact that the response time for that particular request is in the order of micro seconds. This can help developers understand potential bottlenecks in the system.
References :
PerfCenter Tutorial : Predicting Response Times of a simple HelloWorld Web Service for increasing loads April 30, 2009
Posted by Aditya Thatte in Performance Modeling, Queuing Theory, Web services.Tags: Performance Modeling, Web services
add a comment
Using PerfCenter to predict response times of a simple HelloWorld web service.
This tutorial guides you through a series of simple steps, from Installation to hands on Performance modeling.
1. Installing PerfCenter
– Goto http://www.cse.iitb.ac.in/perfnet/softperf/cape/home/wosp2008page and download the zipped version of PerfCenter
– Unzip the folder to a location on your linux drive. Typically the current version of PerfCenter works on a linux box.
– Execute “ant compile” by navigating to the PerfCenter folder path. This will compile source files
$>cd PerfCenter
$PerfCenter>ant compile
– Execute ./Perfcenter input/expt1a, will execute the input file “expt1a” which is configured to a test scenario.
$PerfCenter>./PerfCenter input/expt1a
2. PerfCenter is a command line tool which enables Predictive Modeling and analysis of Distributed Systems and Application Hosting Centers. Performance of systems can be predicted by modeling different scenarios via input configuration files. PerfCenter input files follow a typical syntax of their own. Please refer the user manual for more details “http://www.cse.iitb.ac.in/perfnet/softperf/cape/home/wosp2008page“.
3. To predict the response times of a simple HelloWorld Web Service at different loads the input configuration file for PerfCenter should look something like this input_file_1 . Essentially the input file requires mandatory parameters like
a. CPU characteristics
b. Service time
c. Web Server characteristics
d. Load ( no. of users )
Once you have all the above parameters in place, PerfCenter will be able to generate predictive response times by “analytical” and “simulation” methods.
PerfCenter is based on the Layered Queuing Network model, where in you can model LQN’s for performance prediction. The following figure describes the scenario corresponding to the input file “input_file_1.doc”.
The diagram illustrates a Layered Queuing Network with a Software layer ( web server ) and a Hardware layer ( CPU ). Modeling contention for Software Servers and Hardware can be done using the concepts of LQN. The above scenario illustrates a Web Server configured to “n” threads. The rectangle to the left of the server represents a queuing space for threads in which incoming client requests are queued up. The incoming requests can be handled by threads if available, else they have to wait in the queue for threads. This is called Contention for Software ( access to a lock, thread etc ).
The Web Server on this machine has only 1 CPU, so all threads configured in the web server will be contending for that CPU. The rectangle to the left of the CPU layer ( hardware layer ) represents a queue for CPU. Threads waiting to access a hardware resource is called Contention for Hardware.
References :
http://www.cse.iitb.ac.in/perfnet/softperf/cape/home/wosp2008page
Scaling for E-Business ( Daniel Menasce, Almeida )
TIBCO BusinessWorks : SAX Parser Exception in generating WSDL file November 10, 2008
Posted by Aditya Thatte in Web services.Tags: Web services, WSDL
add a comment
This error commonly occurs while trying to “generate a WSDL from process ” in TIBCO BusinessWorks.
On specifying the parameters for generating the WSDL and then on clicking “Generate ” the designer shows no activity, i.e. the dialog disappears without the generation of the WSDL file.
If you view logs in “Show Console ” , you might come across ” SAX Parser Exception in generating WSDL”.
It would be very difficult to pinpoint the exact reason of failure. It could be the palettes , runtime exceptions , environment specific details.
Remedy : Re-install TIBCO BusinessWorks 🙂
Service Oriented Computing : Publish , Find , Bind November 3, 2008
Posted by Aditya Thatte in SOA.Tags: Service Orientation, SOA
add a comment
SOA is not only about services but involves the interaction of the following three entities: Service requester (client), service provider (server) and the Service registry.
SOA is applicable when applications run on heterogeneous technologies, platforms involving silos of information coming from disparate sources. Such applications need to communicate to each other using standard based protocols which can be implemented using the SOA concept.
The above figure [1] shows the collaboration between the entities. It involves the operations such as publish, find and bind which act on the service artifacts: service description and service implementation.
In a simple Service oriented scenario, an Application Service Provider (ASP) hosts an application across a network. ASP is a third party entity deploying, hosting and managing the access to the application and delivering software based services to clients across a distributed environment. The service provider defines or describes the service i.e. the functionality and publishes the service to the service discoverable agency or client via which the service is exposed. The discovery agency is the registry or repository like UDDI, which uses the service description to bind to the service provider and invoke the requested service. The service requestor (client) uses a find operation to retrieve the service description from the registry.
A service is a business/technical function implemented in software, which is wrapped with a formal documented interface that is well known and known[1] where to be found not only by the agents who designed the service but also by agents who want to access the service.
The formal interface is the mechanism via which a service communicates with an application and other services. Technically speaking the interface describes a set of operations that are available to the service client for use.
Each service is treated as a loosely coupled component, essentially like a Black Box. The essence of SOA lies in the concept of simplicity and reusability of components, thereby enabling a “just perform one function” scenario solely dedicating a service to perform its function.
SOA’s use and reuse of components makes it easier to build new applications as well as restructuring existing applications.
References
[1] Service Oriented Analysis and Design, http://www.redbooks.ibm.com/abstracts/sg246303.html
The Birth of SOA November 3, 2008
Posted by Aditya Thatte in SOA.Tags: SOA
1 comment so far
In the early days businesses were small involving small and compact architectures which were using vendor and enterprise specific standards.
But over decades the need of the enterprises started growing and businesses had to cope up with their competitors. As enterprises started expanding, system architectures became complicated as well involving ever changing components and layers demanding to the business.
Early “solutions” resulted in combinations of platform, vendor and enterprise-specific standards that remained largely proprietary to the implementing enterprise. Enforcement of these attempted standardizations within an enterprise and across lines of business and geographies led to creation of shared services organizations whose effectiveness depended on diligent management oversight.
Ultimately, such solutions for enterprise standards and enforcement by one or more shared services organizations failed to keep pace with constantly [2] evolving business requirements. Moreover, the largely proprietary standards locked an enterprise’s allegiance to specific computing platforms and supporting vendors.
Subsequently, use of the Internet as a viable means to interact with customers and vendors led to devising front-end Web interfaces to access enterprise data for e-commerce.
XML (Extensible Markup Language) soon entered the scenario with the different schema formats which were used to represent different formats of data. Enterprises identified the capability of XML for exchanging data in the enterprise computing models.
SOAP (simple object access protocol) the key figure in exchanging the data over distributed nodes wrapped XML data and drove it over the ubiquitous HTTP.
This was the most compelling aspect of SOAP and by that time most of the enterprises had accepted the viability of these standard mechanisms and IT concerns began to be addressed.
The concept of SOA was born and a hope for business being supported by technology evolved.
The IT industry trended to solving enterprise’s computing information exchange problems involving employees, customers, suppliers and partners-with technologies that aligned with overarching standards tolerant of dynamic business requirements.
It was the business which led to the concept of SOA , because with so many different systems and technologies, enterprises could not keep a single holistic view or track of the customers. As systems could not talk to each other, enterprises lost time in processing the customers whereby losing them , so it was very business driven.
Getting Started with SOA : The concept of a Service March 7, 2008
Posted by Aditya Thatte in SOA.Tags: Computer science, SOA, Web services
add a comment
This blog is dedicated to the concept of Service Oriented Architecture ( SOA) and Complex Event Processing (CEP). Before introducing SOA , I would like to dig deep into the basic concept of a “Service”.
A service may be defined as an entity which processes input and gives an expected output. It can also be defined as a logical component used to perform a business or technical function.
There are different kinds of services that we use in our day to day life viz. electrical service , telephone service , water service. Some are free while some are not.
We shall consider a day to day scenario of a service as an example, consider yourself going to a Restaurant. You enter the restaurant , sit at the table , check the menu , place an order to the waiter , wait till the food is served , eat the food , pay the bill. This is a normal procedure that is followed. We pass a set of instructions and information to the waiter ( instruction- how you want your meal to be cooked , information – what preparation you would like ) , and the restaurant magically provides you with your meal. The meal is the service that you pay for.
So here are a couple of things that you can relate with the meal service.
1. The quality of the food
2. Time required to serve the food
We can consider the restaurant to be componentized and how the components interact. The restaurant can be assumed to be made up of an ” order processing” , ” meal processing” and the “delivery” modules.
An important aspect in this scenario is that , the user is not bothered of how the food is made and how the components interact internally. All he is in interested is in how the food tastes and the quality of service. Thus, the business service is the “logical encapsulation of business function”.
In a Service Oriented Architecture business services interact with each other to carry out business functions. Services act like loosely coupled components orchestrated to deliver high level of service by modeling and linking business processes.Services are business functions that can form complete business processes.
SOA makes services from the legacy applications available for reuse by people , processes , applications.
Key aspects of a Service
- Specific : A service should conform to the industry based standards and protocols ( WSDL , COM , XML)
- Well defined : The service should represent its functionalities very clearly i.e the set of operations it performs
- Platform Agnostic : Services should be made able to use by the simplest standard based protocols and be independent of the computer architecture in use.
- Loosely coupled : The different services should be simple and autonomous allowing flexibility in the application
- Location transparency : The client need not know where the service actually resides.
- Reliability : The service should guarantee a high level of service.
SOA deals with building IT applications using loosely coupled components rendering a high level of service.
Be Thorough With Technology - The only way 
