[TYPO3-dev] problems with cache hashes

Hartmut Plehn plehn at rz.uni-wuerzburg.de
Fri Nov 30 12:36:09 CET 2007


Olivier Dobberkau wrote:

> Hartmut Plehn schrieb:
> 
>> Maybe some more information about our system helps: There are over 10000
>> entries in cache_pages corresponding to the page with the CE causing the
>> problems. We have over 30000 entries in table "pages", over 80000
>> in "cache_pages" and about 180000 in "cache_hash" when the caches are
>> filled. Deleting the 10000 cache_pages entries for the problem page took
>> 1:40 min just now, blocking page delivery to frontend for 2 minutes. If
>> at the same time there are some indexed-searches coming in we're in big
>> trouble.
> 
> Hi Hartmut.
> 
> I think we have the same setup here.
> 
> We managed to get rid of some issues using nc_staticfilecache.
> PM if you want to discus this in a phone call.
> 
nc_staticfilecache probably won't help since we heavily use personalized
pages and non-cacheable content.

But I promised to try InnoDB and report my results:

delete from cache_pages WHERE page_id IN (46772);
Query OK, 9764 rows affected (3 min 53.77 sec)

which means that clearing the cache of our problem page did even take longer
than with MyISAM (1:40 min). (Shouldn't that be much faster with both table
types?) The good news is: during that time there has been no locking of
tables and no problem with page delivery to frontend. So probably InnoDB
really is the way to go. 

We have one other problem left, though: From time to time there happens
a "DoS" (even resulting in server crash) when somebody starts multiple
indexed_searches over and over again without waiting for the result page.
There is some kind of design issue in my opinion since page contents cached
for indexed_search are grouped by gr_list. Our many user groups and group
auto-logins by ip-address ranges result in almost 400 distinct gr_list's.
(I admit that this probably isn't proper use?) It leads to really huge
indexed_* tables and to performance problems during searches (that provoke
the impatient user to start searches again and again...).

On our starting page we therefore switched to mnogosearch but indexed_search
is still used on many sub trees. And the possibility to search content
personalized would be very nice indeed. The crawler extension is also
problematic in combination with many different gr_list's because the page
has to be requested for every possible gr_list combination. All in all
indexed_search in my opinion is not usable at sites with complex FE user
rights. mnogosearch doesn't support "personalized" searches, which imho
really is a pity, because it weakens Typo3 as a true internet and intranet
solution.

Best regards
H. Plehn

-- 
Hartmut Plehn, Universitaet Wuerzburg




More information about the TYPO3-dev mailing list