SOLR Performance

Hallo Community,

SOLR beeinträchtigt scheinbar die Arbeit im BE insbesondere bei Speichervorgängen in die DB (z. B. Datensätze ein/ausblenden mittels Listmodul oder auch erstellen neuer Datensätze z. B. tt_content).

Folgende Symptome treffen nicht zu, wenn das Plugin 'solr 2.6.0-dev' deinstalliert wird:

Symptome:
- der Browser (Produkt egal | Netzwerk egal) meldet sich meistens sehr spät (im Minutenbereich) oder gar nicht (Error 324) zurück.
- ein zweiter Browser(-tab) zeigt während der Erste noch "arbeitet" die erwarteten Änderungen.
- manche "längerwierigen" Aufgaben (ln10nmgr importe) brechen ab (nicht über CLI - nur über BE)

Umgebung:
- Typo3 4.5.20
- solr 2.6.0-dev
- Mehrsprachiger (14) Multitree-Auftritt (15) mit entsprechenden Kernen
- SOLR-Speicher 512MB unterschiedlich auf die jew. Sprachen Verteilt, jedoch alle min. 10MB
- Tabelle "pages" > 7000
- Tabelle "tt_content" > 30000
- Scheduler: je Rootpage (14 Stück) ein Commit- und ein Queue-Worker Task; alle 30 Minuten jeweils zueinander Zeitversetzt

Auffälligkeiten:
- Datenbank-Feld 'sys_registry.entry_value' wurden in der Kapazität (BLOB) überschritten (in der Folge: korruptes serialisiertes PHP-Array) - bereits behoben durch Wahl einer größeren Einstellung (LONGBLOB)
- Solr-Admin listet im zweiten Dropdown (Auswahl der Kerne) alle verwendeten Kerne mehrfach (>12)! - Ich erwarte eigentlich jeden Kern nur einmal (repräsentiert diese Liste den Ihnalt von sys_registry.entry_value?)
- Scheduler Commit meldet ab und an: "Ausführung fehlgeschlagen: 0, Solr response does not appear to be valid JSON, please examine the raw response with getRawResponse() method" (wie mach ich das?)

Jeglicher Hinweis die zur Ergreifung des Täters führt (auch falls ich das selbst sein sollte) wird schon jetzt mit "1000 Dank" behlohnt :-)

hardcoder schrieb

Jeglicher Hinweis die zur Ergreifung des Täters führt (auch falls ich das selbst sein sollte) wird schon jetzt mit "1000 Dank" belohnt :-)

Scheint doch etwas härter zu sein die Nuss - und auch ein Update auf 2.8.0 hat am Problem nichts geändert.

Ich habe in der Zwischenzeit einen weiteren Tipp:

Die Garbagecollection scheint hier der Verursacher meiner Problematik zu sein.

Kommentiert man

	#$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processCmdmapClass'][]  = 'EXT:solr/classes/class.tx_solr_garbagecollector.php:&tx_solr_GarbageCollector';
	#$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][] = 'EXT:solr/classes/class.tx_solr_garbagecollector.php:&tx_solr_GarbageCollector';

in ext_tables.php aus rennt das System wieder. Ist mein Projekt zu gross für Solr?

Also nur um mal Solr in Schutz zu nehmen. Solr (die Suchmaschine) ist definitiv nicht Schuld. Höchstens die Extension die du verwendest, um Solr an TYPO3 anzubinden.
Ich hab mir die Arbeitsweise der Extension solr noch nicht näher angesehen, da ich nur mksearch verwende. Dort entstehen garantiert keine längeren Laufzeiten bei der Arbeit im Backend. Alle Verwaltungszugriffe (Indizierung und Löschung von Daten) auf Solr (oder auch Lucene) erfolgen da generell asynchron.