![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article is part of the Quality busters series in which I look at common influences on application quality from the enterprise view of the operational environment and non-functional requirements. To address these influences is a matter of tradeoffs, with no single solution solving all problems.
The SHEEP Web team was setting up the conference room for a management presentation. While wiring the sound system, a young programmer commented, "I see so many different cables and wires here! Why isn't there a standard cable type for everything?"
Figure 1 illustrates the type of sound system the programmer might have worked with.
Figure 1. The back of a generic sound system
A senior engineer with an electrical engineering background replied, "There are many reasons for the different cable and connector types. One reason is compatibility with older systems, similar to our writing code to be compatible with legacy applications. Another reason is industry standards, where an external organization set cable and connector type specifications so sound systems can connect. But, the main reason for the different cables is each cable has different requirements -- signal characteristics such as analog or digital, power characteristics such as voltage and current levels, and performance characteristics such as signal frequency and bandwidth."
What the senior engineer knew was the connection between two sound components -- such as receiver, mixer, amplifier, and speakers -- went beyond two copper wires and some insulation. Some cables are shielded while others are not. Some cables have two wires while others may have five, six, twelve, or more wires.
The deciding factor lies in the nature of signal being transmitted. For example, the electrical characteristics of the power cable are significantly different from those of the speaker cable.
Could the cables on a sound system be standardized with a single wiring standard, such as using a shielded version of the power cable? Theoretically, this is possible, but practically, such a system would not be something a consumer would buy. The sound quality would be poor, components would have to be located very close together, the receiver could only pick up strong local broadcast stations, and still more quality issues.
A standardized approach that wasn't performing
The young programmer later researched a performance issue with the SHEEP application's new logging service. Every component that used the logging service had to wait until the service acknowledged receipt of the log message. Aspects of the program itself, such as database operations, were already tuned. The only remaining candidate cause for the performance issue was the log message delivery mechanism.
The enterprise architect specified the use of Web services, specifically SOAP messages over HTTP protocol, for all component interconnections. The aim was to move existing and new applications and components in the direction of a service-oriented architecture (SOA).
The new logging service was written to receive log messages, parse the message into individual fields, write the data to a database table, and send an acknowledgement message to the submitting component.
When testing the logging service, measurements showed that the service could not satisfy expected demand (messages submitted per second). The programmer identified three problems:
- The first was the overhead of parsing the XML message into field values to be inserted into the logging database.
- The second was the blocking of the service requestor due to the use of a synchronous (request/reply) message exchange with the service provider.
- Finally, the system could not support the number of threads running in the logging service as a result of the rate of message arrival.
Non-functional requirements might require a non-standard approach
In the SHEEP team example, the Web services approach satisfied the functional requirements and the standardized enterprise architecture, but it failed to satisfy the non-functional performance and resource utilization requirements.
In the remainder of this article, I will look at the impact on performance and resource utilization associated with each of the three problem areas identified in the SHEEP logging service example -- message parsing, message exchange protocols, and thread management. The discussion will be generalized, with no measurement data provided because my goal is to encourage architects and designers to look at the impact of the choices on the bigger solution space. Other resources, books, and articles, some of which are listed in Resources, can provide more specific details.
The first problem identified in the logging service example was the overhead of parsing the XML message -- how much CPU time and memory space does it take to read the message, parse into values, and copy those values to the database table row?
The parsing time and space is related to the format (structure and encoding) of a message. Figure 2 illustrates several common message formats -- XML, tagged, fixed-length, and native.
Figure 2. Commonly encountered message formats
XML parsing takes the longest time and uses the most space. In addition to the data values, XML parsing involves parsing the metadata tags. XML messages are composed of string datatypes which means additional processing is involved to convert from string datatype to SQL native datatypes such as integer, decimal, and date. Finally, XML message parsing usually involves dynamically creating the memory structures (like objects) to store the retrieved data values.
Parsing a tagged message takes less time than parsing a XML message, but it does take more time than parsing a fixed-length message. The parsing overhead is a result of having to read and evaluate the tags and length fields in the message to determine how to handle the data value following the tag. A tagged message also has the space overhead of allocating variable length data elements to store the retrieved data values.
In the case of a fixed-length message, the parsing is reduced to transforming from the datatype representation used in the message to the SQL native datatype. For example, a date can be passed in the message using a fixed-size string representation of YYYY-MM-DD. This must be transformed to the native SQL date datatype. The message is read directly into a memory data structure that is divided into the data fields of the message.
Finally, a refinement of the fixed-length message is the
native format message. In this case, even the data representation used in the
message matches that of the system and programming environment of the service
provider. If an integer is four bytes in length with a big-endian encoding,
then the message uses that same representation. In this case, the only parsing
is copying the data values from the message's mapped data structure to the
database table's INSERT SQL statement. With no interpretation or
transformation, the native format message has the shortest time and uses the
least amount of memory space.
The relative impact of message formats
Figure 3 shows the relative impact on message throughput (messages processed per unit of time) associated with each of the four message formats discussed. In reality, throughput is affected by a large number of variables including message arrival rate, message processing time, multiprocessing and scheduling, and resource constraints. If all other variables are held constant for the purposes of comparison, then the throughput is proportional to the inverse of the processing time. For example, if it takes 0.05 seconds to process a message, then the throughput is roughly 20 messages per second.
Figure 3. Message format processing time and effective throughput
Therefore, if throughput and minimizing memory utilization are important non-functional requirements for the application, then consider using a message format that minimizes the amount of parsing time, datatype transformation time, and dynamic memory allocation time.
The impact of a message exchange protocol
The second problem identified in the logging service example was the blocking of the service requestor process as a result of the synchronous message exchange protocol. That is, the service requestor waited until it received an acknowledgement reply from the logging service before it could resume processing. If the service requestor sent a large number of logging messages within the scope of a user transaction, then the user would experience a long response time.
In most cases, a service requestor of a logging service does not need an acknowledgement from the logging service. The functional requirements can be satisfied if the service requestor is guaranteed reliable delivery of the logging message in a send-and-forget exchange, but there are exceptions. For example, certain log events that impact financial data or personal information might require an acknowledgement because this log event is part of a larger transaction.
A synchronous message exchange protocol is the easier approach to implement and has the least impact on the service provider environment. However, a synchronous exchange does have a performance impact on the requestor because the requestor must wait for a response.
An asynchronous message exchange protocol is the more difficult approach to implement and can have more impact on the service provider environment. A common implementation to guarantee message delivery in an asynchronous exchange is to implement a queuing environment. The additional processing time and space requirements on the service processor to manage the queuing environment will have a performance and capacity impact on the provider.
Therefore, if requestor response time and message throughput are important non-functional requirements for the application, then consider asynchronous message exchange instead of synchronous exchange to minimize blocking and delays in the requestor's processing.
The impact of thread management
The final problem identified in the logging service example was the large number of threads active at any given time. That is, so many messages were arriving and being dispatched to a new processing thread that the resource demand of the threads was exceeding available CPU resources and memory resources.
In a multiprocessing environment, the processing time for a thread is related to the availability of system resources and synchronization with other threads. The more threads running on a given system, the more demand for those limited system resources and the more time spent waiting on synchronization locks to release.
The emphasis here is that an application component designed to be multi-threading does not mean the component can handle an unlimited number of active threads. Instead, you must design the component to have a limit on the number of threads that can run. If you need more threads to handle the workload, then it becomes necessary to add more system resources such as another CPU, more memory, parallel I/O channels, or even new servers.
Figure 4 shows that the throughput of a service does not grow continually or linearly as new threads are added. Instead, it reaches a point where the overhead of managing the service, synchronization, and resource demands exceeds the actual productive processing and throughput starts declining.
Figure 4. Relationship between throughput and active threads
You can find more details about threading and performance in the references listed in Resources.
Therefore, if a service has a large number of concurrent requests and response time and message throughput are important non-functional requirements, then consider managing the number of threads running on a system and scaling the service to run on multiple CPUs and computers. If the non-functional requirement includes consolidating and reducing the number of servers, then consider changing the service to reduce system resource demand and eliminate unnecessary points of synchronization.
The best solution for a given environment is always a matter of trade-offs. For the example in this article, you could select from several possible solutions.
- The logging service might stay with the Web services approach and use a cluster of servers to spread out the workload over many computers. But this approach might conflict with the enterprise's goal of server consolidation.
- The logging service might use a more proprietary fixed-length message employing an asynchronous protocol to reduce the logging service processing time per message and eliminate the block on the service requestor. But this approach might introduce increased maintenance and monitoring overhead by the support personnel because the approach is different from the standard message middleware mechanisms.
It is very important that an application architect or designer create a solution based on both the functional and non-functional requirements and expectations. The solution can be functionally correct and satisfy every task the user needs to perform, but if the solution is unreliable, unavailable, difficult to use, or possess a number of other quality issues, then the user will not use the solution.
Learn
-
WebSphere™ MQ V6 Fundamentals (IBM Redbooks, November 2005) provides introductory information about message exchange using a message-oriented middleware product.
-
Java Threads, Third Edition (O'Reilly, September 2004) by Scott Oaks and Henry Wong is a brief discussion about thread scheduling and performance in a Java environment.
-
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (Addison Wesley, April 2005) by Nick Rozanski and Eoin Woods is a practitioner-oriented guide to designing and implementing effective architectures for information systems and provides an introduction to alternative viewpoints of an application from those of the software team in their book.
-
Loosely Coupled: The Missing Pieces of Web Services (RDS, August 2003) by Doug Kaye is an interesting book that cuts through a lot of the hype surrounding Web services.
-
Messaging and queuing using the MQI (McGraw-Hill, March 1995) by Burnie Blakeley is an early, but still one of the best, descriptions of message queuing and the various ways to use messages to integrate components.
-
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services (Prentice Hall, April 2004) and Service-Oriented Architecture: Concepts, Technology, and Design (Prentice Hall, August 2005) are two books by Thomas Erl that define the service-oriented architecture domain, including short descriptions about the performance impact and increased computing resources required to implement a SOA solution using Web services.
-
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison Wesley, October 2003) by Gregor Hohpe and Bobby Woolf is an excellent catalog of many message solution patterns.
-
Evaluating SOAP for High Performance Business Applications: Real-Time Trading Systems, by Christopher Kohlhoff and Robert Steele and presented at the Twelfth International World Wide Web Conference 2003, provides measurement data comparing the throughput of SOAP messaging with established fixed-field binary messaging in a high-transaction-rate environment.
-
Try this series of articles if you want to follow the SHEEP Web team.
-
Design and Implementation Considerations for IBM WebSphere MQ Integrator Message Flows (developerWorks, November 2002) discusses the major concepts and issues relating to the design and implementation of message flows.
-
Use SLAs in a Web services context, Part 3: Integrate Web services into EAI with a SLA guarantee (developerWorks, October 2004) details SOA system interruption thresholds. Use SLAs in a Web services context, Part 2: Guarantee second-generation Web services applications with a SLA (developerWorks, October 2004) discusses SOA latency and throughput.
-
Understanding quality of service for Web services (developerWorks, January 2002) looks at the various Web service QoS requirements, bottlenecks affecting performance of Web services, approaches of providing service quality, transactional services, and a simple method of measuring response time of your Web services using the service proxy.
-
Visit the developerWorks Web Architecture zone which specializes in articles covering various Web-based solutions.
-
Hone your skills with developerWorks tutorials for each technology topic area we cover, including Web architecture tutorials.
Get products and technologies
-
developerWorks offers all kinds of new technology and product downloads, including these Web architecture downloads.
-
Have developerWorks deliver customized information through RSS feeds right to your desktop -- stay informed on cutting-edge technology without a lot of work. Likewise, follow the context for new technologies with developerWorks newsletters.
Discuss
- Participate in the discussion forum.
-
Get answers to your questions, participate in rousing discussions, and become a technology guru in the developerWorks forums.
-
developerWorks bloggers have their fingers on the pulse of technology industry.
Michael Russell has a Bachelors Degree in Physics and a Masters Degree in Computer Science. He was a logistics engineer, a technical services manager, and a certified IT architect at IBM for nearly 14 years; he is currently a Web application architect for a resort company in Orlando, Florida. He has experience in Windows, UNIX, and OS/400 environments and uses Web technology for entertainment through his own company, Vicki Fox Productions.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
