Thanks Juan, but definitely not bandwidth issue. Got 3Mb both ways uncontended, and it's working fine. Dave
On 3/15/08, Juan Nin <[EMAIL PROTECTED]> wrote: > > may it be your internet connection? > > what kind of connection do you have? > what available bandwidth? > > is it used only by kannel, or also by other services? > > > On Sat, Mar 15, 2008 at 10:16 AM, Dave Clarke <[EMAIL PROTECTED]> wrote: > > Just a follow up to say I feel I've ruled out the carrier connection. I > > routed everything through another bind, to a different carrier and still > > found 150 messages took 82 seconds. I know this is something very basic, > I'm > > just not seeing it. > > Dave > > > > > > On 3/15/08, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote: > > > Dave, > > > > > > It certainly looks like a bottleneck on the link, but there are so > many > > variables involved that it's quit difficult to pinpoint the problem > without > > a lot of analysis and tests. > > > > > > One more question: if you access the http interface on kannel, the > store > > and queued values gets higher and higher? Could you please post some > figures > > on what's showing on the admin interface? > > > > > > Regards, > > > > > > Alejandro > > > > > > > > > > > > On Fri, Mar 14, 2008 at 9:56 PM, Dave Clarke <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > Thanks for this Alejandro > > > > > > > > I'll look at trying the fake smsc. The carrier has given me a > > throughput of 50, and advised that I split this across 2 binds, which I > have > > done, setting the throughput figures at 25 and 25. I never see any > > throttling erors. > > > > > > > > The reason I set the max-pending-submits to 100 was that, with log > level > > 0, and max-pending-submits set to 10, I was able to see that I was only > > able to send 10 submit_sm, and would then have to wait for a > submit_sm_resp > > before I could submit another message. I thought that increasing to 100 > > would give me a better window, as sometimes my submit_sm_resp seem to > take > > forever. Maybe I need to talk to the carrier about the length of time it > > takes to get the submit_sm_resp back from them. > > > > > > > > Thank for your input. I think I'll open a ticket with the carrier in > > case it's simply a misconfig on their side. > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > On 3/15/08, Alejandro Guerrieri <[EMAIL PROTECTED]> > wrote: > > > > > Dave, > > > > > > > > > > I can't make a 100% accurate diagnostic without further tests, but > > looks like the bottleneck is on the links with the carrier. > > > > > > > > > > You can try using the fake smsc module instead of your links, and > > queue a fair amount of traffic. If the bottleneck is on those links, > you'll > > get much better performance when using the fake smsc. > > > > > > > > > > Probably, what it's happening is that the smsc is only accepting a > > small amount of traffic, and maybe you should lower the throughput > values to > > avoid retries and throttling on the other side. > > > > > > > > > > What I'd try: > > > > > > > > > > * Try reducing max-pending-submits to 10. Experiment with other > values > > also. 100 looks rather high imho. > > > > > * Check on your logfiles if there's any "throttling errors". > > > > > * Also ask your smsc what's the maximum accepted rate and set the > > thorughput value to that value. > > > > > > > > > > Hope it helps, > > > > > > > > > > Alejandro > > > > > > > > > > > > > > > > > > > > On Fri, Mar 14, 2008 at 9:14 PM, Dave Clarke <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Having used kannel for a couple of years, I am now at a point > where > > I need to start ramping up my throughput, but I am finding that I can't > > sustain any more than 2-3 messages a second through my 2x25 SMPP binds. > > > > > > > > > > > > If I walk through my application: > > > > > > > > > > > > - PHP/Apache/Postgresql application presents messages to > smsbox. On > > this occasion I try to send 2200 messages through. They are delivered to > > smsbox in blocks of 25 numbers. If I study smsbox.log, I see the entire > > process of passing the messages to smsbox takes 26 seconds. > > > > > > > > > > > > - smsbox then chops these up into individual messages and queues > > them. If I study smsbox-access.log, again I see all 2200 send-SMS > requests > > added in about 26 seconds. So far so good. > > > > > > > > > > > > - If I now go to access.log, I see that I'm taking 22 MINUTES to > do > > the 2200 transmits. > > > > > > > > > > > > Because this is so long, more customers come along with big > sends, > > and soon I have 10,000 messages queued and waiting. Result is a system > > churning through 2-3 messages per second. > > > > > > > > > > > > I'm guessing this is a simple matter of my not understanding the > > correct settings for my max-pendings etc. > > > > > > > > > > > > What I'm hoping is to kick off a slightly high-level discussion > on > > the factors I need to look at to achieve X messages per second, and > sustain > > this level of trafic before I get a snowball effect with queued messages > and > > a flood of DLRs. My thinking, which seems to have been wrong, was that > if I > > have a through put to SMSC of 50msgs per second, and an ACK takes say 3 > > seconds to come back, then I should handle 3x50=150 pending messages, so > I > > set max-pending-submits = 100 on both binds. Doesn't seem to have done > the > > trick. > > > > > > > > > > > > I'd appreciate any views or suggestions on how I scale this > thing. > > Let me know if you need more info. > > > > > > > > > > > > Thanks, > > > > > > Dave > > > > > > > > > > > > Points to note: > > > > > > - This is CVS today (20080314) > > > > > > - using file as store > > > > > > - All messages have DLR mask 31, so lots of DLRs coming in. > > > > > > - using mysql for dlrs > > > > > > - everything currently on a single Dual P4 IBM Netfinity, 4GB > RAM. > > Not cutting edge, but a good solid system, RAID array etc. > > > > > > > > > > > > Config: > > > > > > > > > > > > # CORE > > > > > > group = core > > > > > > admin-port = 13000 > > > > > > smsbox-port = 13001 > > > > > > admin-password = bar > > > > > > status-password = foo > > > > > > log-file = "/logs/kannel1/kannel.log" > > > > > > access-log = "/logs/kannel1/access.log" > > > > > > dlr-storage = mysql > > > > > > store-type = file > > > > > > store-location = "/logs/kannel1.store" > > > > > > log-level = 1 > > > > > > > > > > > > group = mysql-connection > > > > > > id = mydlr > > > > > > host = localhost > > > > > > username = xx > > > > > > password = xx > > > > > > database = kannel_dlr > > > > > > max-connections = 1 > > > > > > > > > > > > # SMSC SMPP A 1 > > > > > > group = smsc > > > > > > smsc = smpp > > > > > > smsc-id = smpp_A > > > > > > host = xxx > > > > > > port = 6700 > > > > > > receive-port = 6700 > > > > > > system-type = "" > > > > > > service-type = CMT > > > > > > dest-addr-ton = 1 > > > > > > dest-addr-npi = 1 > > > > > > enquire-link-interval = 60 > > > > > > address-range = "" > > > > > > throughput = 25 > > > > > > log-file = "/logs/kannel1/smppA1.log" > > > > > > log-level = 1 > > > > > > max-pending-submits = 100 > > > > > > > > > > > > # SMSC SMPP A 2 > > > > > > group = smsc > > > > > > smsc = smpp > > > > > > smsc-id = smpp_A > > > > > > host = xxx > > > > > > port = 6700 > > > > > > receive-port = 6700 > > > > > > system-type = "" > > > > > > service-type = CMT > > > > > > dest-addr-ton = 1 > > > > > > dest-addr-npi = 1 > > > > > > enquire-link-interval = 60 > > > > > > address-range = "" > > > > > > throughput = 25 > > > > > > log-file = "/logs/kannel1/smppA2.log" > > > > > > log-level = 1 > > > > > > max-pending-submits = 100 > > > > > > > > > > > > # SMSBOX SETUP > > > > > > group = smsbox > > > > > > bearerbox-host = localhost > > > > > > sendsms-port = 13013 > > > > > > smsbox-id = wtsmsbox > > > > > > sendsms-chars = "0123456789 +-" > > > > > > log-file = "/logs/kannel1/smsbox.log" > > > > > > log-level = 1 > > > > > > access-log = "/logs/kannel1/smsbox-access.log" > > > > > > mo-recode = 1 > > > > > > max-pending-requests = 1024 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >