Because you were talking about very high number, I have assumed it was a MO rate, and not MT rate. What is your MT throughput?
On Mon, Jun 9, 2014 at 10:40 AM, spameden <[email protected]> wrote: > > > > 2014-06-09 17:08 GMT+04:00 Ahmed BOUDHRAA <[email protected]> > : > > HI >> thx for the relpay i was wondering if someone will help :) >> the fact is that we tunned the max-pending-requests and we ve concluded >> that about 800 is the best value and if we go up the results go worst, but >> the smsbox-max-pending we havent added such parametre; can you please >> explain it, is it, the smsbox-max-pending, is the queue between the smsbox >> and our portal? >> > > I can't imagine why do you need such high rate of sending MT messages for > university unless you're spamming your students every second .. > > The speed also very much depends on your SMSC upstream providers, network > link between you and them, TCP RTT (re-transmissions), etc. > > The general settings for throughput between you and smsc are: > > 1) throughput -- limits MT/sec > 2) max-pending-submits -- unofficial parameter, controls how many > "outstanding" operations between you and SMSC (e.g. unacknowledged > submit_sm packets) > > Try tuning these two parameters to get maximum of your upstream SMSC. Do > it carefully to not get THROTTLED errors or MAX_QUEUE errors. Consulting > your provider is highly recommended. > > > > > >> if i make it more simple: >> >> what is the difference between the tow variable that you gived to us : >> smsbox-max-pending >> and max-pending-requests ? and where are they placed, i mean if there is >> tow pending queue, i think one is in front of the bearerbox ( can i assume >> it is the max-pending-requests ?) and one between the bearerbox and the >> smsbox ? ( should it be the smsbox-max-pending ???) if my assumption are >> right i could be the bottleneck coz we havent touch such parametre, and if >> so the default value is about how much? >> > > check user-guide, it's available on the WEB: > http://kannel.org/download/kannel-userguide-snapshot/userguide.html > > bottleneck is most likely your code in DLR-url parsing script not the > kannel itself. > > try testing with different conditions: > > 1) without DLR reports at all > 2) with DLR but without your url hit > 3) with DLR and your URL > > Also, you might want to consider switching over to sqlbox, so you won't > need to drag web-server each time report comes. > > >> >> thinx again for the help >> >> >> >> ----- Mail Original ----- >> De: "DHC Admin" <[email protected]> >> À: "Ahmed BOUDHRAA" <[email protected]> >> Cc: [email protected] >> Envoyé: Lundi 9 Juin 2014 13:50:46 >> Objet: Re: Tunning up kannel >> >> >> Hi Ahmed >> Have you tweaked the smsbox-max-pending and/or max-pending-requests? >> Check for them on the user guide >> >> >> On Wed, Jun 4, 2014 at 11:33 AM, Ahmed BOUDHRAA < >> [email protected]> wrote: >> >>> Hi >>> we are using kannel about 2 years in our institution and its woriking >>> like a charm. we have high load traffic with 3 operators with 3 kannel >>> gatways, our configuration is like this: >>> >>> - kannel 1 : Operator 1 : VM 2 x CPU 3 Ghz 8 Go Ram >>> - kannel 2 : Operator 2 : VM 2 x CPU 3 Ghz 8 Go Ram >>> - kannel 3 : Operator 3 : VM 2 x CPU 3 Ghz 8 Go Ram >>> - Web Portal: for all kannel : VM 8 x CPU 3 Ghz 32 Go RAM >>> - Postgres Database behind the web server : VM 8 x CPU 3 Ghz 32 Go RAM >>> >>> All those server are running under ESXi hypervisor in SAN environnement. >>> Any way we are tunning all the plateform with several tools ( ApacheBench >>> for web load and fakesms for kannel) >>> we want to profit of all the hardware ressources with optimizing all >>> componenents to reach the limits of the hardware, but still are still far >>> behind the real capability of the hardware. >>> The fact is we have reached 800 sms /s with the operators and its fine, >>> but we want more not that we need it right now but just to master how every >>> things work... >>> The WEB/DB side tunning is "well" done due to fact that we have >>> "mastered" it in our webs servers but the kannel side is litle different. >>> with fakesms we are sending about 1000 sms / s from each kannel so we want >>> to manage 3000 sms / s in our portal but all the kannel dosent send them >>> with the speed we want even if they are not even litle solicited, we >>> noticed that the bottle neck is between the smsbox and the bearerbox we >>> dont know exactly but all 1000 sms arrive instantelly to the bearerbox in >>> each kannel and a queue is formed between the bearerbox and smsbox, the >>> smsbox send to the web server ( the portal ) about 1200 request / s wich is >>> far from his limit ( we have tunning it to manage 3500 request / s ) I ve >>> talked a lot but the main question is how we remove that so called queue >>> smsbox/bearebox? to make the kannels send more than 1200 request/s so we >>> can reach the limits in all the equippements all the system is running far >>> behind his capabilitys. >>> thinx for the help >>> >> >> >
