 | Level: Intermediate Michael Russell (MikeRussell@VickiFox.com), Application Architect, Vicki Fox Productions
24 Jan 2006 Software professionals often get excited about a new technology, development tool, reference architecture, or other solution approach. As this excitement influences their decisions, many architects and developers attempt to solve all aspects of their current problems using this solution approach -- just like the classic saying, "Give a child a hammer and everything becomes a nail." However, when you apply a single solution approach throughout a distributed application, it can have significant impact on performance, resource utilization, and other quality attributes. The author explains why you want to think before you put all your eggs in a single basket.
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.
So many different approaches
|
The SHEEP application
The Quality busters series uses the SHEEP application to present an opening example of some quality issue. The SHEEP application is a fictional aggregation of many sales e-commerce applications that the author has encountered at several companies. The quality issues are loosely based on real-world problems that those companies address. The first article in this series introduced the SHEEP application.
|
|
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 impact of message parsing
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 messages
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.
Tagged messages
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.
Fixed-length messages
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.
Native format messages
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.
Conclusion
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.
Resources 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
Discuss
About the author | 
| | 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. He can be reached at MikeRussell@VickiFox.com. |
Rate this page
| |
