The reverse C10K problem

The original C10K problem studies how to provide reasonable service to 10,000 simultaneous clients or HTTP requests using a normal web server. I call the following problem the reverse C10K problem, or RC10K --- how to support 10,000 simultaneous outbound HTTP requests running on a web server. The RC10K problem can be found in scenarios like service orchestrations and server-side mashups. A server-side mashup needs to send several simultaneous HTTP requests to partner services for each inbound request.

Many approaches to improving the performance and scalability of HTTP servers can be applied to tackle the original C10K problem. However, whether these approaches can tackle the reverse C10K problem needs to be verified. My recent paper discussed the RC10K problem, and presented some experiment results got from a prototype mashup server application.

People like to try what they are not good at

From xkcd.com

Two models of load testing and corresponding tools

When a load testing is conducted, a tester first needs to decide what kind of workload should be applied, that is, load characterized by the number of clients or arrival rate (interarrival time) . For those who always use one tool for load testing, it is better to try other options to get different interpretation of system behaviors.

Tools specify the number of clients:

• JMeter
• Faban

These two are both developed in Java. The most important parameter to be configured is the number of simulated users that will send requests to the server. The simulated concurrent users are natually mapped to Java threads. Both of them can specify thinking time of different distributions. A difference between them is that JMeter specifies how many rounds the request scenario will run and Faban specifies how long the test will run.

Tools specify the arrival rate:

• Tsung

Since the processes in Erlang are very light, new process can be spawned very fast and a machine can support thousands of Erlang processes without problem. This make it possible for Tsung to generate load of given interarrival time, while it is difficult for Java-based tools.

Finally they heard that ... "web-based services"

Back in 2007, W3C had a workshop of "Web of Services for Enterprise Computing". I have blogged it here. The presentations at the workshop made me understand more about why some thought the so-called "web services" were not about web. It was around that time that I started to believe that REST is much better than WS-* for the problems I was looking at. These came to my mind when I read the CFP of ICWS2009 this morning. It sounds like that the organizers began to realize that "web services" should be "web-based services". Two of three major conference areas have web titled -- "Web-based Services", "Web Services Applications beyond Web". Hope I can have a manuscript for it by January 19, 2009.

Reflection from Pat Helland about Amazon S3 outrage

The post titled "Confidence in the Cloud" by Data guru Pat is really worth reading. Interesting quotations from his post:

the implementations which sent the minimum amount of data seemed to be the most resilient.

which leads to

Communicating less information within a message is usually best. If you send extra stuff, it can cause corruption!

For cloud, he predicts

As I look at data center cost structures, it is clear that it is going to be a competitive business with many advantages to large data center managers with large economies of scale. In a handful of years, most companies will look to offsite providers for their reliable servers.

Word cloud of my reading

Created by Wordle. You may need Firefox, because Chrome does not support the applet. 

Comic of Google Chrome

Its quite interesting to read what Google engineers think about the web browser or web client design with respect to multi-threading and multi-process for tabs (http tasks). 

And what the multi-process means for memory management.  Many blocking and crashing problems result from shared memory and memory space.