Franz Holzinger

Verse of the day

Denn es ist ein Gott und ein Mittler zwischen Gott und den Menschen, nämlich der Mensch Christus Jesus, der sich selbst gegeben hat für alle zur Erlösung, daß solches zu seiner Zeit gepredigt würde;
1 Timotheus 2:5-6

© Bible Gateway's Verse of the Day


Entwickler Version

Bitte testen Sie es immer vor dem Stellen einer Frage auch mit der aktuellen Entwicklerversion

autor  
10-07-13 18:09:24 feuser_register 3.0.1: Seitenaufruf >15sec
Claus Faber
Vertrackt: Sobald ich ein Plugin feuser_register auf einer Seite habe, dauert der Seitenaufruf zwischen 7 und 15 Sekunden. Alle anderen Seiten sind normal. Typo3 gibt eine rendering-Zeit von 0.1ms aus.

Das Plugin funktioniert ganz normal (keine SQL-Fehler), nur eben quälend langsam.

Kann es damit zu tun haben, ...
- dass ich nach UTF8-Umstellung noch einige Tables habe, die ISO-LATIN1 sind?
- dass die Tables MyISAM und InnoDB gemischt sind?
- realurl und stimulateStaticdocuments OFF sind?

Any ideas why? Vielen Dank echt!

typo3: 4.5.27 LTS
feuser_register: 3.0.1
rsaauth: 1.1.0& typ "rsa"
saltedpasswords: 1.0.0
static_info_tables: 2.3.2
static_info_tables_de: 2.1.0
div2007: 0.21
config.no_cache = 1 (gleiches Ergebnis wie 0)
10-07-13 19:08:42 welches Plugin?
Franz Holzinger
Ist es ein Create Plugin? Am besten mit debug_mysql_db untersuchen, welcher Datenbank Zugriff langsam ist.

Es kann auch an der Zeichencodierung liegen. Dazu sollte im Install Tool "[SYS][t3lib_cs_convMethod] = mbstring" und "[SYS][t3lib_cs_utils] = mbstring" gesetzt werden.
15-07-13 19:34:37 Re: Welches Plugin
Claus Faber
Lieber Franz,

1) es ist ein "Standard" Plugin, das nichts tut (Handbuch sagt, das soll auf dieselbe Seite, auf der das felogin auch ist).
2) Zeichencodierung auf mbstring gesetzt: super, bin schon herunten auf 6-8 Sekunden.

Ähm, wie sehe ich, welcher SQL-Aufruf so lange braucht?

Ich habe sqlDebug auf "2" gesetzt, um alle queries zu sehen, und habe verglichen: Seitenaufruf ohne sr_feuser_register und mit. Auffälligkeiten im Vergleich: Mit Plugin aktiviert ...

- werden mehrere zusätzliche INSERT INTO cache_hash geschrieben, wovon einer 5 Ausdruck-Seiten lang ist. Ohne plugin gibts auch mehrere INSERT INTO cache_hash, aber max. 3 Zeilen lang. cache_hash ist InnoDB mit utf8_general_ci.

- wird auf static_currencies, static_countries, static_country_zones und static_languages zugegriffen. Sind MyISAM mit utf8_general_ci.

Ich habe nach update auf typo3 4.5LTS und UTF-8 eine Mischung aus MyISAM und InnoDB, und utf8 und ISO-LATIN1.

Kann das der Grund sein? Wie kann ich das lösen?

dankeschön,
Claus
16-07-13 11:15:22 Untersuchung
Franz Holzinger
Die Ausführungszeit der SQL Anweisungen kann über die TYPO3 Erweiterung debug_mysql_db untersucht werden. Damit findet man sofort heraus, ob es daran liegt.
sr_feuser_register verwendet sehr viele Texte und lädt sie in den Speicher. Vermutlich macht das die Ausführung langsam.

Wenn es nicht an SQL liegt, dann kann man noch PHP Zeilen für die Zeitmessung einbauen, so wie es auch in der Erweiterung debug_mysql_db gemacht wird:

--------------
$starttime = microtime(TRUE);
$endtime = microtime(TRUE);

$microseconds = $endtime - $starttime;
$debugArray = array();
$debugArray['debug_backtrace'] = \TYPO3\CMS\Core\Utility\DebugUtility::debugTrail();
$debugArray['miliseconds'] = round($microseconds * 1000, 3);
debug ($debugArray, '$debugArray');
--------------
Damit kann man feststellen, an welcher Stelle in der Erweiterung sr_feuser_register die Zeit verbraten wird.

Wenn es noch ISO-Latin1 Kollationen gibt, dann sollten diese ebenso in utf8_general_ci umgewandelt werden. Man kann dies manuell über phpMyAdmin umstellen.
Alternativ gibt es ein PHP Skript db_utf8_fix.php oder man sucht das PHP Skript von Boris Bojic zum Umlaute korrigieren und passt es an und führt dieses danach aus.
16-07-13 11:59:49 juhuu
Claus Faber
Erstmal: riesengroßes Danke für die Hilfe an einen typo3-Dilettanten Ich lobe eine Flasche Wein aus! Jetzt haben wir den Schuldigen:

- Modul:
Pg495 exec_DELETEquery(cache_md5params) - class.tx_srfeuserregister_control_main.php#154->init // class.tx_srfeuserregister_controldata.php#140->cleanShortUrlCache // class.tx_srfeuserregister_controldata.php#1047->exec_DELETEquery

- Die query ist watscheneinfach:
DELETE FROM cache_md5params WHERE tstamp<1371375157 AND type=99

- Affected rows: keine

- Und sie braucht rund 750.000 Millisekunden.

Ich habe nachgesehen: der table ist eine InnoDB mit utf-8 und etwa 970.000 (!) Datensätzen. Davon sind gut 660.000 Einträge timestamp<1371375157, aber alle typ 1, nicht 99.

Idee, was da los sein kann?
16-07-13 12:00:54 ups...
Claus Faber
kleiner Tippfehler: Sind "nur" 75.000 Millisekunden, nicht 750.000...
16-07-13 12:59:04 Index
Franz Holzinger
Scheinbar läuft diese Webseite schon sehr lange. Das stammt alles von Registrierungen, die begonnen aber nie abgeschlossen worden sind. Vermutlich wollen sich diese Leute nicht zu Ende registrieren. Dann könnte man die Datensätze auch einmal manuell löschen. Die Anzahl der "Affected Rows" stimmt in diesem Fall nicht, weil das DELETE keine Anzahl zurückliefert.

Es wäre zu überlegen, einen Index auf die beiden Felder "tstamp" und "type" in Kombination zu legen. Denn offensichtlich muss MySQL alle Datensätze sequentiell durchsuchen, was bei dieser Größe in diesem Fall 75 Sekunden gedauert hat (= 75 000 Milisekunden).
16-07-13 17:01:32 Puuh! Geschafft, danke!
Claus Faber
Juhuu, das hat das Problem gelöst:

1) den table löschen (TRUNCATE; da waren tatsächlich Einträge seit 2007 drin)
2) einen kombinierten Index auf die beiden Parameter anlegen, die abgefragt werden (tstamp,type)

... und die Abfragezeit ist unter 5 Millisekunden herunten!

Die Flasche Wein kommt! Vielen Dank!
26-07-13 20:12:00 Ich danke auch
Franz Holzinger
für eine Flasche Wein "Heideboden Zweigelt Selection" aus dem Burgenland, die heute bei mir angekommen ist.
< Zurück zum Forum