I/O queues always help. Receiving from an ESME or bb would be much faster.
Processing would be also if they are waiting I/O states in the code, to take
advantage of the waiting period. Of course new queues would have to be
implemented there. Queue overhead should be minimal. Just a pointer append
and a pointer move. Muteces do not collide.
More importantly smppbox would be more autonomous. It could still provide a
working interface to the ESME client, even if downstream bb is down for
upgrade, smsc reconfiguration, etc.
A much better, robust design overall. I am puzzled about the reported
delays.
BR,
Nikos
----- Original Message -----
From: "Alexander Malysh" <amal...@kannel.org>
To: "Rene Kluwen" <rene.klu...@chimit.nl>
Cc: <devel@kannel.org>
Sent: Monday, August 23, 2010 11:48 AM
Subject: Re: smppbox bulk sms: slow reception from a client
Hi Rene,
I don't really understand why do you need this patch to get more
performance...
If you will use queues you have also use store or you have to delay acks to
the client.
And as far as I see it will have the same effect if client would use
windowing and you
just forward messages to bearerbox without any queues because you will have
queues
overhead.
Thanks,
Alexander Malysh
Am 22.08.2010 um 21:03 schrieb Rene Kluwen:
Sorry, forgot to copy the list.
-----Original Message-----
From: Rene Kluwen [mailto:rene.klu...@chimit.nl]
Sent: Sunday, 22 August, 2010 20:53
To: 'Hillel Bilman'; 'Davit Mirzoyan'; 'Alvaro Cornejo'; 'Nikos Balkanas';
'ad...@impexrur.pl'
Subject: RE: smppbox bulk sms: slow reception from a client
For the ones who are worried about smppbox performance. Here is something
that I believe in better than the queue implementation (like in my earlier
post of today).
At some point in time, I made smppbox wait for a bearerbox ack before
acknowledging the message back to the ESME and vice versa. In the
following
patch, I turned that back again. I immediately acknowledge the message,
irregardless what it's relaying status later is going to be.
If you have problems with smppbox and/or slow performance, this patch
might
be for you. I made the patch in such a manner that it is easy to make a
configuration option for this, in a later stage.
Please test.
== Rene
-----Original Message-----
From: Hillel Bilman [mailto:hbil...@ecommunicate.biz]
Sent: Sunday, 22 August, 2010 18:59
To: rene.klu...@chimit.nl
Cc: devel@kannel.org
Subject: RE: smppbox bulk sms: slow reception from a client
Thanks for the update and to Chimit for smppbox in general.
To take up the discussion from the user group, you mentioned a great idea
to
have another set of queues that smppbox only uses.
To add to this, it would be great to have the same set of queues where you
can set priority and range 0-3 is allowed. Then this prevents your
smppbox
flooding bearer box and also you can far more easily isolate problems from
smppbox.
Regards
<smppbox_direct_acks_1.patch>
