RE: Slow RX incoming
Thanks Will try this From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 3:52 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming You can do a packet trace using tcpdump: sudo tcpdump -s 65000 -w kannel_trace.pcap host and port You can then open it with ethereal. Hope it helps, Alex On Fri, Apr 15, 2011 at 2:51 PM, Rapture wrote: Regular Kannel. I'm not familiar with a packet trace or zero win errors. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 3:47 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Make a packet trace and check if you get "zero win" errors. If you get tons of DLR's and your DB is not fast enough that would explain the problem. Art you using a "regular" Kannel or did you apply any patches to it? Regards, Alex On Fri, Apr 15, 2011 at 2:35 PM, Rapture wrote: Hi Alex, The issue is persistent but all has been well till about 3 weeks ago when I started receiving huge bursts of messages. DLR is enabled and DB is ok as other application is working properly. Regards, Rapture From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 12:14 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Is the issue constant, or only happens at some specific times during the day? Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're getting lots of them? Perhaps a long shot, but might be worth checking: try doing a packet trace and verify you're not getting TCP "zero win" errors. Regards, Alex On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Re: Slow RX incoming
You can do a packet trace using tcpdump: sudo tcpdump -s 65000 -w kannel_trace.pcap host and port You can then open it with ethereal. Hope it helps, Alex On Fri, Apr 15, 2011 at 2:51 PM, Rapture wrote: > Regular Kannel. > > > > I’m not familiar with a packet trace or zero win errors… > > > > *From:* Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] > *Sent:* Friday, April 15, 2011 3:47 PM > > *To:* Rapture > *Cc:* users@kannel.org > *Subject:* Re: Slow RX incoming > > > > Make a packet trace and check if you get "zero win" errors. If you get tons > of DLR's and your DB is not fast enough that would explain the problem. > > > > Art you using a "regular" Kannel or did you apply any patches to it? > > > > Regards, > > > > Alex > > On Fri, Apr 15, 2011 at 2:35 PM, Rapture wrote: > > Hi Alex, > > > > The issue is persistent but all has been well till about 3 weeks ago when I > started receiving huge bursts of messages. DLR is enabled and DB is ok as > other application is working properly. > > > Regards, > > > > Rapture > > > > *From:* Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] > *Sent:* Friday, April 15, 2011 12:14 PM > > > *To:* Rapture > *Cc:* users@kannel.org > *Subject:* Re: Slow RX incoming > > > > Is the issue constant, or only happens at some specific times during the > day? > > > > Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're > getting lots of them? > > > > Perhaps a long shot, but might be worth checking: try doing a packet trace > and verify you're not getting TCP "zero win" errors. > > > > Regards, > > > > Alex > > On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: > > Hi guys, > > > > We’ve been running a campaign averaging 350,000 messages a day. Lately I > noticed kannel does not retrieve them as fast as it needs to hence a > backlog builds on the operator’s end. This is only affecting one of the > operators. On calling them, they insisted that it is Kannel which determines > how many RX messages to pull. I tried an old SMPP client software I’d > written in Delphi and it cleared all the backlog in less than 5 mins and > continues to do so in real time. All data is dumped into the same mysql > table. I’ve tried using throughput in kannel with no success. I’ve even > opened upto 15 channels to the same operator without success. > > > > What could be the issue? How can I speed up my intake of messages? > > > > Distraught, > > > > TR > > > > > > > > >
RE: Slow RX incoming
Regular Kannel. I'm not familiar with a packet trace or zero win errors. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 3:47 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Make a packet trace and check if you get "zero win" errors. If you get tons of DLR's and your DB is not fast enough that would explain the problem. Art you using a "regular" Kannel or did you apply any patches to it? Regards, Alex On Fri, Apr 15, 2011 at 2:35 PM, Rapture wrote: Hi Alex, The issue is persistent but all has been well till about 3 weeks ago when I started receiving huge bursts of messages. DLR is enabled and DB is ok as other application is working properly. Regards, Rapture From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 12:14 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Is the issue constant, or only happens at some specific times during the day? Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're getting lots of them? Perhaps a long shot, but might be worth checking: try doing a packet trace and verify you're not getting TCP "zero win" errors. Regards, Alex On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Re: Slow RX incoming
Make a packet trace and check if you get "zero win" errors. If you get tons of DLR's and your DB is not fast enough that would explain the problem. Art you using a "regular" Kannel or did you apply any patches to it? Regards, Alex On Fri, Apr 15, 2011 at 2:35 PM, Rapture wrote: > Hi Alex, > > > > The issue is persistent but all has been well till about 3 weeks ago when I > started receiving huge bursts of messages. DLR is enabled and DB is ok as > other application is working properly. > > > Regards, > > > > Rapture > > > > *From:* Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] > *Sent:* Friday, April 15, 2011 12:14 PM > > *To:* Rapture > *Cc:* users@kannel.org > *Subject:* Re: Slow RX incoming > > > > Is the issue constant, or only happens at some specific times during the > day? > > > > Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're > getting lots of them? > > > > Perhaps a long shot, but might be worth checking: try doing a packet trace > and verify you're not getting TCP "zero win" errors. > > > > Regards, > > > > Alex > > On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: > > Hi guys, > > > > We’ve been running a campaign averaging 350,000 messages a day. Lately I > noticed kannel does not retrieve them as fast as it needs to hence a > backlog builds on the operator’s end. This is only affecting one of the > operators. On calling them, they insisted that it is Kannel which determines > how many RX messages to pull. I tried an old SMPP client software I’d > written in Delphi and it cleared all the backlog in less than 5 mins and > continues to do so in real time. All data is dumped into the same mysql > table. I’ve tried using throughput in kannel with no success. I’ve even > opened upto 15 channels to the same operator without success. > > > > What could be the issue? How can I speed up my intake of messages? > > > > Distraught, > > > > TR > > > > > > >
RE: Slow RX incoming
Hi Alex, The issue is persistent but all has been well till about 3 weeks ago when I started receiving huge bursts of messages. DLR is enabled and DB is ok as other application is working properly. Regards, Rapture From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, April 15, 2011 12:14 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Is the issue constant, or only happens at some specific times during the day? Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're getting lots of them? Perhaps a long shot, but might be worth checking: try doing a packet trace and verify you're not getting TCP "zero win" errors. Regards, Alex On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Re: Slow RX incoming
Is the issue constant, or only happens at some specific times during the day? Do you have DLR's enabled? DB-backed? Maybe the issue happens when you're getting lots of them? Perhaps a long shot, but might be worth checking: try doing a packet trace and verify you're not getting TCP "zero win" errors. Regards, Alex On Thu, Apr 14, 2011 at 7:27 AM, Rapture wrote: > Hi guys, > > > > We’ve been running a campaign averaging 350,000 messages a day. Lately I > noticed kannel does not retrieve them as fast as it needs to hence a > backlog builds on the operator’s end. This is only affecting one of the > operators. On calling them, they insisted that it is Kannel which determines > how many RX messages to pull. I tried an old SMPP client software I’d > written in Delphi and it cleared all the backlog in less than 5 mins and > continues to do so in real time. All data is dumped into the same mysql > table. I’ve tried using throughput in kannel with no success. I’ve even > opened upto 15 channels to the same operator without success. > > > > What could be the issue? How can I speed up my intake of messages? > > > > Distraught, > > > > TR > > > > >
Re: Slow RX incoming
Hi Cezary, What you describe is very hard to happen. The only server resources that could be limiting would be sockets, in which case Solaris freezes for 30" or so, and linux reboots (I think) or not responding to SMSc's writes, in which case there would be a lot of timeout errors on the SMSc side. Getting a lot of timeout errors on the SMSc is easy to check with them. Besides it is very unusual, since the code in bearerbox is very light and efficient, at this point. It just puts MOs in input queue and returns for more. The MO is cleared from the SMSc and processing can happen at any time later, building only the internal queue. I am not saying that it is not an application error, especially if you have prior experience, but there are a lot of other things to check before getting there. The mechanism I just described, precludes any case other than a hard server-wide error from being a problem. A top or server log (messages) during the incident should resolve that. BR, Nikos - Original Message - From: "Cezary Siwek" To: "Nikos Balkanas" Cc: "Rapture" ; Sent: Thursday, April 14, 2011 6:25 PM Subject: Re: Slow RX incoming Nikos, You are right if we are talking only about kannel's behavior. Bear in mind that kannel have to create thousands http requests. many of them will be hanging and waiting to be processed by http server. Also, if http and mysql server coexist on the same machine that is going to consume all the system resources which will dramatically slow down the kannel. BR, Cezary On 14/04/2011 15:29, Nikos Balkanas wrote: Hi, I don't think that this will solve your problem. If it were an application issue, it would build up kannel's queue, not the SMSc's. SMSc's queue can build up only from dropped connections. These would be shown in your bearerbox logs. Sorry, Cezary. BR, Nikos - Original Message - From: "Rapture" To: "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 2:36 PM Subject: RE: Slow RX incoming Thanks Cezary, Will try that. -Original Message- From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] Sent: Thursday, April 14, 2011 1:40 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On ca
Re: Slow RX incoming
As mentioned before, this is a known, old, kannel issue with Rx/Tx connections.1 of the 2 goes down, while enquire pdus are still received from the other. Kannel normally will restart connections when they go down, but since it still receives enquires from the other link, it thinks that connection is back online and aborts. Look for connection problems in maximum detail bearerbox logs. BR, Nikos - Original Message - From: "Rapture" To: "'Nikos Balkanas'" ; "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 5:38 PM Subject: RE: Slow RX incoming What would be the issue Nikos? -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 5:29 PM To: Rapture; 'Cezary Siwek' Cc: us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, I don't think that this will solve your problem. If it were an application issue, it would build up kannel's queue, not the SMSc's. SMSc's queue can build up only from dropped connections. These would be shown in your bearerbox logs. Sorry, Cezary. BR, Nikos - Original Message - From: "Rapture" To: "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 2:36 PM Subject: RE: Slow RX incoming Thanks Cezary, Will try that. -Original Message- From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] Sent: Thursday, April 14, 2011 1:40 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message----- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Re: Slow RX incoming
Nikos, You are right if we are talking only about kannel's behavior. Bear in mind that kannel have to create thousands http requests. many of them will be hanging and waiting to be processed by http server. Also, if http and mysql server coexist on the same machine that is going to consume all the system resources which will dramatically slow down the kannel. BR, Cezary On 14/04/2011 15:29, Nikos Balkanas wrote: Hi, I don't think that this will solve your problem. If it were an application issue, it would build up kannel's queue, not the SMSc's. SMSc's queue can build up only from dropped connections. These would be shown in your bearerbox logs. Sorry, Cezary. BR, Nikos - Original Message - From: "Rapture" To: "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 2:36 PM Subject: RE: Slow RX incoming Thanks Cezary, Will try that. -Original Message- From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] Sent: Thursday, April 14, 2011 1:40 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
RE: Slow RX incoming
What would be the issue Nikos? -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 5:29 PM To: Rapture; 'Cezary Siwek' Cc: us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, I don't think that this will solve your problem. If it were an application issue, it would build up kannel's queue, not the SMSc's. SMSc's queue can build up only from dropped connections. These would be shown in your bearerbox logs. Sorry, Cezary. BR, Nikos - Original Message - From: "Rapture" To: "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 2:36 PM Subject: RE: Slow RX incoming > Thanks Cezary, Will try that. > > -Original Message- > From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] > Sent: Thursday, April 14, 2011 1:40 PM > To: Rapture > Cc: users@kannel.org > Subject: Re: Slow RX incoming > > Ok, that makes it more clear. > From my experience I can say that kannel->xttpd->php->mysql way alsways > makes some problems if is designed in wrong way. > How do you run your php script under http server? Run it using fastcgi > and keep persistent connection with the DB. Don't share the db > connection across fastcgi processes - use one connection per fastcgi > process. > > Your delphi application does it, right? > > My application written in Perl, running under lighttpd in fastcgi (with > 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. > > BR, > Cezary > > > > > On 14/04/2011 11:25, Rapture wrote: >> All MOs are stored via a php script to the same mysql table for incoming >> messages. This is the same table I use for the inhouse app. >> >> -Original Message- >> From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On >> Behalf >> Of Cezary Siwek >> Sent: Thursday, April 14, 2011 1:03 PM >> To: users@kannel.org >> Subject: Re: Slow RX incoming >> >> Hi, >> >> How do you store MO messages? Maybe there is a bottleneck? >> >> BR, >> Cezary >> >> >> On 14/04/2011 11:00, Rapture wrote: >>> Hi Nikos, >>> >>> I'm referring to MO traffic. It only affects incoming SMS. We run > separate >>> TX and RX and operator does not offer transceiver mode. We don't have >>> any >>> logs that indicate slow speed, though traffics backs up at operator's > end. >>> When I call them, they insist that it is my application that is not >>> 'picking' messages fast enough from their SMSC. Funny thing is the > inhouse >>> app clears the messages in a heartbit. >>> >>> -Original Message- >>> From: Nikos Balkanas [mailto:nbalka...@gmail.com] >>> Sent: Thursday, April 14, 2011 12:38 PM >>> To: Rapture; us...@vm1.kannel.org >>> Subject: Re: Slow RX incoming >>> >>> Hi, >>> >>> Kannel doesn't "retrieve" SMS from the operator. Operator sends them to >>> kannel. Throughput doesn't affect incoming traffic, only outgoing and >>> not >>> *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is > difficult >>> to help you without any kind of logs. Since there is back log at your >>> operator, what do his logs say? >>> >>> There is an issue with separate Tx/Rx connections in kannel. If only 1 >>> of >>> the 2 drops, while the other is working, kannel doesn't realize it to >>> reconnect both ends. You might try transceiver mode for that. >>> >>> BR, >>> Nikos >>> - Original Message - >>> From: Rapture >>> To: users@kannel.org >>> Sent: Thursday, April 14, 2011 8:27 AM >>> Subject: Slow RX incoming >>> >>> >>> Hi guys, >>> >>> We've been running a campaign averaging 350,000 messages a day. Lately I >>> noticed kannel does not retrieve them as fast as it needs to hence a >>> backlog builds on the operator's end. This is only affecting one of the >>> operators. On calling them, they insisted that it is Kannel which >> determines >>> how many RX messages to pull. I tried an old SMPP client software I'd >>> written in Delphi and it cleared all the backlog in less than 5 mins and >>> continues to do so in real time. All data is dumped into the same mysql >>> table. I've tried using throughput in kannel with no success. I've even >>> opened upto 15 channels to the same operator without success. >>> >>> What could be the issue? How can I speed up my intake of messages? >>> >>> Distraught, >>> >>> TR >>> >>> >>> >>> > >
Re: Slow RX incoming
Hi, I don't think that this will solve your problem. If it were an application issue, it would build up kannel's queue, not the SMSc's. SMSc's queue can build up only from dropped connections. These would be shown in your bearerbox logs. Sorry, Cezary. BR, Nikos - Original Message - From: "Rapture" To: "'Cezary Siwek'" Cc: Sent: Thursday, April 14, 2011 2:36 PM Subject: RE: Slow RX incoming Thanks Cezary, Will try that. -Original Message- From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] Sent: Thursday, April 14, 2011 1:40 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos ----- Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
RE: Slow RX incoming
Thanks Cezary, Will try that. -Original Message- From: Cezary Siwek [mailto:cza...@thebestisp.co.uk] Sent: Thursday, April 14, 2011 1:40 PM To: Rapture Cc: users@kannel.org Subject: Re: Slow RX incoming Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: > All MOs are stored via a php script to the same mysql table for incoming > messages. This is the same table I use for the inhouse app. > > -Original Message- > From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf > Of Cezary Siwek > Sent: Thursday, April 14, 2011 1:03 PM > To: users@kannel.org > Subject: Re: Slow RX incoming > > Hi, > > How do you store MO messages? Maybe there is a bottleneck? > > BR, > Cezary > > > On 14/04/2011 11:00, Rapture wrote: >> Hi Nikos, >> >> I'm referring to MO traffic. It only affects incoming SMS. We run separate >> TX and RX and operator does not offer transceiver mode. We don't have any >> logs that indicate slow speed, though traffics backs up at operator's end. >> When I call them, they insist that it is my application that is not >> 'picking' messages fast enough from their SMSC. Funny thing is the inhouse >> app clears the messages in a heartbit. >> >> -Original Message----- >> From: Nikos Balkanas [mailto:nbalka...@gmail.com] >> Sent: Thursday, April 14, 2011 12:38 PM >> To: Rapture; us...@vm1.kannel.org >> Subject: Re: Slow RX incoming >> >> Hi, >> >> Kannel doesn't "retrieve" SMS from the operator. Operator sends them to >> kannel. Throughput doesn't affect incoming traffic, only outgoing and not >> *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult >> to help you without any kind of logs. Since there is back log at your >> operator, what do his logs say? >> >> There is an issue with separate Tx/Rx connections in kannel. If only 1 of >> the 2 drops, while the other is working, kannel doesn't realize it to >> reconnect both ends. You might try transceiver mode for that. >> >> BR, >> Nikos >> - Original Message - >> From: Rapture >> To: users@kannel.org >> Sent: Thursday, April 14, 2011 8:27 AM >> Subject: Slow RX incoming >> >> >> Hi guys, >> >> We've been running a campaign averaging 350,000 messages a day. Lately I >> noticed kannel does not retrieve them as fast as it needs to hence a >> backlog builds on the operator's end. This is only affecting one of the >> operators. On calling them, they insisted that it is Kannel which > determines >> how many RX messages to pull. I tried an old SMPP client software I'd >> written in Delphi and it cleared all the backlog in less than 5 mins and >> continues to do so in real time. All data is dumped into the same mysql >> table. I've tried using throughput in kannel with no success. I've even >> opened upto 15 channels to the same operator without success. >> >> What could be the issue? How can I speed up my intake of messages? >> >> Distraught, >> >> TR >> >> >> >>
Re: Slow RX incoming
Ok, that makes it more clear. From my experience I can say that kannel->xttpd->php->mysql way alsways makes some problems if is designed in wrong way. How do you run your php script under http server? Run it using fastcgi and keep persistent connection with the DB. Don't share the db connection across fastcgi processes - use one connection per fastcgi process. Your delphi application does it, right? My application written in Perl, running under lighttpd in fastcgi (with 5-10 concurrent processes) mode can easly handle 150sms/s on one machine. BR, Cezary On 14/04/2011 11:25, Rapture wrote: All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
RE: Slow RX incoming
All MOs are stored via a php script to the same mysql table for incoming messages. This is the same table I use for the inhouse app. -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Cezary Siwek Sent: Thursday, April 14, 2011 1:03 PM To: users@kannel.org Subject: Re: Slow RX incoming Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: > Hi Nikos, > > I'm referring to MO traffic. It only affects incoming SMS. We run separate > TX and RX and operator does not offer transceiver mode. We don't have any > logs that indicate slow speed, though traffics backs up at operator's end. > When I call them, they insist that it is my application that is not > 'picking' messages fast enough from their SMSC. Funny thing is the inhouse > app clears the messages in a heartbit. > > -Original Message- > From: Nikos Balkanas [mailto:nbalka...@gmail.com] > Sent: Thursday, April 14, 2011 12:38 PM > To: Rapture; us...@vm1.kannel.org > Subject: Re: Slow RX incoming > > Hi, > > Kannel doesn't "retrieve" SMS from the operator. Operator sends them to > kannel. Throughput doesn't affect incoming traffic, only outgoing and not > *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult > to help you without any kind of logs. Since there is back log at your > operator, what do his logs say? > > There is an issue with separate Tx/Rx connections in kannel. If only 1 of > the 2 drops, while the other is working, kannel doesn't realize it to > reconnect both ends. You might try transceiver mode for that. > > BR, > Nikos > - Original Message - > From: Rapture > To: users@kannel.org > Sent: Thursday, April 14, 2011 8:27 AM > Subject: Slow RX incoming > > > Hi guys, > > We've been running a campaign averaging 350,000 messages a day. Lately I > noticed kannel does not retrieve them as fast as it needs to hence a > backlog builds on the operator's end. This is only affecting one of the > operators. On calling them, they insisted that it is Kannel which determines > > how many RX messages to pull. I tried an old SMPP client software I'd > written in Delphi and it cleared all the backlog in less than 5 mins and > continues to do so in real time. All data is dumped into the same mysql > table. I've tried using throughput in kannel with no success. I've even > opened upto 15 channels to the same operator without success. > > What could be the issue? How can I speed up my intake of messages? > > Distraught, > > TR > > > >
Re: Slow RX incoming
Hi, How do you store MO messages? Maybe there is a bottleneck? BR, Cezary On 14/04/2011 11:00, Rapture wrote: Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
RE: Slow RX incoming
Hi Nikos, I'm referring to MO traffic. It only affects incoming SMS. We run separate TX and RX and operator does not offer transceiver mode. We don't have any logs that indicate slow speed, though traffics backs up at operator's end. When I call them, they insist that it is my application that is not 'picking' messages fast enough from their SMSC. Funny thing is the inhouse app clears the messages in a heartbit. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Thursday, April 14, 2011 12:38 PM To: Rapture; us...@vm1.kannel.org Subject: Re: Slow RX incoming Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Re: Slow RX incoming
Hi, Kannel doesn't "retrieve" SMS from the operator. Operator sends them to kannel. Throughput doesn't affect incoming traffic, only outgoing and not *_resp pdus. Are you referring to MO traffic or MT (DLRs)? It is difficult to help you without any kind of logs. Since there is back log at your operator, what do his logs say? There is an issue with separate Tx/Rx connections in kannel. If only 1 of the 2 drops, while the other is working, kannel doesn't realize it to reconnect both ends. You might try transceiver mode for that. BR, Nikos - Original Message - From: Rapture To: users@kannel.org Sent: Thursday, April 14, 2011 8:27 AM Subject: Slow RX incoming Hi guys, We’ve been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator’s end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I’d written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I’ve tried using throughput in kannel with no success. I’ve even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
Slow RX incoming
Hi guys, We've been running a campaign averaging 350,000 messages a day. Lately I noticed kannel does not retrieve them as fast as it needs to hence a backlog builds on the operator's end. This is only affecting one of the operators. On calling them, they insisted that it is Kannel which determines how many RX messages to pull. I tried an old SMPP client software I'd written in Delphi and it cleared all the backlog in less than 5 mins and continues to do so in real time. All data is dumped into the same mysql table. I've tried using throughput in kannel with no success. I've even opened upto 15 channels to the same operator without success. What could be the issue? How can I speed up my intake of messages? Distraught, TR
