[Apc-aa-coders] Re: Caching - are you able to help a bit

[Mitra <mi...@ea...>]

Honza

(I've split your message - seperate the purge issues from 
display-count updates)

Thinking about this problem of display-counts,

I wonder if the best thing would be to put them in a separate table. 
I think MOST views don't ever care about that field, so we could then 
only  read that table unless someone uses an alias that requires 
showing display-count?

- Mitra


At 12:27 AM +0100 5/3/03, Honza Malik wrote:
>  > >The best solution, I think, is to call purge() from AA cron. The cache
>  > >was written in time, then AA cron wasn't in AA, so there was no such
>  > >possibility. Now we can move it here.
>  > >
>  > >I think it should not be problem. Anyway. I plan to write script
>>  >db_maintain.php3 which will be runed each 5 minutes from AA cron. There
>>  >I want to move managing count Hits (Item display count). Marek found
>>  >some inefficiecy in count hit - if a user searches in AA, noone can view
>>  >fulltext!!! - it waits until the searching is done and after that it
>>  >updates display_count in item table. After that the fulltext is shown.
>>  >It is quite bad.
>>
>>  I don't think its a good idea to rely on Cron, it requires access to
>>  the system that many cases won't have - I find this when I'm doing
>>  work for some organization who are hosting their site on some ISP,
>>  not on their own machine. Often this hosting is a gift by the ISP to
>>  the organization, so they don't always give it top priority.
>
>That's right but I do not see better solution. What about to create
>special service (say at Econnect or SourceForge) which will create HTTP
>request to cron.php3 on remote AA installs for such organizations (each
>5 minutes)?
>
>(I'm sure there must be such service on the web already.)
>
>>  I find the search/fulltext issue quite surprising, can you say more
>>  about where this lock happens - is it in MySQL or in PHP ?  And what
>>  has this got to do with Counting Hits?  Or do you mean that it is
>>  because the fulltext view is trying to update the table, and can't do
>>  this until the Search finishes?
>
>Yes, exactly. It is MySQL issue. If MySQL do the SELECT from item joined
>with content table, the tables are locked (at least in MySQL <4) and all
>UPDATEs must wait until the SELECT is executed.
>
>>  >We can fix it, if we write the hit to another table. We plan to use log
>>  >table, where we log the hit and then we run db_maintain.php3 from cron.
>>  >The script will count all loged hits and then update database
>>  >(item.display_count). There is no problem, if the script will call also
>>  >purge() for cache. The purge events could be written into log database
>>  >as well, so we will know, when last purge() was run.
>>
>>  Another solution MIGHT be to do the hitcount update AFTER all page
>>  output has been done, that way we don't care if the script waits a
>>  second or two?
>
>No way. We can't use it with shtml files, because SSI includes MUST wait
>after whole script is executed. After then it can continue display next
>part of shtml file.
>
>Also, MySQL do not have any UPDATE DELAYED command. It has only REPLACE
>DELAYED, which we can't use, because the autoincremented short_id is
>changed on each REPLACE.
>

-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved