Well, if it weren't for the SELECT COUNT(*) slowness would be my preferred option here as well. Despite seeming "slower" at first (specially on small tables) InnoDB performs row-locking on index-based queries, which indeed improves things quite a bit on big tables with lots of simultaneous reads and writes.
Regards, Alex 2010/8/10 Nikos Balkanas <nbalka...@gmail.com> > Indeed. InnoDB is much slower overall compared to MyIsam. However, it has > its use for some jobs (archive_logs, hot backups, etc.) > > The figures I gave were sustained rates simulated with a 10000-SMS batch. > Count was sufficient to reach sustainability and reproducibility, yet short > enough to get results fast. > > When i submitted fakesmpp, I also released similar data from a 64bit > Solaris 10 server. > > BR, > Nikos > ----- Original Message ----- From: alejandro.guerri...@gmail.com > To: brett skinner ; users-boun...@kannel.org ; us...@kannel. Users@Kannel.Org > Sent: Tuesday, August 10, 2010 11:21 AM > > Subject: Re: Kannel performance benchmarking > > > Brett, > > The DLR engine uses SELECT COUNT(*) from the admin interface, which is > painfully slow on InnoDB for moderately big tables. > > While InnoDB would theoretically be the best option, MyIsam performs quite > better in this case. > > Regards, > > Alex > BlackBerry de movistar, allν donde estιs estα tu oficin@ > > > > > From: brett skinner <tatty.dishcl...@gmail.com> > Sender: users-boun...@kannel.org > Date: Tue, 10 Aug 2010 10:13:54 +0200 > To: Users<users@kannel.org> > Subject: Re: Kannel performance benchmarking > > > Hi Nikos > > > Thanks for the extra information. What was the motivation for using MyISAM? > My reading lead me to believe that MyISAM was not that well suited for > interleaved reads and writes due to table locking which is why I opted to > use InnoDB. From what I assumed about how Kannel worked is that > reading/writing to the DLR table would be interleaved. I may be quite badly > mistaken and might perhaps need to switch to MyISAM as a few others have > recommended. > > > In your opinion what should Kannel be able to handle sustained (assuming > normal business hours)? And what should Kannel be able to burst to? I know > some of these questions are a bit like how long is a piece of string but I > really do value all and any of your feedback. > > > Regards, > > > 2010/8/10 Nikos Balkanas <nbalka...@gmail.com> > > Try valgrind in linux. > > BR, > Nikos > ----- Original Message ----- From: "sangprabv" <sangpr...@gmail.com> > To: "Nikos Balkanas" <nbalka...@gmail.com> > Cc: "brett skinner" <tatty.dishcl...@gmail.com>; "kannel users" < > users@kannel.org> > Sent: Tuesday, August 10, 2010 3:35 AM > > Subject: Re: Kannel performance benchmarking > > > Yeah I understand that. But when the there is no traffic. Kannel doesn't > release the cached or buffered memory it used. Do you have any solution? > What command to list down or trace the memory usage by Kannel? So maybe we > can investigate which function or module in Kannel is eating the memory. > Thanks > > > > > sangprabv > sangpr...@gmail.com > http://www.petitiononline.com/froyo/ > > > On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote: > > > No memory problems. It is reasonable that kannel will use more memory in > higher traffic, since all queues are in memory, as long as it drops to > nominal levels once the traffic is gone. > > BR, > Nikos > ----- Original Message ----- From: sangprabv > To: brett skinner > Cc: Nikos Balkanas ; kannel users > Sent: Monday, August 09, 2010 5:59 PM > Subject: Re: Kannel performance benchmarking > > > Hi Nikos, > Do you experience memory problem? In my case Kannel is eating the memory on > high load traffics. I always need to restart the box to get more memory. I > even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( > > > > > > > sangprabv > sangpr...@gmail.com > http://www.petitiononline.com/froyo/ > > > > > On Aug 9, 2010, at 9:42 PM, brett skinner wrote: > > > Hi Nikos > > Out of curiosity can you go into more detail regarding what hardware you > were running and your setup for MySql? Were you using Innodb or MyIsam. If > you were using Innodb did you make any other configuration changes to MySql > to accommodate Innodb. > > From the user guide it is implied that the bottle neck for Kannel is the > number of messages that the SMSC can accommodate per second. Is this still > the case? > > Regards, > > > 2010/8/8 Nikos Balkanas <nbalka...@gmail.com> > > Hi, > > I have run some benchmarking for a client using fakesmpp. Using the default > service for MO's I got: > > MO's: 1400 SMS/s > MT + DLRs (internal): 747 SMS/s > MT + DLRs (MySql): 434 SMS/s > > BR, > Nikos > ----- Original Message ----- From: ha...@aeon.pk > To: kannel users > Sent: Sunday, August 08, 2010 4:22 PM > Subject: Kannel performance benchmarking > > > > Hi, > > > I am interested to know about the kannel performance benchmarking, > especially in terms of speed (msgs/sec), MO or MT. I assume that multiple > smsboxes does not have any effect over kannel performance, since the > front-end talking to SMSC is the main bearerbox. What is the max speed that > could be attained by kannel and/or bearerbox? > > > Regards, > > > Hamza >