Re[2]: [PEAR-DEV] cmysql (was: Package proposal)
| From: | Maxim Antipin | Date: | Tue, 12 Oct 2004 07:32:07 +0000 |
| Subject: | Re[2]: [PEAR-DEV] cmysql (was: Package proposal) | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-33787@lists.php.net to get a copy of this message | ||
Hello Mika,
Tuesday, October 12, 2004, 2:16:14 PM, you wrote:
>> 2. By default caching mechanism is turned off as default value
>> 'query_cache_size' is '0' so it depends on hoster wether cache is
>> actually enabled or not. Even if cache is enabled developer needs to
>> modify SQL queries:
>> a) SET SESSION query_cache_type = DEMAND - to allow caching only
>> explicitly defined by 'SELECT SQL_CACHE' prefix queries.
>> b) Add 'SQL_CACHE' to all required queries. This will results in
>> problems with SQL syntax for MySQL 3.xx.xx
MT> ... must disagree with this one. query_cache_type defaults
MT> to ON. Once query_cache_size is set above zero the caching
MT> just magically starts to work. No need to modify any queries
MT> unless you yourself set or administrator has explicitly set
MT> the query_cache_type to DEMAND.
Yes it is so, but it is the worst case when we hope to get fruits of
built in MySQL cache on hosting server. As i told queries cache memory
is limited and actually it is 16 or 32Mb for hosting servers. This
means that we can actually store several hundreds queries in cache.
When we run MySQL on hosting server it processes these hundreds of
queries for couple of minutes and if all queries are cached by default
cache will be filled with trash queries and our queries will be pushed
out of cache for couple of minutes.
That is why i told about 'SET SESSION query_cache_type = DEMAND' and
'SQL_CACHE' as strategy to make built in cache usage more efficient.
But in this case every or at least most scripts should follow this
strategy that is absolutely unreal for now.
--
Best regards,
Maxim Antipin (ITScript CEO) mailto:max@itscript.com