BT

Article: Spectacular Scalability with Smart Service Contracts

| by Floyd Marinescu Follow 35 Followers on Apr 16, 2008. Estimated reading time: 1 minute |
In this latest article, Udi Dahan describes an experience implementing a new order system in which large size message passing was affecting the scalability and even bringing down servers in the system. The article describes how they diagnosed the problem and their solution, by "changing our service contracts and introducing stateful interactions we were able to manage the performance critical state of the system."

Read Spectacular Scalability with Smart Service Contracts.

The problem:
Message size seemed to be have a large influence on all the other dimensions. As messages got larger, it took more CPU to deserialize them, more memory to hold the resulting data, more network and IO to get that data in and out of the database, altogether affecting the total processing time. However, even small requests like those to discount all pending orders for a partner were impacted by the amount of data they had to process.
The solution:
Instead of one "create order message", partners could send us many "order messages" over time keyed by their partner id and purchase order number. When they were done with all the items for that purchase order number, they would send us an "order message" with the flag "complete" set to true. It was a statefull interaction....Once resource utilization per request dropped, obviously latency dropped as well but throughput increased even higher than expected.
And Udi's key takeaway:
The key takeaway for me was this: scalability isn't a Boolean value. Beyond the number of concurrent users or servers online, scalability is a multi-dimensional cost function. Given certain response time requirements, peak and average request rates, message sizes, formats, memory working set sizes per request, CPU/IO utilization per request, how much does a given solution cost? Technology choices which made sense for strategic partners were not cost effective for regular partners. Always run the results by the business - they just might change the performance requirements once they see that costs (up-front and ongoing) overshadow projected revenue.
Have you had similar experiences?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Table fragmentation by Mauricio Arancibia

Hi Udi,

Excellent article! Your experience is very useful for everybody. Thanks for share it with us.

I have a question: assuming that saga persistence mechanism is a database table, fragmentation of this table is not an issue?

Thanks
Mauricio Arancibia

Interface matters! by Randy Shoup

Hi, Udi --



Excellent article. You make several very interesting points, including the multifaceted nature of scalability, the central importance of interface design, and the power of message-oriented interactions. Modeling the transient state as its own first-class object was a great solution.



Take care,

-- Randy

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT