You didn't understand me. I asked about the performance penalty in the
queued patch, and what was responsible for it, because i couldn't see it.
You don't have a dict for stored_acks in there.
That's the other patch, which I agree it is faster with immediate acks. But
even there, it is not the dict the problem, it is a hash table after all,
but the round-trip you are doing to get the ack.
BR,
Nikos
----- Original Message -----
From: "Rene Kluwen" <[email protected]>
To: "'Nikos Balkanas'" <[email protected]>; "'Hillel Bilman'"
<[email protected]>
Cc: <[email protected]>
Sent: Monday, August 23, 2010 12:27 AM
Subject: RE: smppbox bulk sms: slow reception from a client
I think that if I profile, the bottle neck will be the dict that I use to
store acks. But not 100% sure.
== Rene
-----Original Message-----
From: Nikos Balkanas [mailto:[email protected]]
Sent: Sunday, 22 August, 2010 23:25
To: Rene Kluwen; 'Hillel Bilman'
Cc: [email protected]
Subject: Re: smppbox bulk sms: slow reception from a client
Let's see. On one hand you have a serial design, on the other a
multithreaded one. OK, not exactly multithreaded, but queued which will
get
you ~80% of a true multithreaded design. Which one is faster, and more
robust under heavy traffic?
How much of a delay are you talking about? Any idea what is the offending
call(s)?
BR,
Nikos
----- Original Message -----
From: "Rene Kluwen" <[email protected]>
To: "'Hillel Bilman'" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, August 22, 2010 9:15 PM
Subject: RE: smppbox bulk sms: slow reception from a client
I knew this wasn't a good idea. The overall performance is a lot slower
now.
Please find attached an smppbox implementation including queues (patch to
svn trunk).
I am myself -1 for this patch. But here you have it, for the ones that
want
to try.
== Rene
-----Original Message-----
From: Hillel Bilman [mailto:[email protected]]
Sent: Sunday, 22 August, 2010 18:59
To: [email protected]
Cc: [email protected]
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
