Hi,
No issue at all. It is your decision, after all. But you have DLRs already
in a flat file, namely bb's access log. Why don't you just parse that one
with your cron job and save all the trouble of maintaining a web server just
for DLRs and writing the cgi script?
BR,
Nikos
----- Original Message -----
From: "abhishek jain" <[email protected]>
To: "Juan Nin" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, July 12, 2009 8:25 PM
Subject: Re: Urgent: limiting the http request for delivery reports.
Hi
With all your inputs, i have created on apache a CGI file which will
save the dlrs on a flat file and a cron script will update the mysql.
Does anyone sees an issue on this,
I mean saving to a disc rather on mysql directly.
Pl. advice,
Thanks
abhishek
On Sun, Jul 12, 2009 at 10:22 PM, Juan Nin<[email protected]> wrote:
Apart from being better options like lighthttpd for handling high
traffic, 50 requests/sec is VERY low for ANY web server.
If you're using Apache and you're not able to handle 50 requests/sec
then you got a very bad configured Apache installation (or a very low
end server)
If you're using MySQL < 5.1 to store the DLRs on InnoDB tables which
have an auto increment column it can really suck, since auto
increments on MySQL < 5.1 are very resource consuming and produce
locking. In theory MySQL 5.1 corrects this problem.
Hope this helps.
Regards
2009/7/12 Nikos Balkanas <[email protected]>:
Hi,
50 urls/s is very small. Fast webservers such as lighttpd or cherokee can
process >10,000 static pages/sec in an average dual box, without even
loading the CPU.
It would help if the webserver was in the same server as kannel, in that
it
eliminates network issues. Of course it is not a cure for badly written
code, or a very slow database implementation. If you are in doubt, turn
your
dlr-url to a static page in your webserver and bench that using fakesms.
Permanent DLR storage is not kannel's responsibility, but yours. To
answer
your question, it is the first time, in the last 8 months that I frequent
this group, that this question comes across. Mind you all DLRs are
perfectly
fine logged in bb's access log. You may not need a permanent external DLR
storage after all.
BR,
Nikos
----- Original Message ----- From: "Eduardo Raad"
<[email protected]>
To: "abhishek jain" <[email protected]>;
<[email protected]>; "Jinson" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, July 11, 2009 9:39 PM
Subject: Re: Urgent: limiting the http request for delivery reports.
You could use a memcache indeed, or a queue server such as rabbitmq.
These
operations are very fast. I believe you could handle 1000-2000
messages/second with a standard dual processor box with 4gb ram.
Test it out and see if it works for you.
Sent from my BlackBerry® wireless device
-----Original Message-----
From: abhishek jain <[email protected]>
Date: Sun, 12 Jul 2009 00:04:39
To: Jinson<[email protected]>
Cc: <[email protected]>
Subject: Re: Urgent: limiting the http request for delivery reports.
Hi all,
Even if i use Memcache or store in a flat file,i will be still calling
eg. approx 50 urls / http sessions in a second if the throughput is
the minimum, and this can bring the server to a halt i believe.
This does not solve,
I am sure I am not the first to have this kind of problem,
Pl. help.
thanks
abhishek
On Sat, Jul 11, 2009 at 2:30 PM, Jinson<[email protected]> wrote:
You can use memcache to store all your incoming DLRs and later process
it
from memcache..
Thanks
Jinson Abraham
MobME Wireless Solutions Pvt. Ltd
Cochin
+91 4846491646
On Sat, Jul 11, 2009 at 2:28 PM, Jovan Kostovski <[email protected]>
wrote:
On Sat, Jul 11, 2009 at 9:31 AM, abhishek
jain<[email protected]> wrote:
> Hi friends,
> I need a urgent reply,
> I have configured dlr to be internal and i specify the url in the
> XML
> Post,
> But if i send eg. 10,000 sms at one go, the kannel initiates 10,000
> different http requsts to my server for delivery reports i need to
> know is there a method to limit these http requests generated from
> kannel.
There is no way to limit the DLRs. They are received asynchronously
and you never
know when will you get them.
I guess you have problem handling all the DLRs due to their large
number.
There are two things that you can do:
1. Buffer the DLRs. Your DLR hanlder should just read the relevant
data and strore it somehere,
database or plain text file, and then you can process them whenever
you
want.
2. Setup more than one DLR hanlder. Create more instances of the DLR
handler and set dlr-urls
of the MT messages to be spread equally. For i.e. if you have 5 DLR
handlers and 10 MT messages
you set 1 sms to 1 dlr, 2 sms to 2 dlr....... 6 sms to 1 dlr
BR, Jovan
--
Thanks and kind Regards,
Abhishek jain
07799 328 727
skype: ejaincom
--
Juan Nin
3Cinteractive / Mobilizing Great Brands
http://www.3cinteractive.com
