14 Apr
2014
14 Apr
'14
11:38 p.m.
Module: sip-router
Branch: master
Commit: c92ec42ac07a4a000a95dcd1f3c1a349ce35ea82
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c92ec42…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Mon Apr 14 22:37:02 2014 +0200
acc: extended documentation for db_insert_mode parameter
- if set to 2, async insert operation is used to store the acc record in
database table
---
modules/acc/README | 3 +++
modules/acc/doc/acc_admin.xml | 4 ++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/modules/acc/README b/modules/acc/README
index da2df70..bf53f25 100644
--- a/modules/acc/README
+++ b/modules/acc/README
@@ -1113,6 +1113,9 @@ modparam("acc", "db_extra",
"ct=$hdr(Content-type); email=$avp(s:email)")
InnoDB engine doesn't support INSERT DELAYED, thus be sure the acc
tables are defined with different type (e.g., MyISAM).
+ If set to 2, async insert is used if the db driver module has support
+ for it. If not, then standard INSERT is used.
+
Default value is 0 (no INSERT DELAYED).
Example 1.32. db_insert_mode example
diff --git a/modules/acc/doc/acc_admin.xml b/modules/acc/doc/acc_admin.xml
index c59aa0e..8b5ee60 100644
--- a/modules/acc/doc/acc_admin.xml
+++ b/modules/acc/doc/acc_admin.xml
@@ -1098,6 +1098,10 @@ modparam("acc", "db_extra",
"ct=$hdr(Content-type); email=$avp(s:email)")
the acc tables are defined with different type (e.g., MyISAM).
</para>
<para>
+ If set to 2, async insert is used if the db driver module has
+ support for it. If not, then standard INSERT is used.
+ </para>
+ <para>
Default value is 0 (no INSERT DELAYED).
</para>
<example>
16 Apr
16 Apr
11:48 a.m.
New subject: git:master: acc: extended documentation for db_insert_mode parameter
Daniel-Constantin Mierla writes:
+ If set to 2, async insert is used if the db driver
module has support
+ for it. If not, then standard INSERT is used.
+
Default value is 0 (no INSERT DELAYED).
daniel,
just to clarity, is there some relationship between INSERT DELAYED and
async insert? if db_insert_mode=2, is INSERT DELAYED or standard INSERT
used? that is, do db_insert_mode 0 and 2 somehow differ on the wire to
db server or is it so that both 0 and 2 use standard INSERT?
-- juha
12:11 p.m.
New subject: git:master: acc: extended documentation for db_insert_mode parameter
Hello,
On 16/04/14 10:48, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
No.
+ If set to 2, async insert is used if the db
driver module has support
+ for it. If not, then standard INSERT is used.
+
Default value is 0 (no INSERT DELAYED).
daniel,
just to clarity, is there some relationship between INSERT DELAYED and
async insert? if db_insert_mode=2, is INSERT DELAYED or standard
INSERT
used? that is, do db_insert_mode 0 and 2 somehow differ on the wire to
db server or is it so that both 0 and 2 use standard INSERT?
Both use standard
INSERT.
INSERT DELAYED is an extension of MySQL and doesn't work for all engines
(e.g., innodb) and there are even plans to be removed, as I got it from
some forums.
The async insert is based on a generic framework that can be extended to
all other queries that don't return a db result needed in config or
inside the module (e.g., delete, update -- on the todo list, trying to
figure out if would be possible to do it via db api for all db modules
at once).
In the recent commits I added the features of creating a dedicated group
of processes (named async workers) that listen on an internal socket for
tasks sent by other processes (e.g., sip workers, timers, etc.). These
new processes are used also by the async_task_route() function.
The mechanism behind async insert is as follow:
- the INSERT query is printed by the process that does the db operation
- the mysql module instead of sending the query to mysql server, clones
it in shared memory and sends it to the group of async workers
- one of the workers reads the task and sends the query to the database
server
To have the above working, the db_url is also cloned and sent to async
workers in order to identify the right connection to use. The first idle
async worker is receiving the task (it is kernel based, the same
mechanism used for many processes reading on the same UDP socket). You
have to specify the number of async workers via global parameter
async_workers:
- http://www.kamailio.org/wiki/cookbooks/devel/core#async_workers
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
12:24 p.m.
New subject: git:master: acc: extended documentation for db_insert_mode parameter
Daniel-Constantin Mierla writes:
No.
good. so perhaps the comment on default value could be (no INSERT
DELAYED nor async insert is used).
Default value is 0 (no INSERT DELAYED).
daniel,
just to clarity, is there some relationship between INSERT DELAYED and
async insert? The mechanism behind async insert is as follow:
- the INSERT query is printed by the process that does the db operation
- the mysql module instead of sending the query to mysql server, clones
it in shared memory and sends it to the group of async workers
- one of the workers reads the task and sends the query to the database
server
does there need to be a free async worker to serve the request or are
the requests buffered so that the sender of the request is always
immediately free to go on with other business?
To have the above working, the db_url is also cloned
and sent to async
workers in order to identify the right connection to use. The first idle
async worker is receiving the task (it is kernel based, the same
mechanism used for many processes reading on the same UDP socket). You
have to specify the number of async workers via global parameter
async_workers:
- http://www.kamailio.org/wiki/cookbooks/devel/core#async_workers
that would have been my next question. if someone only reads
acc/README, it does not mention a need set async_workers > 0 in order to
benefit from db_insert_mode=2.
-- juha
2:03 p.m.
New subject: git:master: acc: extended documentation for db_insert_mode parameter
On 16/04/14 11:24, Juha Heinanen wrote:
The sender is immediately free. The request is queued in the internal
socket (used to pass only the pointer to shared memory query) and will
be handled by first async worker. In other words, the sender does like
an 'udp send', but via a reliable socket.
You can add a note about this as well, if you put
more content in the
docs for this parameter.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Daniel-Constantin Mierla writes:
No. good. so perhaps the comment on default value could be
(no INSERT
DELAYED nor async insert is used).
You can enhance the docs as you consider more
clear -- the possible
values are listed in the same section.
Default value is 0 (no INSERT DELAYED).
daniel,
just to clarity, is there some relationship between INSERT DELAYED and
async insert? The mechanism behind async insert is as follow:
- the INSERT query is printed by the process that does the db operation
- the mysql module instead of sending the query to mysql server, clones
it in shared memory and sends it to the group of async workers
- one of the workers reads the task and sends the query to the database
server
does there need to be a free async worker to serve the request or are
the requests buffered so that the sender of the request is always
immediately free to go on with other business? To have the above working, the db_url is also
cloned and sent to async
workers in order to identify the right connection to use. The first idle
async worker is receiving the task (it is kernel based, the same
mechanism used for many processes reading on the same UDP socket). You
have to specify the number of async workers via global parameter
async_workers:
- http://www.kamailio.org/wiki/cookbooks/devel/core#async_workers
that would have
been my next question. if someone only reads
acc/README, it does not mention a need set async_workers > 0 in order to
benefit from db_insert_mode=2.
3903
days inactive
3905
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen