Yes sure, even though I am using Tsung (a load generator tool written in Erlang) to generate my load and get some results back. I have added a new Tsung plugin for the purpose of my tests. I am a bit busy right now but If you are interested I will share what I have done so far.<div>
<br></div><div>However, I would really like to have an opinion from an expert about my comments in here<br></div><br><div class="gmail_quote">On Sun, Jun 24, 2012 at 10:47 AM, Ronny Meeus <span dir="ltr"><<a href="mailto:ronny.meeus@gmail.com" target="_blank">ronny.meeus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jun 22, 2012 at 1:51 PM, Erisa Dervishi <<a href="mailto:erisa85d@gmail.com">erisa85d@gmail.com</a>> wrote:<br>

> Hey, thank you for your reply, but I use the same mysql driver even for my<br>
> evaluations in  Erlang OTP R12 and do not get the same CPU usage (for R12 is<br>
> up to 45%). And the tests are exactly the same (same load). I have also<br>
> checked the message queue of the process that supervises the connections,<br>
> and it looks like there isn't a bottleneck in there (the queue length is<br>
> most of the time 0 and up to 4 messages at most)<br>
> And even for Mnesia the CPU usage (though low), doubles from R12 to R15 with<br>
> smp enabled from 6% to 12% for write tests<br>
><br>
><br>
><br>
> On Fri, Jun 22, 2012 at 10:22 AM, <a href="mailto:be.dmitry@gmail.com">be.dmitry@gmail.com</a> <<a href="mailto:be.dmitry@gmail.com">be.dmitry@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I think that much of CPU usage is created by your MySQL driver.<br>
>> You should have a look at driver details. There may be copying of the<br>
>> query you send to MySQL between your benchmarking process and the real<br>
>> process that owns the socket. The same with result - parsing response and<br>
>> sending result back to benchmarking process. There may be a bottleneck in<br>
>> choosing MySQL connection from connection pool if it is made through<br>
>> supervisor.<br>
>> Try to use etop to see what functions are at the bottlenecks.<br>
>> I mean your io-intensive test may be just the test showing driver<br>
>> bottlenecks and not the problems in smp.<br>
>><br>
>><br>
>><br>
>><br>
>> ----- Reply message -----<br>
>> From: "Erisa Dervishi" <<a href="mailto:erisa85d@gmail.com">erisa85d@gmail.com</a>><br>
>> To: <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
>> Subject: [erlang-questions] SMP for IO-bound applications<br>
>> Date: Thu, Jun 21, 2012 23:28<br>
>><br>
>><br>
>> One additonal comment I forgot to mention:<br>
>><br>
>> For all Mnesia tests, the CPU usage is low in general. Only for the<br>
>> transactional read test in R15 with SMP enabled i get a CPU usage of 70%.<br>
>> From the load generator tool, i call the read(N) function that is showed<br>
>> below:<br>
>><br>
>> exec_read(0) -> done_reading;<br>
>><br>
>> exec_read(N)  -><br>
>><br>
>>        Id=random:uniform(7000000),<br>
>><br>
>>        %%io:format("~p~n",[Id]),<br>
>><br>
>>        %%[_Row] = mnesia:dirty_read({subscriber,Id}),<br>
>><br>
>>        Fun = fun() -><br>
>><br>
>>           mnesia:read({subscriber,Id})<br>
>><br>
>>        end,<br>
>><br>
>>        {atomic,[Row]}=mnesia:transaction(Fun),<br>
>><br>
>>        %io:format("~p~n",[Row]),<br>
>><br>
>>        exec_read(N-1).<br>
>><br>
>> read(N) -><br>
>><br>
>>        {A1,A2,A3} = now(),<br>
>><br>
>>        random:seed(A1, A2, A3),<br>
>><br>
>>        exec_read(N).<br>
>><br>
>><br>
>> I am using mpstat while my tests are running and beside the CPU usage,<br>
>> another difference of this test from the other Mnesia tests is that the<br>
>> syscl (system calls) column of mpstat has a value which is 20 times higher<br>
>> than the other test cases.<br>
>><br>
>><br>
>><br>
>> On Thu, Jun 21, 2012 at 8:37 PM, Erisa Dervishi <<a href="mailto:erisa85d@gmail.com">erisa85d@gmail.com</a>><br>
>> wrote:<br>
>><br>
>> > Hi,<br>
>> > As part of my studies, I have recently been doing some performance<br>
>> > evaluations on Erlang SMP improvements  for IO-bound applications.<br>
>> ><br>
>> > The applications I considered for the evaluation were Emysql driver (<br>
>> > <a href="https://github.com/Eonblast/Emysql" target="_blank">https://github.com/Eonblast/Emysql</a>) and Mnesia.<br>
>> > I have created an Erlang module for performing reads/writes from/to<br>
>> > Mysql<br>
>> > DB through Emysql driver, and another Erlang module for communicating<br>
>> > with<br>
>> > Mnesia.<br>
>> > Both the modules have two methods write(nr_records) which writes<br>
>> > nr_records records to the database (MySQL, or Mnesia), and<br>
>> > read(nr_records)<br>
>> > which reads nr_records random records from the db. (both the reads and<br>
>> > writes are consecutive, not in chunks)<br>
>> > I have a load generator tool which simulates simultaneous requests to<br>
>> > both<br>
>> > the modules and gathers performance statistics. I generate as much load<br>
>> > as<br>
>> > needed to stress the applications (near the saturation point)<br>
>> > The metrics I uses are the throughput (no. of sessions/sec), and the<br>
>> > session duration. A session is a call to write(nr_records)<br>
>> > or read(nr_records) function depending on the test case (read or write).<br>
>> > So<br>
>> > if I call write(500), I measure the duration of a session that does 500<br>
>> > hundred inserts into the database.<br>
>> ><br>
>> > The tests I run have these parameters:<br>
>> ><br>
>> > A)Type of operations: 1- Reads 2-Writes<br>
>> > I have just one table with 20 fields, and the reads and writes are just<br>
>> > select and insert operations in that table<br>
>> ><br>
>> > B) I/O applications: 1- Emysql 2-Mnesia<br>
>> ><br>
>> > C) SMP parameters:<br>
>> > 1- SMP enabled, no. of schedulers = no. of cpu cores<br>
>> > 2-SMP  enabled, no. of schedulers = 1<br>
>> > 3- SMP disabled<br>
>> ><br>
>> > D) Erlang OTP versions:<br>
>> > 1- Erlang R12B (The SMP has only one run-queue and multiple schedulers)<br>
>> > 2- Erlang R15B (Improved SMP, 1 run-queue per each scheduler)<br>
>> ><br>
>> > The tests included all possible combinations from A,B,C,D. They were run<br>
>> > in Solaris 10 x86 (a 16 cores machine).<br>
>> > In general these were the results I got:<br>
>> ><br>
>> > *Emysql driver:*<br>
>><br>
>> > 1- There is a a big difference in performance between SMP enabled and<br>
>> > disabled in both the Erlang versions (R12 and R15)  for both read and<br>
>> > write<br>
>> > tests.  So I can say that SMP rocks! However, you have to have enough<br>
>> > load<br>
>> > to achieve that (for low load I could not see any difference, sometimes<br>
>> > it<br>
>> > was even better to disable SMP)<br>
>> ><br>
>> > 2- I was expecting a much better performance for SMP enabled (no. of<br>
>> > cores<br>
>> > = no. of schedulers) in R15 than in R12, since the schedulers' logic has<br>
>> > changed a lot from R12 to R15. But the results were more or less the<br>
>> > same.<br>
>> >  I was thinking since I had a multithreaded db like MySql, a multiple<br>
>> > db-connections driver as Emysql, and SMP with multiple schedulers with<br>
>> > their own run queues, I could get better results than in R12 where there<br>
>> > is<br>
>> > only one run-queue and multiple schedulers (more lock contention).<br>
>> > Is it maybe because the processes are just doing IO and nothing<br>
>> > CPU-intensive?<br>
>> ><br>
>> > 3- I realized that CPU usage in R15 SMP enabled is twice higher than the<br>
>> > CPU use in R12 SMP enable. All the cores have a CPU usage over 90%, and<br>
>> > I<br>
>> > can see that the beam process is using up to 75-80% of the CPU, the rest<br>
>> > is<br>
>> > the mysql daemon process. Is it because in R15 the scheduling algorithm<br>
>> > has<br>
>> > become more complex?<br>
>> ><br>
>> > *Mnesia*<br>
>> > *<br>
>><br>
>> > *<br>
>> > I have only one table (as I said before) created with the attribute<br>
>> > disc_copies, and it is stored only in one node. The whole table fits in<br>
>> > RAM, and I tried to keep it simple by controlling the size of the table<br>
>> > during my tests, in order not exceed RAM capacity<br>
>> ><br>
>> > 4-  For the write tests in Mnesia I see the same behavior as in Mysql.<br>
>> > However, since the data are all loaded in RAM, the session duration is<br>
>> > shorter, and the gain in performance between SMP enabled and disabled is<br>
>> > not as huge as in Mysql.<br>
>> ><br>
>> > 5- For the read tests, I have two observations. First, the dirty reads<br>
>> > are<br>
>> > 10 times faster than the reads that use transactions. Second, I have<br>
>> > better<br>
>> > results for SMP disabled (twice faster, though in both cases the session<br>
>> > duration is in order of millisecods, 70 msec vs 30 msec).<br>
>> ><br>
>> > 6- Same as in Mysql, no difference in performance between R12 and R15<br>
>> > with<br>
>> > SMP enabled, for both read and write tests.<br>
>> ><br>
>> > If you have read so far, and have a comment on my results, you are<br>
>> > welcome. Especially about the no difference btw R12 and R15 and the high<br>
>> > CPU usage in R15 when the applications are IO-bound.<br>
>> ><br>
>> > Thanks,<br>
>> > Erisa<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
<br>
Hello<br>
<br>
I'm very interested also in the behavior of Erlang applications in an<br>
SMP environment (so also my post "Strange observation running in an<br>
SMP environment." on this mailing list). Is the code that you have<br>
created somewhere available so that I can also play with it? In case<br>
not: are you willing to share it with the community?<br>
<br>
Thanks<br>
<br>
--<br>
Best regards,<br>
Ronny<br>
</blockquote></div><br>