Résoudre un problème de lenteur sous TYPO3 quand on partage le dossier typo3temp en NFS entre plusieurs serveurs

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on Reddit0Share on StumbleUpon0Email this to someone

Sous ce titre de billet très long j’ai essayé de résumer le problème que j’ai rencontré dans le cadre de mon travail sur une application tournant sur le cms TYPO3 version 6.1.1.

En environnement de développement tout allait bien, les performances du site était bonne, le backoffice également. Nous passons plus tard en environnement de pré-production.

Serveur ultra puissant (que ce soit les frontaux ou la base de données) et malgré cela j’obtiens un temps de chargement backoffice extrêmement lent ! L’action de changement des droits des pages prend plusieurs minutes à s’effectuer (environ 50 pages) alors que le même nombre sur la version de démo de TYPO3 prend quelques secondes !

Je décide alors de surveiller les requêtes sur la base de données. Au passage j’en profite pour vous parler d’un logiciel vraiment sympa : Jet Profiler for MySQL.
J’obtient un nombre crête de 250 requêtes/secondes ! Autant vous dire que ce n’est rien du tout ! Alors que ce passe t’il ?

Voici l’architecture web mise en place (je vous ai fait un schéma simplifié) :

1 répartiteur de charge + 2 serveurs web frontaux + 1 serveur de partage de ressource + 1 serveur de base de données

1 répartiteur de charge + 2 serveurs web frontaux + 1 serveur de partage de ressource + 1 serveur de base de données

Lorsqu’un internaute visite le site, le répartiteur décide de l’envoyer sur l’un des 2 serveurs web. La requête HTTP arrive sur Apache, il exécute PHP…

Ensuite c’est à ce moment qu’intervient le serveur de ressources. Nous avons décidé de partager les ressources entre les serveurs Web pour ne pas avoir besoin de mettre en place un mécanisme de synchronisation des dossier « typotemp » et « uploads » (nous en avons profité pour le faire aussi pour le dossier « fileadmin »). Ce partage a été mis en place au travers d’un montage NFS. Lors que TYPO3 ou notre extension a besoin d’écrire un fichier dans le dossier typo3temp il ne savent pas qu’ils sont sur finalement sur un serveur distant. Le dossier « typo3temp » est présent en local sur le serveur et c’est tout ce qui compte. C’est la magie des montages de dossier en temps que montage NFS.

Oui mais si vous relisez le titre du billet c’est peut être à ce moment là que vous allez comprendre d’où venait le problème.

En effet, alors que cela ne posait pas de problème particulier d’utiliser le NFS avec les version 4.x de TYPO3, cela en posait depuis la version 6.0. De nouveau fichier de cache ont vus le jour et sont crées dans le dossier « typo3temp » (valeur par défaut, nous en reparlerons après).
Je n’ai pas pu voir ce que cela représentait comme nombre de fichiers (TYPO3 ne laisse pas assez longtemps les fichiers sur le disque) mais un dossier se nommant « Cache » dans « typo3temp » est utilisé pour stockage de différents caches.

Pour expliquer la piste de ce « cache » j’ai cherché dans la documentation de TYPO3. Et c’est la que vous pleurez réellement… Déjà, n’espérez jamais avoir de l’aide via les forum FR, soit on vous répond « Va voir la doc » ou soit on ne vous répond même pas…
Bref, la documentation de TYPO3 sur les caches se trouve ici. Alors oui c’est chouette tout est expliqué dans les moindres détails, quels sont les différents cache, où ils peuvent être enregistrés (fichier, base de données, redis, memcached, etc.. ). Mais ce n’est quand même pas super évident…

Il faut savoir que tous les types de caches de TYPO3 ont une configuration par défaut. Des fois ce sera dans la base de données, des fois ce sera en fichier sur le disque. Si nous regardons dans la configuration « file backend » vous pouvez voir que par défaut le dossier est « typo3temp/cache/« . Nous allons changer ce chemin par défaut pour le placer en dehors du dossier « typo3temp ». Ainsi il ne sera pas sur NFS.

Tout d’abord créez un dossier « typo3cache » (par exemple dans le dossier de TYPO3 (au même niveau que les dossier « typo3temp », « uploads », etc… En effet, la configuration cherche un dossier par rapport au dossier principal de votre site.
N’oubliez pas de donner les droits à votre user « apache » car il aura besoin d’écrire dans ce nouveau dossier.

Ensuite nous allons modifier la configuration de TYPO3.
Editez le fichier « typo3conf/LocalConfiguration.php »

Rendez-vous à la fin du fichier, vous devriez avoir une configuration « SYS », voici un exemple :

'SYS' => array(
	'compat_version' => '6.1',
	'curlUse' => '1',
	'dbClientCompress' => '0',
),

Il faut ajouter la configuration dans « SYS ». Voici ce que j’ai mis :

'SYS' => array(
	'caching' => array(
		'cacheConfigurations' => array(
			'cache_core' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			'cache_phpcode' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			'fluid_template' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			't3lib_l10n' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
		),
	),
	'compat_version' => '6.1',
	'curlUse' => '1',
	'dbClientCompress' => '0',
),

Bon alors dans ma configuration je n’étais pas obligé de ré-écrire les valeurz « backend » et « frontend » car ce sont déjà les valeurs par défauts (spécifiez simplement les tableau options »).

Videz les caches de configuration de TYPO3 et testez votre site pour voir s’il fonctionne toujours et si le dossier « typ3cache » se rempli.

Suite à cette modification, la valeur de 250 requêtes/secondes passe maintenant à plus de 2500 ! C’est beaucoup mieux !

Il reste encore d’autres possibilités pour faire grimper les performances, mais ça fera l’objet d’un autre billet sur ce blog 😉

 

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on Reddit0Share on StumbleUpon0Email this to someone
Taggé .Lien pour marque-pages : Permaliens.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Veuillez prouver que vous êtes un humain : * Time limit is exhausted. Please reload CAPTCHA.