Le vendredi 01 janvier 2010 à 14:08 +0100, Ivan Sergio Borgonovo a écrit :
Before just building my cache tables and build up my own cache system on top of cache API, is there an alternative approach?
You may turn off caching, turn on SQL logging for slow queries and study your SQL query log server-side in the SQL database. Find slow queries and fix them. Of course, this may not be possible if you are using a shared server without access to logs.
I wrote these guidelines if you are interested: http://drupal.org/node/559302
Most Drupal developers are writing PHP code and take advantage of Drupal caching system. The drawback is that we developers have no idea of the actual time that SQL queries take to run.
If you are running MySQL on a dedicated server, consider dropping MySQL because it is fairly slow. And look at PostgreSQL. when configured correctly, it can be faster than the caching system. But this is my own opinion, people with no SQL background may consider MySQL a nice tool just because it runs queries.
Two months ago, I agreed to work on MySQL for a Drupal project. When queries started to flow on the production server, I saw a number of red lines indicating that MySQL was not working fast enough and thus dropped transactions. When I migrated back from MySQL to PostgreSQL, some tables had duplicated entries, just because users had clicked several times on Submit button. I looked at MySQL table and they had unique indexes. This is what MySQL does: it is only a desaster. It can work for small sites, but when using large sites, you need a minimum of two servers, one for database, the other for MySQL. And you go beyond 1000 simultaneous users, you probably need a farm, which will ruin you.
Now my contracts have the "No MySQL" obligation. My opinion.
Kind regards and happy new year, Jean-Michel