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
>

Reply via email to