The threads should not be it. Otherwise all multithreaded programs would be
in trouble ;-). Anyway, they usually increase performance, reducing wait I/O
and taking advantage of every bit of free CPU.
What you put in the threads has an effect, but it is minimal. You just do a
pointer append, and pointer move. You have muteces, allright, but they
should not collide in your code. What kind of performance degradation are
you talking about?
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 3:22 PM
Subject: RE: smppbox bulk sms: slow reception from a client
The performance penalty is probably because of the overhead of the queues
and 2 extra producer threads that take care of putting the messages in the
queue.
And yes... you are right about the round trip of the ack that is the most
probably cause of the delay.
I am also working on a priority queue implementation.
The big question will be: Which is the implementation with the best
results?
Personally I think the best way to handle things is how things are now.
But
will do some more testing, next weekend.
== Rene
-----Original Message-----
From: Nikos Balkanas [mailto:[email protected]]
Sent: Monday, 23 August, 2010 03:07
To: Rene Kluwen; 'Hillel Bilman'
Cc: [email protected]
Subject: Re: smppbox bulk sms: slow reception from a client
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
