RE: Kannel performance benchmarking
Are you using sqlbox for DLR storage? And do not relay to smsbox? Then this could very well be because of un-acked messages in the bearerbox queue. There’s a patch available for that. == Rene From: sangprabv [mailto:sangpr...@gmail.com] Sent: Tuesday, 10 August, 2010 23:21 To: Alejandro Guerrieri Cc: Rene Kluwen; brett skinner; Users Subject: Re: Kannel performance benchmarking Currently I apply bearerbox-sqlbox-smsbox and use mysql as my dlr engine. On Delll R710 Quadcore 2.2 Intel Xeon 16GB RAM it usually reduce to 5GB available memory in just 6 days and must be restarted to gain more memory. The server only used by Kannel. My daily traffics for that server is only 800 thousands MT/day. sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 10, 2010, at 10:53 PM, Alejandro Guerrieri wrote: Are you completely _sure_ that it's held by Kannel and not the underlying OS? Linux doesn't free unused memory unless needed by other processes. Also, if you have in-memory DLR's or a huge retry queue, it could consume lots of memory. Unless you get OOM errors, I wouldn't be concerned by the amount of memory being used. Regards, Alex On Tue, Aug 10, 2010 at 5:26 PM, sangprabv sangpr...@gmail.com wrote: 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 1-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
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
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@ -Original Message- From: brett skinner tatty.dishcl...@gmail.com Sender: users-boun...@kannel.org Date: Tue, 10 Aug 2010 10:13:54 To: Usersusers@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
Re: Kannel performance benchmarking
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 1-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: Usersusers@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
Re: Kannel performance benchmarking
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 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 1-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: Usersusers@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
Re: Kannel performance benchmarking
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 1-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: Usersusers@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
Re: Kannel performance benchmarking
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.comwrote: 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 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 1-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: Usersusers@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
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/ 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 1-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: Usersusers@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
RE: Kannel performance benchmarking
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 1-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: Usersusers@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
Re: Kannel performance benchmarking
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 1-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: Usersusers@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
Re: Kannel performance benchmarking
Are you completely _sure_ that it's held by Kannel and not the underlying OS? Linux doesn't free unused memory unless needed by other processes. Also, if you have in-memory DLR's or a huge retry queue, it could consume lots of memory. Unless you get OOM errors, I wouldn't be concerned by the amount of memory being used. Regards, Alex On Tue, Aug 10, 2010 at 5:26 PM, sangprabv sangpr...@gmail.com wrote: 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 1-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: Usersusers@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
RE: Kannel performance benchmarking
It would be interesting to use valgrind over a period over those 6 days. On all the boxes (bearerbox-sqlbox-smsbox). == Rene From: sangprabv [mailto:sangpr...@gmail.com] Sent: Tuesday, 10 August, 2010 23:21 To: Alejandro Guerrieri Cc: Rene Kluwen; brett skinner; Users Subject: Re: Kannel performance benchmarking Currently I apply bearerbox-sqlbox-smsbox and use mysql as my dlr engine. On Delll R710 Quadcore 2.2 Intel Xeon 16GB RAM it usually reduce to 5GB available memory in just 6 days and must be restarted to gain more memory. The server only used by Kannel. My daily traffics for that server is only 800 thousands MT/day. sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 10, 2010, at 10:53 PM, Alejandro Guerrieri wrote: Are you completely _sure_ that it's held by Kannel and not the underlying OS? Linux doesn't free unused memory unless needed by other processes. Also, if you have in-memory DLR's or a huge retry queue, it could consume lots of memory. Unless you get OOM errors, I wouldn't be concerned by the amount of memory being used. Regards, Alex On Tue, Aug 10, 2010 at 5:26 PM, sangprabv sangpr...@gmail.com wrote: 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 1-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
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
Re: Kannel performance benchmarking
Hi, Server was 64bit Ubuntu system, kernel 2.6.31-22. Dual core Xeon @3.4GHz. 4 GB RAM. MyIsam Mysql, with index on ts,smsc. You may have to adjust this if using latest svn with EMI or CIMD2 connections. Interestingly, SQLbox, performed the same as smsbox in MT with DB for DLRs. BR, Nikos - Original Message - From: brett skinner To: Nikos Balkanas Cc: ha...@aeon.pk ; kannel users Sent: Monday, August 09, 2010 5:42 PM Subject: Re: Kannel performance benchmarking 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
Re: Kannel performance benchmarking
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
Re: Kannel performance benchmarking
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
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
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
Re: Kannel performance benchmarking
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
