Re: smppbox bulk sms: slow reception from a client

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
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>