SMP for IO-bound applications - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion SMP for IO-bound applications
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
MIME-Version: 1.0
Date: Thu, 21 Jun 2012 20:37:44 +0200
Message-ID: <CAHcC6xcCbeT09i6wmONTLefRguYX5jftRPsDSZ1w5LKBgdm...@mail.gmail.com>
From: Erisa Dervishi <erisa...@gmail.com>
To: erlang-questi...@erlang.org
Subject: [erlang-questions] SMP for IO-bound applications
Precedence: list
Content-Type: multipart/mixed; boundary="===============5229999702566487915=="
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

--===============5229999702566487915==
Content-Type: multipart/alternative; boundary=14dae9340eb7bb83b504c2ffcf2b

--14dae9340eb7bb83b504c2ffcf2b
Content-Type: text/plain; charset=ISO-8859-1

Hi,
As part of my studies, I have recently been doing some performance
evaluations on Erlang SMP improvements  for IO-bound applications.

The applications I considered for the evaluation were Emysql driver (
https://github.com/Eonblast/Emysql) and Mnesia.
I have created an Erlang module for performing reads/writes from/to Mysql
DB through Emysql driver, and another Erlang module for communicating with
Mnesia.
Both the modules have two methods write(nr_records) which writes nr_records
records to the database (MySQL, or Mnesia), and read(nr_records) which
reads nr_records random records from the db. (both the reads and writes are
consecutive, not in chunks)
I have a load generator tool which simulates simultaneous requests to both
the modules and gathers performance statistics. I generate as much load as
needed to stress the applications (near the saturation point)
The metrics I uses are the throughput (no. of sessions/sec), and the
session duration. A session is a call to write(nr_records)
or read(nr_records) function depending on the test case (read or write). So
if I call write(500), I measure the duration of a session that does 500
hundred inserts into the database.

The tests I run have these parameters:

A)Type of operations: 1- Reads 2-Writes
I have just one table with 20 fields, and the reads and writes are just
select and insert operations in that table

B) I/O applications: 1- Emysql 2-Mnesia

C) SMP parameters:
1- SMP enabled, no. of schedulers = no. of cpu cores
2-SMP  enabled, no. of schedulers = 1
3- SMP disabled

D) Erlang OTP versions:
1- Erlang R12B (The SMP has only one run-queue and multiple schedulers)
2- Erlang R15B (Improved SMP, 1 run-queue per each scheduler)

The tests included all possible combinations from A,B,C,D. They were run in
Solaris 10 x86 (a 16 cores machine).
In general these were the results I got:

*Emysql driver:*
1- There is a a big difference in performance between SMP enabled and
disabled in both the Erlang versions (R12 and R15)  for both read and write
tests.  So I can say that SMP rocks! However, you have to have enough load
to achieve that (for low load I could not see any difference, sometimes it
was even better to disable SMP)

2- I was expecting a much better performance for SMP enabled (no. of cores
= no. of schedulers) in R15 than in R12, since the schedulers' logic has
changed a lot from R12 to R15. But the results were more or less the same.
 I was thinking since I had a multithreaded db like MySql, a multiple
db-connections driver as Emysql, and SMP with multiple schedulers with
their own run queues, I could get better results than in R12 where there is
only one run-queue and multiple schedulers (more lock contention).
Is it maybe because the processes are just doing IO and nothing
CPU-intensive?

3- I realized that CPU usage in R15 SMP enabled is twice higher than the
CPU use in R12 SMP enable. All the cores have a CPU usage over 90%, and I
can see that the beam process is using up to 75-80% of the CPU, the rest is
the mysql daemon process. Is it because in R15 the scheduling algorithm has
become more complex?

*Mnesia*
*
*
I have only one table (as I said before) created with the attribute
disc_copies, and it is stored only in one node. The whole table fits in
RAM, and I tried to keep it simple by controlling the size of the table
during my tests, in order not exceed RAM capacity

4-  For the write tests in Mnesia I see the same behavior as in Mysql.
However, since the data are all loaded in RAM, the session duration is
shorter, and the gain in performance between SMP enabled and disabled is
not as huge as in Mysql.

5- For the read tests, I have two observations. First, the dirty reads are
10 times faster than the reads that use transactions. Second, I have better
results for SMP disabled (twice faster, though in both cases the session
duration is in order of millisecods, 70 msec vs 30 msec).

6- Same as in Mysql, no difference in performance between R12 and R15 with
SMP enabled, for both read and write tests.

If you have read so far, and have a comment on my results, you are welcome.
Especially about the no difference btw R12 and R15 and the high CPU usage
in R15 when the applications are IO-bound.

Thanks,
Erisa

--14dae9340eb7bb83b504c2ffcf2b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br>As part of my studies, I have recently been doing some performance e=
valuations on Erlang SMP improvements =A0for IO-bound applications.<br><br>=
The applications I considered for the evaluation were Emysql driver (<a hre=
f=3D"https://github.com/Eonblast/Emysql" target=3D"_blank">https://github.c=
om/Eonblast/Emysql</a>) and Mnesia.<br>


I have created an Erlang module for performing reads/writes from/to Mysql D=
B through Emysql driver, and another Erlang module for communicating with M=
nesia.<br>Both the modules have two methods write(nr_records) which writes =
nr_records records to the database (MySQL, or Mnesia), and read(nr_records)=
 which reads nr_records random records from the db. (both the reads and wri=
tes are consecutive, not in chunks)<br>


I have a load generator tool which simulates simultaneous requests to both =
the modules and gathers performance statistics. I generate as much load as =
needed to stress the applications (near the saturation point)<br>The metric=
s I uses are the throughput (no. of sessions/sec), and the session duration=
. A session is a call to=A0write(nr_records) or=A0read(nr_records) function=
 depending on the test case (read or write). So if I call write(500), I mea=
sure the duration of a session that does 500 hundred inserts into the datab=
ase.<br>

<br><div>The tests I run have these parameters:<br>
<br>A)Type of operations: 1- Reads 2-Writes<div>I have just one table with =
20 fields, and the reads and writes are just select and insert operations i=
n that table<br><br>B) I/O applications: 1- Emysql 2-Mnesia<br><br>C) SMP p=
arameters: <br>


1- SMP enabled, no. of schedulers =3D no. of cpu cores <br>2-SMP =A0enabled=
, no. of schedulers =3D 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 te=
sts included all possible combinations from A,B,C,D. They were run in Solar=
is 10 x86 (a 16 cores machine).<br>In general these were the results I got:=
<br>


<br><b>Emysql driver:</b><br>1- There is a a big difference in performance =
between SMP enabled and disabled in both the Erlang versions (R12 and R15) =
=A0for both read and write tests. =A0So I can say that SMP rocks! However, =
you have to have enough load to achieve that (for low load I could not see =
any difference, sometimes it was even better to disable SMP)<br>


<br>2- I was expecting a much better performance for SMP enabled (no. of co=
res =3D no. of schedulers) in R15 than in R12, since the schedulers&#39; lo=
gic has changed a lot from R12 to R15. But the results were more or less th=
e same. =A0I was thinking since I had a multithreaded db like MySql, a mult=
iple db-connections driver as Emysql, and SMP with multiple schedulers with=
 their own run queues, I could get better results than in R12 where there i=
s only one run-queue and multiple schedulers (more lock contention).<div>


Is it maybe because the processes are just doing IO and nothing CPU-intensi=
ve?</div><div><br></div><div>3- I realized that CPU usage in R15 SMP enable=
d is twice higher than the CPU use in R12 SMP enable. All the cores have a =
CPU usage over 90%, and I can see that the beam process is using up to 75-8=
0% of the CPU, the rest is the mysql daemon process. Is it because in R15 t=
he scheduling algorithm has become more complex?=A0</div>


<div><br></div><div><b>Mnesia</b></div><div><b><br></b></div><div>I have on=
ly one table (as I said before) created with the attribute disc_copies, and=
 it is stored only in one node. The whole table fits in RAM, and I tried to=
 keep it simple by controlling the size of the table during my tests, in or=
der not exceed RAM capacity=A0</div>


<div><br></div><div>4- =A0For the write tests in Mnesia I see the same beha=
vior as in Mysql. However, since the data are all loaded in RAM, the sessio=
n duration is shorter, and the gain in performance between SMP enabled and =
disabled is not as huge as in Mysql.</div>

<div><br></div><div>5- For the read tests, I have two observations. First, =
the dirty reads are 10 times faster than the reads that use transactions. S=
econd, I have better results for SMP disabled (twice faster, though in both=
 cases the session duration is in order of millisecods, 70 msec vs 30 msec)=
.</div>
<div><br></div><div>6- Same as in Mysql, no difference in performance betwe=
en R12 and R15 with SMP enabled, for both read and write tests.</div><div><=
br></div><div>If you have read so far, and have a comment on my results, yo=
u are welcome. Especially about the no difference btw R12 and R15 and the h=
igh CPU usage in R15 when the applications are IO-bound.</div>
<div><br></div><div>Thanks,</div><div>Erisa</div><div><br><br><br><br><br><=
br><br></div></div>
</div>

--14dae9340eb7bb83b504c2ffcf2b--

--===============5229999702566487915==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--===============5229999702566487915==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
