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