ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

Is the pipe half-full or half-empty?

David Linthicum does a good job of pointing out the factors that can affect performance of your SOA in his recent Real World SOA entry: When to Consider SOA Performance.

I particularly liked rule #3:

\"Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services.\"

You should indeed take the network into careful consideration when you're architecting your SOA, but not just regarding how much bandwidth is available. Too often we think of the network as nothing more than a pipe, and blame poor performance on limited bandwidth. It's often the case, however, that the network pipe is actually underutilized and poor performance is the result of other network-based mitigating factors, like the overhead inherent in TCP connections. It's that second half of David's sentence that is truly important when considering how distributing fine-grained services affects the performance of your SOA.

I chatted with an architect at Gartner's Integration and Web Services Summit earlier this month who clearly articulated his understanding of this problem - too many TCP connections are often the root cause of poor performance, especially in a JavaEE-based architecture. We talked about that earlier this month in When Reuse Becomes a Four Letter Word. I won't repeat the discussion, except to say that the more services you connect to, the higher the cost of TCP session management across the application.

Luckily you can offload some of that processing to alleviate the overall burden on the server and thereby increase the efficiency of the platform. TCP sessions are costly, and if your application comprises a lot of services that's a lot of overhead. Using an application delivery controller like BIG-IP can not only offload a lot of that overhead but in many cases it can optimize TCP as well, which means increasing the efficiency of servers as well as speeding up the delivery of services-based applications.

Imbibing: Mountain Dew

Is the pipe half-full or half-empty?

David Linthicum does a good job of pointing out the factors that can affect performance of your SOA in his recent Real World SOA entry: When to Consider SOA Performance.

I particularly liked rule #3:

\"Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services.\"

You should indeed take the network into careful consideration when you're architecting your SOA, but not just regarding how much bandwidth is available. Too often we think of the network as nothing more than a pipe, and blame poor performance on limited bandwidth. It's often the case, however, that the network pipe is actually underutilized and poor performance is the result of other network-based mitigating factors, like the overhead inherent in TCP connections. It's that second half of David's sentence that is truly important when considering how distributing fine-grained services affects the performance of your SOA.

I chatted with an architect at Gartner's Integration and Web Services Summit earlier this month who clearly articulated his understanding of this problem - too many TCP connections are often the root cause of poor performance, especially in a JavaEE-based architecture. We talked about that earlier this month in When Reuse Becomes a Four Letter Word. I won't repeat the discussion, except to say that the more services you connect to, the higher the cost of TCP session management across the application.

Luckily you can offload some of that processing to alleviate the overall burden on the server and thereby increase the efficiency of the platform. TCP sessions are costly, and if your application comprises a lot of services that's a lot of overhead. Using an application delivery controller like BIG-IP can not only offload a lot of that overhead but in many cases it can optimize TCP as well, which means increasing the efficiency of servers as well as speeding up the delivery of services-based applications.

Imbibing: Mountain Dew