<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<div class="moz-text-flowed"
 style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">Hello
all,
<br>
<br>
Problem :
<br>
&nbsp;&nbsp;&nbsp; In the current 1.6.x OpenSIPS design, database queries are one of
the main performance issues. Running DB queries is blocking, and in
case the DB back-end is not answering as fast as expected, for reasons
like high load, table locks etc, the&nbsp; SIP processing children of
OpenSIPS remain blocked until they receive a reply from the DB and
cannot further process SIP traffic.
<br>
<br>
Solution :
<br>
&nbsp;&nbsp;&nbsp; The current 1.6.x OpenSIPS design does not have an asynchronous
reactor ( will only be present from 2.x on ) so for queries returning a
result, like selects, we can not address this problem.
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; What we can try to speed up are queries that do not return any
results, like inserts, updates, deletes.
<br>
So far we have identified two potential solutions that would allow
OpenSIPS not to block on these particular types of queries :
<br>
<br>
1) Extend the OpenSIPS DB core. Add extra core processes that would
only handle queries that return no results.
<br>
&nbsp;&nbsp;&nbsp; For example : The accounting module need to insert an entry in the
DB. The module calls the insert() function. Behind the scene, this
triggers passing all the arguments to the new core processes, via IPC
mechanisms. The insert() then exists and the SIP children continues
execution as if the entry has been inserted in the DB. Meanwhile, the
DB core processes receive the new parameters, build and send the query,
blocking if necessary.
<br>
<br>
&nbsp;&nbsp;&nbsp; Advantages of this solution&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : General solution, works for
all DB drivers. Transparent for modules.
<br>
&nbsp;&nbsp;&nbsp; Disadvantages of this solution&nbsp;&nbsp;&nbsp; : Not an easy task. IPC
communication for all queries.
<br>
<br>
2) Use the asynchronous functions exported by each particular DB
driver.
<br>
&nbsp;&nbsp;&nbsp; For example : The accounting module need to insert an entry in the
DB. The module calls the insert() function. The particular DB module
used has been modified to call the asynchronous functions whenever it
can ( inserts, updates, deletes ). The function exists immediately and
the actual operation on the DB back-end will be applied in the future.
<br>
<br>
&nbsp;&nbsp;&nbsp; Advantages of this solution&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Less code to write, no extra
overhead for IPC
<br>
&nbsp;&nbsp;&nbsp; Disadvantages of this solution&nbsp;&nbsp; : Not a general solution. While
Postgres API fully supports asynchronous queries, Mysql only allows
regular queries to be run asynchronously out of the box, while prepared
statements can be ran asynchronously with some quite ugly hacks. Other
modules that deal with an effective DB backend ( db_berkeley, db_oracle
) would need extra documentation, and eventually, if they do not
support asynchronous queries, inserts will block until completed for
those particular modules.
<br>
<br>
<br>
What solution do you find is more appropriate ? Or if you have better
solutions, please share them.
<br>
<br>
Regards,
<br>
<br>
<div class="moz-txt-sig"><span class="moz-txt-tag">--&nbsp;<br>
</span>Vlad Paiu
<br>
OpenSIPS Developer
<br>
<br>
</div>
</div>
</body>
</html>