So far I found the best option is the way it is already... as expected. But with some possible tweaks to max-pending-submits in group = smsc on the client.
== Rene -----Original Message----- From: Hillel [mailto:hbil...@ecommunicate.biz] Sent: Monday, 30 August, 2010 21:58 To: rene.klu...@chimit.nl Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Hi Rene, As regards your email below, did you have a chance this weekend to test which is the best option? Regards ---------------------------------------------------------------------- Date: Mon, 23 Aug 2010 14:22:46 +0200 From: "Rene Kluwen" <rene.klu...@chimit.nl> To: "'Nikos Balkanas'" <nbalka...@gmail.com>, "'Hillel Bilman'" <hbil...@ecommunicate.biz> Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Message-ID: <001c01cb42bd$e855a450$b900ec...@kluwen@chimit.nl> Content-Type: text/plain; charset="us-ascii" 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:nbalka...@gmail.com] Sent: Monday, 23 August, 2010 03:07 To: Rene Kluwen; 'Hillel Bilman' Cc: devel@kannel.org 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" <rene.klu...@chimit.nl> To: "'Nikos Balkanas'" <nbalka...@gmail.com>; "'Hillel Bilman'" <hbil...@ecommunicate.biz> Cc: <devel@kannel.org> 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:nbalka...@gmail.com] > Sent: Sunday, 22 August, 2010 23:25 > To: Rene Kluwen; 'Hillel Bilman' > Cc: devel@kannel.org > 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" <rene.klu...@chimit.nl> > To: "'Hillel Bilman'" <hbil...@ecommunicate.biz> > Cc: <devel@kannel.org> > 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:hbil...@ecommunicate.biz] >> Sent: Sunday, 22 August, 2010 18:59 >> To: rene.klu...@chimit.nl >> Cc: devel@kannel.org >> 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 >> >> >> >> > > >
