> The funny thing is, while in real production, the queries are not this > simple, in most web apps I make, the queries are really not all that > complicated. They do retrieve data from large data stores, but the SQL > itself is relatively straightforward. Besides, none of the web sites I > make are hosting thousands of hits a day. These are scientific web > sites, so even if the query is complicated, it being performed only a > few 10s, at the most 100s of times a day. > > After all this, it may well be that memcache may not be my immediate > step toward better speeds, nevertheless, it is a great concept worth > learning for me.
It's a great tool to have around when shit hits the fan. It's also great for random other things; like caching the results of multiple queries, of rendered page templates, of full pages renderings, etc. So if you compare 5 DB fetches (over the network! or at least not in-process) vs one memcached fetch, it might start looking better. But that's all moot, if your site is fast enough as is there's no point in working on it. If it's slow, profile why it's slow and cache or fix those queries.
