[erlang-questions] measuring OS context switches

ke han ke.han@REDACTED
Wed Sep 20 08:03:34 CEST 2006


I am doing a comparative analysis of a webapp with Ruby on Rails vs.  
Yaws+mysql.  The app being used is the "depot" app from the book  
Agile Programing in Rails (Pragmatic Programmer).  This app is used  
in many Rails based tutorials and seems a good one to use since I  
already have the Rail version complete and it would be hard for the  
Rails community to say I "cheated" as its their app.

There is little value in just measuring end-to-end page load times  
and overall stress testing as it doesn't explain "why" erlang is  
beating the pants off Rails (obviously I'm making assumptions about  
the results ;-)).  I want to show ratios of "real work" vs. OS  
context switches + other internal communications between processes,  
etc...

Can anyone give ideas for how to go about measuring such things??  I  
can litter Rails code with all sorts of wall clock logging and try to  
put this to use, but this also means I have to dig into lighttpd and  
mysql to log some of their times as well...there must be some tools  
or methods I don't know about.  I was hoping to have access to a  
Solaris server for these tests and use DTrace and other profiling  
tools Sun crows about, but alas, no interest from Sun (or hosting  
partners) in providing a box to test on...So I'll be doing this  
initial analysis on my iMac dual core and maybe a dual proc FreeBSD  
server.

If I do this correctly, I should have the sample code and scripts to  
allow others to try out variations on my tests.  Such as:  Rails: 1  
lighttpd proc, 20 mongrel/ruby procs, 1 mysql proc (20 connections)  
on a single CPU vs, variations on multi-core.  The erlang solution  
could be varied by multi-threaded erlang vs. single threaded and  
such.  I'm not so interested in measuring context switches between  
procs within a multi-thread erlang vm as I think my results will be  
interesting enough to show how much overhead is in the Rails "runtime  
architecture".

thanks, ke han

BTW, Yariv, if you catch this email, I will be using your erlyDB  
along with some javascript and erlang prototypes I've been working on  
to make the front end work.




More information about the erlang-questions mailing list