Memcached implementation inquiry

[marc at corky.net]

Hi,


mysql's scaling problem, especially on Linux, was recently found to be a 
sub-optimal implementation of malloc when it comes to threads.

If you preload google's malloc lib for mysqld you'll see a huge 
difference past ~1000 TPS allowing it to scale almost linearly as well.

Search for 'mysqld google malloc'


Lexington Luthor wrote:
> Steven Grimm wrote:
>> Try PostgreSQL instead. MySQL has awful concurrency problems. Much 
>> better in 5.x than it was in 4.x, but still not great.
>>
>
> I can confirm that PG is excellent at highly concurrent loads (> 1000 
> transactions), and I have read that it scales linearly to ~32 CPUs.
>
> > Michael Firsikov wrote:
> >> A typical complex search involves 5-10 tables, all properly indexed.
> >> (some
> >> tables have in excess of 12-15 million records) However, the
> >> concurrency is
> >> problematic (1000+ concurrent users).
>
> For this particular problem, memcache seems somewhat inappropriate, 
> and I think you will be better served by using postgresql and 
> materialized views updated by triggers or by cron depending on your 
> mix of reads/writes.
>
> I have a similar set-up where a particular view was being hit very 
> frequently and was too large to cache entirely. It consisted of a 
> complex query joining 14 tables, so materializing it was just perfect 
> for performance and subsets of the view can now be cached in memcached 
> without requiring the entire result-set to be regenerated every cache 
> miss.
>
> Regards,
> LL
>
>