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

[JoH]

>>> Ich hatte diesen über einen Marker so eingebunden:
>>> ### Warenkorb auf jeder Seite ###
>>> #seite.20 {
>>> #marks.WARENKORB < plugin.tt_products
>>> #marks.WARENKORB.code >
>>> #marks.WARENKORB.code = OVERVIEW
>>> #}
>>
>>
>> Tja, Du hast rein prinzipiell gesehen recht. Es liegt an tt_products
>> Ich hab mir gerade mal die sources von tt_products vorgeknöpft und
>> da steht an diversen Stellen:
>>
>> $TSFE->set_no_cache();
>>
>> Das ist absolut tödlich und vor allem unnötig.
>> Du kannst das aber relativ einfach abstellen:
>>
> Wie soll das funktionieren, wenn eine Seite mit Miniwarenkorb
> gecached wird? Sobald sich ein Produkt im Warenkorb befindet, darf
> auch die
> Listenansicht nicht mehr aus dem Cache kommen, weil ja die Anzahl der
> bereits gekauften Produkte im Eingabefeld stehen bleiben soll. Ggf.
> könnte man das umprogrammieren.
>
> Die SQL-Abfrage läßt sich beschleunigen, wenn keine Liste über alle
> Produkte erzeugt werden muß. Das geht durch die Verwendung der
> Kategorie tx_ttproducts_pi1[cat] als Parameter, der z.B. in der
> Kategorieliste automatisch mit übergeben wird.

Wir reden hier aber nicht von einer langsamen SQL-Abfrage, sondern vom
Ausbremsen eines gesamten Systems, nur weil auf der Seite an einer
bestimmten Stelle ein Warenkorb oder eine Liste angezeigt werden sollen.
Das mit der SQL-Abfrage war lediglich eine Vermutung, die einige hier
geäußert hatten, scheint aber nicht wirklich der alleinige Grund zu sein.
Mit $TSFE->set_no_cache(); hebelst Du den gesamten Caching Mechanismus der
Seite aus, weil diese so jedesmal komplett neu erzeugt werden muß.
Es kann ja wohl kaum sein, dass durch die Nutzung eines Miniwarenkorbs auch
sämtliche fetten Menüstrukturen, GIFBUILDER Elemente und andere Inhalte neu
erzeugt werden müssen, die mit dem Shop eigentlich gar nichts zu tun haben,
aber jedesmal ordentlich Performance fressen. Mal ganz abgesehen davon, dass
Du damit keinerlei Möglichkeit hast, Indexed Search einzusetzen.
Das ist vor allem deshalb unnötig, weil es ausreichen würde, nur die
dynamischen Elemente selbst (sprich: Die Liste, den Warenkorb oder was immer
an veränderbaren Shop-Elementen verwendet wird) neu zu erzeugen.

Aufbau ungefähr so

# Seite kommt aus dem Cache
page = PAGE
page {
    # Menu kommt aus dem Cache
    10 = HMENU
    # Content kommt aus dem Cache
    20 = CONTENT
    # Miniwarenkorb wird immer neu gebaut
    30 = COA_INT
    30.10 < plugin.tt_products
    30.10.code = OVERVIEW
    # Anderes Shop Element wird immer neu gebaut
    40 = COA_INT
    40.10 < plugin.tt_products
    40.10.code = WHATEVER
}

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!

Siehe hierzu auch:
http://lists.netfielders.de/pipermail/typo3-dev/2003-September/000477.html

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