Moin klaus,
main Till,
die Umsatellung auf MyIsam kann nicht die wirkliche Lösung sein.
Vielleicht möchte man irgendwann das projekt skalieren, ...)
Das hört sich nach dem Typischen Extbaase-Problem an.
Bei komplexeren Datenmodellen versucht Extbase das gesamte Modell
aufzulösen.
Komplexere Datenstrukturen können in TYPO3 zu Timeaouts führen, weil
TYPO3 oft nur für bestimmte Spezialfälle notwendige Datenrequest machen
muss oder auch wegen des generischen Prinzips einfache Datenrequest für
jeden Datensatz erneut durchführen muss.
Ich denke insebsondere die Übersetzunge sind wegen der vielen
implizieten Joins ein Timekiller.
Ich hatte für ein ShowItem bei einem Datensatz mit vielen Relationen
schon mal 8000 Datenbankabfragen (iohne Fremdsprachenbezug).
Ich sehe zwei Handlunsgmöglichkeiten
1. Setze Bugticket im Forge (mit zugrundeliegender SQL und TCA)
Vielleicht kommt ja irgendwann mal ein per Yaml definierbarer
Backend-Formular-Builder, so dass die Zeiten für dich wieder erträglich
werden.
2. baue ein eigene Backend-Modul, um deine Datensätze im Backend zu
bearbeiten. So hast dür die Kontrolle über die Request, die abgefeuert
werden. Dort hast du die SQL selbst in der Hand. Du könntest evtl. die
Ausgabefelder in deinen Templates aus dem Frontend als Formulare
definieren und sie im Backend via Ajax als "Frontend-Editing"-Felder zu
nutzen. (HTML5 machts möglich) - Ich habe so etwas in abgewandelter Form
mal Testweise für eine Frontend-Version gemacht. Ist eigentlich ganz
übersichtlich.
Mit besten Grüßen
Dieter
Am 21.07.2020 um 14:40 schrieb g4-l...@tonarchiv.ch:
>
> On 21.07.20 14:03, Gert Redlich wrote:
>> Am 21.07.2020 11:32, schrieb Klaus Fiedler:
>>>
>>> Hallo Liste!
>>>
>>> Wir haben eine Seite mit 7(!) Sprachen und recht komplexen
>>> Produktdatensätzen. Diese besitzen einige unterschiedliche
>>> Bild-Felder (FAL) sowie ca. 10 unterschiedliche Felder, welche
>>> sys_catgories beinhalten und dementsprechend Einträge in der
>>> sys_category_record_mm verursachen.
>>>
>>> Das Speichern eines solchen Datensatzes im Backend dauert meist
>>> Minuten und bricht dann per Timeout ab.
>>>
>>> Recherchen und einigige gefundene Issues auf typo3forge werfen die
>>> Frage auf, ob TYPO3 mit solch einer großen Masse an Daten
>>> (multipliziert mit den Übersetzungen) überhaupt
>>> ordentlich umgehen kann.
>>>
>>> Ich wollte deswegen fragen, ob jemand Erfahrungen mit dieser Thematik
>>> hat.
>>>
>>> ........ usw
>>
>>> Nochmal: Verstehe ich hier vielleicht (hoffentlich) etwas grundlegend
>>> falsch? Das ist für größere, internationele Projekte sonst schon ein
>>> echtes Problem, oder?
>>> Viele Grüße
>>> Klaus
>>>
>>
>> Hallo Klaus,
>>
>> ich habe nach mehreren sehr ausführlichen Tests fast die Hälfte der
>> mysql-
>> Tabellen wieder von innodb auf myisam umgestellt,
>>
>> wenn Du - wie ich - keinen Shop hast, der eine Datenkonstistens
>> erfordert,
>> ist myisqm teilweise über Faktor 2 performanter.
>>
>> Dort wird eben nicht erst mal in Log-Bücher geschrieben und dann erst
>> in die Tabellen einsortiert, also quasi doppeltes Abspeichern der
>> gleichen
>> Datenmenge.
>>
>> Dann hatte ich diverse PHP Parameter noch weiter als vorgeschlagen
>> erhöht.
>> also massig Speicher 512 MB und massig Zeit (über 400 sekunden), und dann
>> kann es klappen.
>>
>> In meinem Museumsprojekt habe ich alle Tabellen komplett auf myisam
>> zurück
>> gestellt, probier mal www.hifimuseum.de, einfach mal durchbrowsen, es
>> geht
>> super schnell.
>>
>> http://www.hifimuseum.de/hifimuseum-neues.html
>> http://www.magnetbandmuseum.info/magnetband-neuigkeiten.html
>
> Hallo
>
> Wie sieht es denn aus mit Tabellen-Indizies? "Von Haus aus" haben die
> DB-Tabellen ja meistens nur Indizies auf Typo3-eigenen Felder, also
>
> PRIMARY KEY (uid),
> KEY parent (pid),
> KEY t3ver_oid (t3ver_oid,t3ver_wsid)
>
> Je nach Modell und Abfragen kann es helfen, wenn man von Hand noch KEY(
> <foreign key>) hinzu fügt.
>
> Ok, es geht ja hier um's Schreiben. Da ist das wohl nicht relevant. Oder
> macht es sogar noch langsamer. Also wieder vergessen. Aber jetzt habe
> ich die Mail schon geschrieben, also schicke ich sie auch ab ;-)
>
> Tja, generell ist ein CMS halt für wenig Schreiben viel Lesen optimiert.
> Und Extbase ohne Cache ist sowieso eine lahme Krücke...
>
> Grüße,
> Till
>
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german@lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
