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