Memcached scalability

Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< Outage | Tukwila delayed - again >

Thursday, May 21. 2009

Behind the scenes of many of your favourite websites you will find an application, that speeds up their page creation times. It's called memcached. At the end it's not much more than a server that allows you to access remote memory to store and load objects like the output of a database query or frequently accessed web pages. Such an mechanism is able to reduce the load to your database by at least an order of a magnitude.

So it's a good idea to do some tuning on it to run on new types of hardware, like CPUs that look like 64 CPUs as such applications were initially developed on architecture with 4 procs at maximum at most deployments.

Zoran wrote about his and his teams efforts to optimize scaling of a single-instance memcached on an UltraSPARC T2 processor. They were able to yield 500.000 operations per second at 100 Byte and 255.000 operations per seconds at 4096 Byte. The second test almost saturated the 10 GBit/s interface of the system.

Shanti made the same test on a dual-cpu Nehalem server: She was able to yield 352,190 with a single instance and 470K ops/sec with two instances. I don't want to make a comment on the performance (I don't know if Shanti had the scalability patch Zoran used in his benchmarking), albeit it's interesting that an single-socket T2 system (announced more than one and half year ago) delivers more performance than a dual-socket Nehalem.

The more important takeaway is: The x86/x64 business is running into the same scalability problems as the massive multicore procs like UltraSPARC T2. So much power, so much work to do, but the software doesn't allow them to to it as it wasn't developed for such environments. Shantis article strongly hints towards such an situation. Sun just ran into this problem 3-4 years earlier than the rest. But: The more people have a problem, the more people working at the solution. I assume we will see more scalability patches in the future for a lot of software projects.

PS: It's nice to see that Sun was correct about a development ... again ...

Posted by Joerg Moellenkamp in English, General at 09:20 | Comments (3) | Trackbacks (0)

Defined tags for this entry: sun

Related entries by tags:

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

I don't think that you should compare the number of sockets when saying the T2 system is the winner. What is more intersting todays is which system costs less or consumes the less power.

#1 Fabrice Bacchella on 2009-05-21 12:36 (Reply)

Obviously you are right. This was another reason why i didn't headlined the article "T2 faster than Nehalem". But it's a nice example that the x86 industry runs into same problem problem as Sun.

Nevertheless: You have to consider, that the T2 is 1,5 years old proc at 65 nm and the Xeon X5... is brandnew at 45nm

Power: Of course i can do that ... something a socket needs power

.

I just did a comparision in the respective power calculators. An X4170 (the chassis is more comparable to the T5120 to factor out chassis design differences out of this comparision as i try to compare "processors" takes 399 Watts with 48 GB.
The T5120 with a single T2 needs 415 Watts with 64 GB. That's a tie in regard of the power ...

#1.1 Joerg M. (Homepage) on 2009-05-21 13:28 (Reply)

niagara systems are great but their price is steep.

unlike the m3000 tenaya better be really cheap!

I always wondered if there will be a shrink of niagara2 to 45nm as announced in the 2006 roadmaps. should save a ton of power and maybe enable to up the clock a bit.

#2 Max on 2009-05-21 19:52 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry