20. Februar 2014

Langsame Repositories in BE-AJAX-Requests

in TYPO3

Wie der Titel schon vermuten lässt, handelt es sich im folgenden Workaround schon um etwas sehr Spezielles. In einer unserer Extensions haben wir Datensätze, in denen eine GoogleMaps-Karte dargestellt wird. Mit jedem Klick auf die Karte wird ein Marker erstellt und mit Hilfe eines AJAX-Requests direkt in der Datenbank gespeichert.

Den AJAX-Request rufe ich mit Hilfe von jQuery auf und es wird die offizielle typo3/ajax.php von TYPO3 geladen. In meinem Objekt hole ich mir nun den gerade bearbeiteten Datensatz über das Repository:

$start = microtime(TRUE);
$poiCollection = $this->poiCollectionRepository->findByUid($uid);
echo microtime(TRUE) - $start;

Wenn ich die URL zu dem AJAX-Request nun direkt aufrufe erscheint ein Wert von 0.30214715004 Sekunden. Ich weiß nicht wie Ihr das seht, aber um einen einzigen Datensatz zu holen, der direkt über die UID abgefragt wird, sollte nicht über eine Viertelsekunde benötigen. Schon gar nicht in AJAX-Requests.

Ich habe mich mit xdebug durch den Quellcode gehangelt und bin bei folgender Methode im Objekt Typo3QuerySettings fündig geworden:

/** @var $configurationManager \TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface */
$configurationManager = $objectManager->get('TYPO3\\CMS\\Extbase\\Configuration\\ConfigurationManagerInterface');
if (TYPO3_MODE === 'BE' && $configurationManager->isFeatureEnabled('ignoreAllEnableFieldsInBe')) {
	$this->setIgnoreEnableFields(TRUE);
}

Hier wird die Methode isFeatureEnabled() aufgerufen, um heraus zu finden, ob das Feature „ignoreAllEnableFieldsInBe“ über TypoScript aktiviert wurde oder nicht. Richtig gelesen: „TypoScript“! Um TypoScript im Backend zur Verfügung zu stellen, müssen schon ein paar Hebel bewegt werden. Zumindest ist das der Grund, warum die Abfrage so lange dauert. Die Frage ist jetzt: Wie kann ich es verhindern oder zumindest umgehen, dass dieser riesige Overhead an TypoScript geladen wird?

Ich habe mir dazu die getConfiguration() angeschaut:

public function getConfiguration($extensionName = NULL, $pluginName = NULL) {
	// 1st level cache
	$configurationCacheKey = strtolower(($extensionName ?: $this->extensionName) . '_' . ($pluginName ?: $this->pluginName));
	if (isset($this->configurationCache[$configurationCacheKey])) {
		return $this->configurationCache[$configurationCacheKey];
	}
	$frameworkConfiguration = $this->getExtbaseConfiguration();
...

Hey cool. Da gibt es einen ConfigurationsCache, aber leider ist dieser als „protected“ deklariert. Ein eigenes Configurations-Objekt wollte ich mir jetzt nicht bauen und habe ein paar Nachforschungen im Extbase-Quellcode durchgeführt und die Methode setProperty im ObjektAccess gefunden. Dort sieht man wie ihr als protected deklarierte Eigenschaften trotzdem direkt befüllen könnt ($forceDirectAccess) und genau das habe ich mir zu Nutze gemacht.

Zurück in meinem Ajax-Objekt injecte ich mir jetzt den BackendConfigurationCache:

/**
 * @var \TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager
 * @inject
 */
protected $backendConfigurationManager;

Und mit Hilfe der initializeObject()-Methode, die beim Instanziieren eines Objekte immer zuvor aufgerufen wird, verwende ich das Beispiel aus dem ObjectAccess und setze die benötigte Konfiguration manuell:

/**
 * In Typo3QuerySettings is a feature check which loads whole TS which needs about 250ms
 * With this workaround I modify the 1st level cache of configuration manager
 *
 * @return void
 */
public function initializeObject() {
	// set minimal configuration
	$configuration = array();
	$configuration['_']['features']['ignoreAllEnableFieldsInBe'] = 0;
		// transport our minimal configuration into backendConfigurationManagers 1st-level Cache
	if (property_exists(get_class($this->backendConfigurationManager), 'configurationCache')) {
		$propertyReflection = new \TYPO3\CMS\Extbase\Reflection\PropertyReflection(get_class($this->backendConfigurationManager), 'configurationCache');
		$propertyReflection->setAccessible(TRUE);
		$propertyReflection->setValue($this->backendConfigurationManager, $configuration);
	}
}

Ich gebe zu: Dieser Weg ist echt schräg und bestimmt nicht StateOfTheArt, aber als Messergebnis erhalte ich nun einen Wert von gerade mal: 0.0470860004425 Sekunden. Über das 6-fache an Performance.

5 Reaktionen zu “Langsame Repositories in BE-AJAX-Requests”

Kommentare abonnieren (RSS) oder TrackBack URL

Gibt es einen bestimmten Grund, warum hier unbedingt Extbase genutzt werden muss? Für hochperformante AJAX-Aufrufe ist die Kombination eID+t3lib_db/DatabaseConnection kaum zu übertreffen, da es praktisch keinen Overhead gibt.

Mathias Brodala am 25. Februar 2014 um 10:41

Wenn möglich sollte man mit ExtBase auch immer das Repository nutzen, sonst verliert man ja den Vorteil der Modell Ebene. Sprich wenn ich Logik in meiner Modell- oder Repository- Klasse abbilde (z.B. spezielle Rechte etc.) dann muss ich die bei einem direkten SQL Statement ja nachbilden, was wiederum die Code-Maintenance drastisch erhöht und auch Fehlerquellen mit sich bringt. Natürlich gibt es aber Fälle wo der Query Builder einfach zu ineffizient ist. Vor allem dann, wenn man über mehrere Tabellen komplexe Abfragen machen möchte. Aber auch da kann man nach der Abfrage das ganze wieder in ExtBase Modell Objekte umwandeln, so dass man auch dort die Modell-Ebene sauber abfängt.

Jonas am 26. Februar 2014 um 07:15

PS: Sollte man das nicht als Branch in Gerrit bereitstellen?

Jonas am 26. Februar 2014 um 07:16

@Mathias: Um „mal eben“ ein paar Daten aus der DB zu holen ist Deine Version definitiv super und performant. Je mehr Logik Du in Deine Modelle gebaut hast, desto lieber willst Du diese ja auch verwenden. Automatische Validierung, Texte croppen, implementierte Bilduploads. All das müsstest Du in Deinem eID-Script nachbauen.
@Jonas: Meine Art der Performanceoptimierung lässt die Hände der Coreentwickler über den Kopf zusammen schlagen. Grad gestern wieder mit einem gesprochen und auf diese Beiträge hier verwiesen „Oh mein Gott“ war die Antwort. Auch in Gerrit sind meine Patches nicht nur mit -1 sondern direkt mit -2 abgelehnt worden. In Venlo will ich das Thema mal ansprechen. Bis dahin poste ich es hier und jeder kann für sich entscheiden, ob er es einbauen will oder nicht.

Stefan Frömken am 26. Februar 2014 um 08:10

@Stefan: Das klingt allerdings, als würden die Models hier bereits viel mehr machen, als sie sollten. Wenn man sich strikt an die Aufgabenverteilung im Extbase/Flow-MVC-Stack hält, sollte ein Model ausschließlich als Datenspeicher dienen. Sämtliche Anwendungslogik gehört in einen Controller oder Service, eingeschränkt gerne auch in ein Repository.

Bitte nicht falsch verstehen: ich liebe den Komfort, den mir der MVC-Stack bietet. Bei Diensten mit hohen Anforderungen an Performance sollte man allerdings genau abwägen, wie viel dieser Komfort wert ist, wenn man dafür an anderer Stelle keine Optimierungsmöglichkeiten hat. Oder wie hier eben grenzwertige Wege beschreiten muss.

Bei all dem darf man natürlich nicht vergessen, was in der kommenden Version 6.2 von TYPO3 CMS an Optimierungen bzgl. Performance vorgenommen wurden. Aktuell hängen konkret bzgl. Extbase noch mindstens zwei Änderungen im Review, die die Datenbank-Interaktion merklich beschleunigen sollten. (https://review.typo3.org/27426 & https://review.typo3.org/27555) Die Kommunikation via AJAX sollte auch hiervon profitieren.

Mathias Brodala am 26. Februar 2014 um 08:40

Kategorien

Archiv