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" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: "Rapture" <[email protected]>; <[email protected]>
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" <[email protected]>
To: "'Cezary Siwek'" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, April 14, 2011 2:36 PM
Subject: RE: Slow RX incoming
Thanks Cezary, Will try that.
-----Original Message-----
From: Cezary Siwek [mailto:[email protected]]
Sent: Thursday, April 14, 2011 1:40 PM
To: Rapture
Cc: [email protected]
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: [email protected] [mailto:[email protected]] On
Behalf
Of Cezary Siwek
Sent: Thursday, April 14, 2011 1:03 PM
To: [email protected]
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:[email protected]]
Sent: Thursday, April 14, 2011 12:38 PM
To: Rapture; [email protected]
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: [email protected]
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
