Lyme vs Lamp IV

21st Century Code WorksBest of Erlang - noreply@blogger.com (Benjamin Nortier) - February 22, 2008

The first Lyme vs Lamp comparison is here!

Let’s recap. I have created a single web page, in Lyme and Lamp, based on database queries. The query is from a single table with 1000 “blog” entries, with Id, Timestamp, Title and Content fields. The web page displays the last 10 entries in the table.

I use Tsung to generate users at a progressive rate, starting from 2 users per second up to 1000 users per second:



Subjecting each web application stack to this test, they compare as follows:


But what does it mean?

It looks like Lyme and Lamp perform the same up until 240 seconds into the simulations, which is where we step up from 66 to 100 requests per second. At about that point, Lyme starts to handle less transactions per second, and the mean transaction time increases dramatically.

Where’s the bottleneck? Good question. I suspect it’s in the database query, but this is just a shot in the dark. Why could it be? Well, in the PHP version, it’s very simple to retrieve the last 10 entries:

SELECT * FROM blog_entries ORDER BY `ID` DESC LIMIT 0 , 10

Whereas with Mnesia, I’m not aware of a better way to retrieve the last 10 rows, other than to iterate backwards from the end of the table:

last_N_entries(_Key, 0, Acc) ->
lists:reverse(Acc);
last_N_entries(Key, N, Acc) ->
{atomic, {Entry, NextKey}} =
mnesia:transaction(
  fun() ->
       [Entry] = mnesia:read({blog_entry, Key}),
       NextKey = mnesia:prev(blog_entry, Key),
       {Entry, NextKey}
  end),
last_N_entries(NextKey, N-1, [Entry|Acc]).
 


last_N_entries(N) ->
{atomic, LastKey} = mnesia:transaction(fun() -> mnesia:last(blog_entry) end),
last_N_entries(LastKey, N, []).

I might try some different approaches to the Mnesia query (using ram copies instead of disk copies for example), but I’d rather put some effort into making the experiment a bit more focussed. I’d like to especially see what happens when multiple cores are thrown at the problem, but more importantly, what happens when the transactions become concurrent.

I have now realised that this is scenario is essentially a sequential load test, which will not show up Lyme’s strengths. The pages render rather quickly, so there is no concurrent page rendering. Thus, I think the next step should be to create another scenario that will create concurrent page requests…

Categories: Blogs  21st Century Code Works  Best of Erlang  

Comments

No comments so far, you could be the first.

Add comment

Name:

Email:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?