[TYPO3-project-4-3] Improving the language overlay performance
Francois Suter
fsuter at cobweb.ch
Tue Sep 16 13:00:13 CEST 2008
Hi all,
I have been working recently on extensions that can display any record
from the TYPO3 database. As such I have had a lot to do with the overlay
process with 2 main worries: performance and a useful API.
The performance is the most important topic. Right now the typical way
to get a list of records is to use t3lib_db::exec_SELECTquery() and then
call t3lib_page::getRecordOverlay() for each record. The latter queries
the database each time, to retrieve the correct overlay. This would seem
to be a performance killer on a high-traffic site, especially with
USER_INT plug-ins (think search engines, for example).
I tried to develop an alternate process, by querying all the relevant
overlays in one go, and matching them on the PHP-side (precise matching
is necessary because of versioning), thereby reducing the number of
calls to the database.
I have bundled the code in an extension called "overlays" which I will
attach to this mail (if allowed by the list server) or that can be
gotten from forge [1].
I made some performance test on a page containing a USER_INT plugin
which calls 4 different tables, with a varying number of records each
(actually 1, 1, 6 and 25, respectively). I'm not a specialist of
benchmarking and I just used Apache bench with the following parameters:
ab -n 250 -c 50 [URL of test page]
and this clearly hasn't pushed the limits of my local server very far.
On several runs I see nearly no performance difference, but maybe I
should be pushing my server further and making more runs and averaging
the figures. I still wanted to describe all of this to you before going
much further, as a kind of sanity check. Do you think that what I'm
doing makes sense or am I barking up the wrong tree?
I know that I have added some refinements to the whole overlay process
(for example, by making sure that the query contains all the necessary
fields for performing the overlay), so it may be that this additional
processing offsets part of the reduced database calls gains.
Basically the "overlays" extension contains a class called tx_overlays
which contains methods to be called statically. In terms of API, there's
a method called tx_overlay::getAllRecordsForTable() which takes the same
arguments as t3lib_db::exec_SELECTquery() and takes care of returning
properly overlaid records. It calls on methods like
tx_overlays::getLanguageCondition() and
tx_overlays::getEnableFieldsCondition() that take care of setting the
right SQL clauses for the developer.
So it's quite easy to test, because all you have to is include the
class.tx_overlays.php class file and call
tx_overlay::getAllRecordsForTable() with the same arguments as
t3lib_db::exec_SELECTquery() and you will get your fully overlaid recordset.
I would be very glad to have your feedback about this.
Cheers
--
Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch
[1] https://svn.typo3.org/TYPO3v4/Extensions/overlays/trunk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T3X_overlays-0_0_0-z-200809161259.t3x
Type: application/octet-stream
Size: 6492 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-project-4-3/attachments/20080916/6fd0eb50/attachment.obj
More information about the TYPO3-project-4-3
mailing list