Fredrik Noring wrote:
>9 jan 2009 kl. 11.01 skrev Stephen R. van den Berg:
>>The MySQL query cache is useful if one has queries with longer than
>>trivial runtimes and comparatively small resultsets. The way Roxen
>>uses the local MySQL database, this never happens. The queries:
>We have some (internal) applications that do a fair amount of queries
>(10-100 per minute), where we do complex JOIN:s on 10+ tables. The
>result sets are usually a couple of hundred rows, and the main issue
>with "too much effort" to cache elsewhere is simply that the table
>dependencies are complicated (by these JOIN:s), which makes it a win
>to have the database handle dependency tracking and caching. (That's
>what a database is good for, right?)
I see. Well, that would be an excellent case to utilise the query-cache.
However, I would have assumed that those kinds of datastructures are
better off in a separate database (either a separate MySQL tuned for
your application, or a separate PostgreSQL database; both possibly on
the same hardware, or, if load dictates such, even on another machine).
I tend to view the integrated MySQL server in Roxen as mostly and merely
a hash-table on steroids, and therefore never use it in my apps. The way
Roxen uses it, and the way my applications use databases differ enough
to warrant separate tuning (in order not to step on each other's caches).
But, I now realise that quite a sizeable number of people actually do
(ab)use the integrated MySQL server as an application database; which
obviously makes that this setting should be exposed to the webadministrator.
--
Sincerely,
Stephen R. van den Berg.
Every successful person has had failures but repeated failure is no
guarantee of eventual success.
|