[TYPO3-performance] Deleting pages in Backend extremely slow

[Ernesto Baschny [cron IT]]

abo at schmutt.de schrieb am 04.10.2012 11:26:

> I have a very special performance problem in a big typo3 (>100.000
> pages) installation, version 4.5.4:
> 
> Deleting of pages is extremly slow: >30sec,
> Often backend completely timed out. I get then this red overlay, I think
> it is some kind of timeout:
> Connection Problem
> Sorry, but an error occurred while connecting to the server. Please
> check your network connection.
> 
> Other page operations like create, move, edit, rename are OK.
> Well, not fast but OK, Firebug shows between 500ms and 3,5s.
> 
> Database is OK, mysql slow requests doesn't show anything.
> PHP Memory limit is on 256M on dev server, and 512M on live server, both
> have this problem
> Deprecation log is OK
> 
> You can help me, if you know anything to catch that bug.
> Is there any logging, performance tool for the backend? If you can tell
> me where the "delete pages" code is running, I can add some debug
> messages by myself.
> 
> As the server is usually OK, there must be any stupid thing, extension
> or someting starting lots of requests when deleting pages. Actually we
> have solr under suspicion, but we can't find anything atm.
> 
> Or if you have any other idea, let me know!

To me it looks on cache invalidation issues, as Steffen suggested. As we
have seen this problem once in a while on big installations, check out
the following:

Caching tables are InnoDB:

1) Check out the size of the TYPO3 core caching tables! Usually you find
out that their tablespaces are multiple GB in size, which will affect
negatively a selective "DELETE FROM" operation. Regaining space is only
(easily) possible if you have InnoDB configured to have a file per
tablespace.

2) Check also the RealURL caching tables: Being also InnoDB they might
contain several GB of tablespace too. RealURL also invalidates specific
caches on save of records in the backend.

For 1) I moved away from InnoDB caching tables and used Caching
Framework with Redis instead. For 2) I haven't found a good solution
yet, but ended up by running some "DELETE FROM" and "OPTIMIZE TABLE" on
a daily cronjob. See also my request
http://bugs.typo3.org/view.php?id=18604 (request to use caching
framework in RealURL).

I expect that Solr shouldn't affect that, as their crawling is based on
having a "crawl-queue", so the actual (time consuming) crawling is only
triggered by a scheduler task.

Cheers,
Ernesto