John,
Using "exec" has its own penalties - the exec itself is CPU consuming as
the Operating System has to create a new process each time. Os it is not
I/O, but it is CPU (system time).
For the accounting part, I still recommend the flatstore as the most
efficient approach.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 12.01.2015 11:55, John Nash wrote:
OK..I think doing accounting in exec makes perfect sense.
On Mon, Jan 12, 2015 at 2:36 PM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi John,
Indeed, depending on the nature of the query, some answers can be
cached, other not. If not, you need to be sure your DB server is
as efficient as possible in answering.
Accounting via flatstore file can be realtime (data is written in
RT into file and you can rote them when you need).
The next 2.1 is the first OpenSIPS version supporting Async I/O
ops. There are many kinds of I/O ops and used in many places. It
is hard to add async support for all of them from the day one. The
current plan is to have support for exec module, for rest_client
module and possible for some mysql queries.
In the worst case, you can push your DB queries into external
scripts and use the "exec" module with the async support.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.01.2015 15:48, John Nash wrote:
Hello Bogdan,
Thank you. Cache features are really good and I am using for
Register and Invite auth but I need to run a query to find out
allowed duration for a call (unfortunately caching cannot be used
in that). Also Accounting I am afraid has to be real time in my case.
I think i should look forward to version 2.X till the features I
need are there. Any guess how long full featured development
version will be out?
John
On Sat, Jan 10, 2015 at 1:16 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Nash,
It is somewhere in the middle :). Of course the DB ops will
bring some penalties to the performance, so you need to take
care and tune your DB for the best performance (not to drag
down opensips). With db ops is very common in OpenSIPS
scripts, so you do not do anything crazy or stupid there.
Of course, you should look into optimizing the DB ops you use:
- DB auth - use caching at script level (see
http://www.opensips.org/Documentation/Tutorials-MemoryCaching)
- ACC - consider using db_flatstore to avoid writing into
a real DB
- dialog - if not really a must use db modes 2 or 3
(http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id294001)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.01.2015 20:19, John Nash wrote:
I have used opensips for load balancing and some border
proxy+ NAT+rtpproxy in past and am quite happy with it.
Recently I decided to add DB operations (Auth and
accounting, routing and dialog into it so that heavy lifting
of VOIP network can be given to opensips. I wanted to send
call to PBX only when it is really needed (Like voicemail
and conference etc)
But in a long time I saw this article
http://www.opensips.org/Documentation/TroubleShooting-FindPerfPb
As per this tutorial I think if any DB operation is slow, it
will hit overall performance (I mean the transactions which
do not require DB can also be stuck).
I know good engineers at openisps have already figured it
out and working on 2.X version but looks like it will take a
while so that I can give it a try (As dialog is not in
current release).
With 1.X series + DB auth/acc + dialog should I reconsider
my approach or there are systems running successfully and I
am just being paranoid?
John
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
