Memcached implementation inquiry

[Lexington Luthor]

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