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 < [email protected]> 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 <[email protected] > > 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/ >> >> <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 < >> [email protected]> 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 <[email protected]> >>> >>>> 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: [email protected] >>>> To: brett skinner ; [email protected] ; >>>> [email protected]@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 <[email protected]> >>>> Sender: [email protected] >>>> Date: Tue, 10 Aug 2010 10:13:54 +0200 >>>> To: Users<[email protected]> >>>> 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 <[email protected]> >>>> >>>> Try valgrind in linux. >>>> >>>> BR, >>>> Nikos >>>> ----- Original Message ----- From: "sangprabv" <[email protected]> >>>> To: "Nikos Balkanas" <[email protected]> >>>> Cc: "brett skinner" <[email protected]>; "kannel users" < >>>> [email protected]> >>>> 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 >>>> [email protected] >>>> 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 >>>> [email protected] >>>> 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 <[email protected]> >>>> >>>> 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: [email protected] >>>> 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 >>>> >>> >>> >> >
