[TYPO3-german] TYPO3-PerformanceProblemebeimehrals2000angelegten Seiten -Warenkorb Overview wars

[JoH]

>> Mit $TSFE->set_no_cache(); hebelst Du den gesamten Caching
>> Mechanismus der Seite aus, weil diese so jedesmal komplett neu
>> erzeugt werden muß.
>
> Ja, weil es keine TYPO3-Funktion gibt, um den Cache nur für
> tt_products oder für einen Code von tt_products zu löschen. Bzw. es
> müßte tt_products aufgespalten werden auf 2 Plugins, einmal für
> statische und einmal für dynamische Teile.

Die "Funktion", die das kann, heißt eben COA/COA_INT bzw. USER/USER_INT.
Damit kannst Du das Ganze sogar so weit runterbrechen, dass nur noch
bestimmte Formularfelder dynamisch sind, während der gesamte Rest aus dem
Cache kommt.
Bilder, Beschreibungen, Varianten etc, das alles kann hervorragend gecached
werden und würde zudem noch per Indexed Search auffindbar sein.

>> Das gleiche funktioniert selbstverständlich auch innerhalb der
>> Ausgabe von tt_products als plugin und zwar so, wie ich es bereits
>> in meinem anderen Posting gezeigt habe:
>>
>> temp.tt_products < plugin.tt_products
>>
>> plugin.tt_products >
>> plugin.tt_products = CASE
>> plugin.tt_products {
>>     key.field = select_key
>>     default = COA
>>     default.10 < temp.tt_products
>>     BASKET = COA_INT
>>     BASKET.10 < temp.tt_products
>>     FINALIZE < .BASKET
>>     TRACKING < .BASKET
>>     WHATEVER < .BASKET
>> }
>>
>> Pack einfach alles in die Liste der COA_INT Elemente, was Deiner
>> Meinung nach dahin gehört.
>> Wenn Dir das zuviel Aufwand ist, mach meinetwegen ein COA_INT aus
>> dem ganzen Element, aber schmeiß auf jeden Fall die set_no_cache()
>> Nummer raus!
> Wenn tt_products zu einem COA_INT werden würde, dann wäre das Caching
> für tt_products weg. Damit wäre es erst wieder langsamer bei vielen
> Produkten in der Listenansicht.
> Dieser CASE über select_key funktioniert nur, wenn jemand noch das
> Code-Feld verwendet und nur einen Code pro Content-Element einträgt.
> Aber in der Regel sollte jeder Flexforms verwenden, und es können auch
> mehrere Ansichtsarten oder Codes gleichzeitig auf einmal eingetragen
> werden. Also kann das nicht als Standard-Einstellung für tt_produts
> verwendet werden.

Das war ja auch nur ein Beispiel, wie es auch ohne set_no_cache() laufen
könnte.
Natürlich kann man das nicht so pauschal verwenden, wie es da steht.
Es wäre aber auf jeden Fall ein Ansatz für einen erbeblichen Performance
Boost in tt_products.

> Vielleicht sollte man nur den Miniwarenkorb in eine eigene Extension
> packen. Alle anderen Codes, die kein Caching haben dürfen, kommen
> eigentlich nur auf einer eigenen Seite vor, also ohne einen zweiten
> gleichzeitig möglichen Code. Außerdem sind die dynamischen Shop-Seiten
> schnell genug, nur die Listenansicht ist ab 1000 Produkten
> problematisch.

Im Prinzip geht das schon in die richtige Richtung, aber mir persönlich ist
das noch nicht weit genug gedacht.
Ich habe aber soeben festgestellt, dass Du gar nicht allzu weit weg wohnst.
Vorschlag dazu: Lass uns das mal bei einem Kölsch/Alt belabern und sehen,
wie man tt_products nochmal richtig schön aufbohren kann.
Da sind nämlich noch einige andere Ecken und Enden, an denen man die
Vorgehensweise im Hintergrund optimieren kann, ohne dabei die Arbeitsweise
für den Anwender großartig zu verändern.

Was hältst Du davon?

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.cybercraft.de