Regarding this performance benchmarking. I still got memory problem. Kannel fails to release buffered or cached memory. Does anybody has tips to avoid this problem? Thanks.
sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 10, 2010, at 10:12 PM, Rene Kluwen wrote: > Why don’t you try it on your own system. Test with a MyIsam table and with > InnoDB. > It will be easy to determine which one works faster for you. > > == Rene > > From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of > brett skinner > Sent: Tuesday, 10 August, 2010 11:56 > To: Alejandro Guerrieri > Cc: Users > Subject: Re: Kannel performance benchmarking > > Thanks for your feedback. > > Guess it is the age old tao of computer science. Space vs Time, always space > vs time. :) > > Regards, > > On Tue, Aug 10, 2010 at 11:52 AM, Alejandro Guerrieri > <alejandro.guerri...@gmail.com> wrote: > Oh yes, I read that blog quite frequently :) There's a lot of stuff to say > about optimizing InnoDB, but it's definitely off-topic here and wouldn't fit > on a single email of course. > > We've gone thru a series of optimization cycles on our platform and, with > respect to Kannel, ended up using MyIsam for DLR's. We don't have any locking > issues, the only detail is we need to be careful when expiring old entries to > do it in small batches and not on peak hours. > > For the rest of our applications, except for small and mostly read-only > tables, we use InnoDB and while seems "slower" when you do a couple of > requests, it's a _lot_ faster if you are under heavy traffic because of the > row locking instead of table locking. > > Anyway, there's no a one-size-fits-all solution and if you really need to > sustain heavy traffic I'd recommend you do a lot of profiling and find the > bottlenecks either on the DB and the rest of your platform. > > Regards, > > Alex > > On Tue, Aug 10, 2010 at 11:15 AM, brett skinner <tatty.dishcl...@gmail.com> > wrote: > Hi Alex > > That is why I have chosen Innodb for the tables we use for the application > that surround Kannel. MyISAM definitely beat Innodb out the box but Innodb > does seem to be better in terms of the issues you have pointed out. The other > thing that I have read is that Innodb is incredibly slow with the stock > standard configuration. I read through the following blog and followed their > advice which increased its performance quite drastically. > > http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ > > If you have a moment you can give that a read. Or if you have any other good > references please send them a long. I am still rather new to MySql. Thanks :) > > Regards, > > > On Tue, Aug 10, 2010 at 10:56 AM, Alejandro Guerrieri > <alejandro.guerri...@gmail.com> wrote: > 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. us...@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 > > > >
