Goddess-Gate.com - Le blog 2.0 - Tag - apache

Apache 2, PHP and FreeBSD: traps to avoid (and other tricks)

Arnaud Boudou — Fri, 06 Apr 2007 11:06:00 +0200

I won't give you the magical recipe which solve all your problems, but just some tricks to avoid many situations you may encounter. This post may be updated if I find any new tricks. Theses tricks will be administration but non development oriented.

first publication on 22/02/2006

06/04/2007 : add some tricks about MySQL (temporay tables buffer) and PHP (persistent connections)

About configuration

This post was redacted with at least this configuration in mind:

Apache 2.2.3
PHP 5.1.6
MySQL 5.0.24
FreeBSD 6.1-STABLE

Of course, it may be usable for other configurations, or give elements to think about.

MySQL performances

Under FreeBSD and not under GNU/Linux, performances drop down where there are too many simultaneous connections. With my 1.8 GHz Celeron and 1.2 MB RAM, I can't go over 30 simultaneous connections without blocking the computer.

This issue seems to be fixed with FreeBSD 7.0, but it may be possible to attenuate it with previous versions.

Here are some ideas:

Build MySQL with Linux threads. You have to use “WITH_LINUXTHREADS=yes” parameter while building it (the way to use it may vary depending your installation procedure: portupgrade, make install within ports' tree or source install).
Build MySQL with “BUILD_OPTIMIZED=yes” parameter. This parameter passes more optimized parameters to compiler in order to get better binaries. It's hard to know how much performances are improved, but it can't do any harm.
Build MySQL with “BUILD_STATIC=yes” parameter. This parameter allows MySQL to be compiled with static links to external libraries. Each time this call to these libraries will be made, it won't be needed to search for this library as the link is hard-coded into executable binary. But if one day you update these libraries, you may break these static links, then need to build MySQL again.
Start MySQL without DNS resolution. Each time a client connects to MySQL daemon, it solve client's IP address to hostname. With many simultaneous connections, MySQL must wait for name server answer before execute the query, answer which may be slow to come depending on network or system usage. If you want to disable this reverse DNS resolution, you have to add parameter “--skip-name-resolve” when starting MySQL. Under FreeBSD, just add into file “/etc/rc.conf” the line “mysql_args="--skip-name-resolve"” then restart MySQL.
Setup MySQL memory usage. A database manager need as many RAM as possible: bigger is the cache, quicker are queries execution (it's quicker to access to previous results into RAM than take them from hard disk). But allocate to many memory to MySQL will penalize other system processes. You must find yourself the good values. There are into “/usr/local/share/mysql/” folder many “.cnf” with are many usecase MySQL configuration files. You just have to choose the right file, copy it to “/etc/my.cnf”, and adapt it to your needs. Then restart MySQL.
Allocate more memory to temporary tables buffer (“tmp_table_size” parameter into “/etc/my.cnf” file). This buffer is used to store temporary tables created while executing some queries. If this parameter is set to low, MySQL will use the harddrive, slower than system memory. Default value is set to 32 MB.

MPM and PHP

Since version 2, Apache support many distinct MPM. The most often used are the following ones:

prefork: each time a client connects, a new process is created from the father's one. This new process will load all apache modules into memory. It's the old school way used with Apache 1.3.
worker: each time a client connects, a new thread is created from father's process. This way is less slower than the previous one, because it's not necessary to create a new process with all related Apache modules. As modules are shared between all threads from the same father process, memory usage will be less important.

If you read the previous list, you will want to use worker MPM: less slower, better memory usage, why hesitate ? the problem is that PHP only support prefork MPM, and nothing is guaranteed with worker MPM. It's may work, but it may not. In my case, it perfectly worked with PHP 5.0.x, but didn't worked with PHP 5.1.x. Related symptoms were session lost or blank pages.

Then if you don't want to prematurely loose your hairs, only use prefork MPM. So you may want to stay with Apache 1.3, and you're right. But remember, one day, this version will be obsolete and not supported anymore, and sooner than version 2.0.

PHP and MySQL

You have to ways to connect to a MySQL database: persistent connections, and non persistent connections. A persistent connection is a connection which will stay open until it's explicitly closed (with the related function or when the script ends). If may be useful if you don't want to lose time waiting to open connection again when you need it, but if you have too many simultaneous connexions the MyQSL service may be overloaded.
A non persistent connection is a connection which is open and close each time a query is sent to MySQL. Connection open and close functions are only here to create the variable used to manage the connexion. Unlike persistent connection, you have a slight overhead due to connection opening and closing, but it may be unnoticeable (unless your scripts need to often execute queries). In non persistent connection case, the server will be less often overloaded while getting many simultaneous connections.
In order to disable persistent connections with PHP, you have to set the parameter “mysql.allow_persistent” to “Off” into “/usr/local/etc/php.ini” file.

PHP and memory usage

It may be evident to you, but PHP is memory hungry. After a few quick tries, an Apache process use 7 MB without PHP, and 20 MB with PHP. And don't forget: more you have connections, more you have open Apache processes. With 20 MB per processes, memory usage will grow quickly.

In order to avoid important memory usage, only install PHP modules you need. And if you have problems with a module, you will loose less time to find which one is guilty with few modules than with many. When I write about problems with a module, I mean this: I open a page with use no function from this module, but Apache crashes with an error code 11. If you want to find the guilty module, disable all modules one by one, then restart Apache and reload the page until Apache doesn't crash anymore.

PHP and performances.

PHP is an interpreted language. This means each time a PHP script is opened and executed, PHP engine will need to check the syntax, compile it to a semi-native language ( called “bytecode”), then execute it. For only one PHP script, this syntax check then compilation dedicated time is invisible to the user. But when the web server has to treat hundreds of PHP script within a second, this overhead may be too important.

If you want to accelerate things, there are tools called “PHP accelerators” which optimize PHP scripts loading. When a PHP script is open for the first time, the syntax is checked, it's compiled to bytecode in an optimized may, and this bytecode is saved then executed. Then, each time this script is asked for, PHP engine will use the previously generated bytecode. This time gain may be appreciable.

There are many PHP accelerator. The most known are:

ZendOptimizer. It's a closed source accelerator, made by Zend, the company behind the Zend Engine (the engine used by PHP).
eAccelerator. It's a free PHP accelerator, and it's performances are closed to ZendAccelerator's ones.

I first tried eAccelerator, but had some issues with: cache was not updated, some session loose, etc. With ZendOptimizer, I still have these issues, but less often. Then I don't use any of them.

If you want to use a PHP accelerator, you can accelerate ZendOptimizer if you don't use files protected by ZendGuard. You just have to add into “/usr/local/etc/php.ini” file, within ZendOptimizer section, the following lines:

zend_optimizer.enable_loader=0
zend_optimizer.disable_licensing=0

Apache and AcceptFilter

AcceptFilter is a feature based on kernel options used to optimize HTTP connections (see “accf_http” kernel module for FreeBSD). Said like that, it looks good. But I'm really not convinced: processes memory usage grow (45 MB memory usage per process), processes are opened but never closed (which does not help with memory usage). The only good thing is, when system was not overloaded, that connections seemed to answer quicker. Then disable AcceptFilter. With FreeBSD, it's easy: just add a line

apache22_http_accept_enable="NO"

into “/etc/rc.conf” (“apache22” may change depending the version you use).

Apache and connections limitation.

I just come back to memory use with some trick to avoid server overload:

Add RAM, many RAM. Remember Apache won't be the only running process on your computer, and if you use a database manager, it will be happy with many memory for its buffers. In my case, the server has 1.2 GB of system memory, and MySQL is set to use 512 MB of RAM. To these 1.2 GB of RAM, I added 512 MB of swap.
Think about Apache maximum connections limits. It's useless to let to many clients to simultaneously connect if your server can't handle them. Think about to a maximum of 200 MB swap usage to avoid system overload when it will begin to swap. In my case, I use the following parameterd:
- 512 MB of RAM for Apache processes (1.2 GB - 512 MB for MySQL - 176 MB for other processes). I had 200 MB of swap memory. Apache will be able to access to 712 MB of memory.
- 30 MB per Apache process: 712 / 30 = 24 simultaneous connections. Then I set Apache not to use more than 25 running processes.

Conclusion

I hope these tricks will be useful to you. There are not perfect one because they come from empiric experience.

Apache 2, PHP et FreeBSD : les pièges à éviter (et autres astuces)

Arnaud Boudou — Fri, 06 Apr 2007 08:39:00 +0200

English version

Je ne vais pas présenter de recette miracle, mais juste quelques petits conseils afin d'éviter des situations auxquelles vous pourriez être confrontés. Ce billet pourra se voir mis à jour au cours du temps si je tombe sur d'autres astuces. Ces conseils seront orientés administration, et non pas développement.

billet initialement publié le 22/02/2006

06/04/2007 : ajouts de quelques conseils pour MySQL (buffer table temporaires) et PHP (connexions persistantes)

Configurations concernées

Ces conseils ont été rédigés pour au moins la configuration suivante :

Apache 2.2.3
PHP 5.1.6
MySQL 5.0.24
FreeBSD 6.1-STABLE

Bien entendu, ils sont plus ou moins valables pour d'autres écarts de configurations, mais peuvent tout de même vous donner des pistes de recherche.

Performances de MySQL

Un des défaut de MySQL sous FreeBSD, et qui apparemment ne se produit pas sous GNU/Linux, est l'effondrement de ses performances lors d'un trop grand nombre de requête simultanées. Dans mon cas, avec un Celeron 1,8 GHz et 1,2 Go de mémoire vive, les performances s'écroule à partir d'une trentaine de requêtes simultanées, bloquant la machine.

Le problème semble corrigé avec FreeBSD 7.0, mais il demeure possible d'atténuer ces problèmes pour les autres version de ce système d'exploitation.

Quelques pistes sont possibles:

Compiler MySQL avec le support des threads Linux. Il suffit à l'installation de passer le paramètre « WITH_LINUXTHREADS=yes » lors de l'installation (la façon peut varier selon la procédure d'installation : portupgrade, make install dans l'arbre des ports ou installation depuis les sources).
Compiler MySQL avec le paramètre « BUILD_OPTIMIZED=yes ». Ce paramètre passe des paramètres de compilations plus optimisés que les paramètre par défaut afin d'obtenir un exécutable plus performant. Difficile de chiffre précisément les améliorations apportés, elles doivent dépendre du système.
Compiler MySQL avec le paramètre « BUILD_STATIC=yes ». Ce paramètre compile MySQL avec les liens vers les bibliothèques externes en statique. Chaque fois qu'un appel à ces bibliothèques sera effectué, il n'y aura pas besoin de chercher la bibliothèque, le lien étant en dur dans l'exécutable. En revanche, lors d'une mise à jour des bibliothèques dont dépend MySQL, il y a un risque de casser ces liens statiques, ce qui nécessite une recompilation de MySQL.
Lancer MySQL en désactivant la résolution DNS lors de chaque connexion. En effet, à chaque fois qu'un client se connecte, MySQL effectue une résolution DNS inverse afin de connaître le nom d'hôte à partir de l'IP. Lors de nombreuses connexions simultanées, MySQL doit donc attendre que le serveur de nom réponde avant d'effectuer la requête, réponse qui peut être plus ou moins longue selon l'état du réseau ou la charge système. Pour désactiver la résolution DNS inverse, il faut passer le paramètre « --skip-name-resolve » lors du lancement de MySQL. Pour FreeBSD, rajoutez simplement dans le fichier « /etc/rc.conf » une ligne « mysql_args="--skip-name-resolve" » avant de redémarrer MySQL.
Paramétrer correctement l'utilisation mémoire de MySQL. En effet, plus une base de donnée à de mémoire à sa disposition, plus gros peut être son cache, et donc plus rapides peuvent être l'exécutions de requêtes (il est plus rapide d'aller chercher les résultats précédents en mémoire que d'accéder au disque dur). En revanche, trop allouer de mémoire à MySQL va pénaliser les autres processus du système. Il faut donc trouver un juste milieu. Il existe donc dans le répertoire « /usr/local/share/mysql/ » une série de fichiers à l'extension « .cnf » qui correspondent à des pré-réglages de MySQL pour certaines utilisations pré-définies. Il suffit de choisir le fichier le plus proche de ses besoins, et de le copier sous le nom « /etc/my.cnf », puis éventuellement de l'adapter plus finement à ses besoins. Puis, il faut relancer MySQL pour prendre en compte les nouveaux réglages.
Augmentez la taille de la mémoire allouée au tables temporaires (paramètre « tmp_table_size » dans le fichier « /etc/my.cnf »). Cette zone mémoire sert à stocker les tables temporaires créées lors de certaines requêtes. Si ce paramètre n'est pas assez grand, MySQL se servira du disque dur, plus lent que la mémoire vive. Il est par défaut paramétré à 32 Mo.

MPM et PHP

Apache à partir de sa version 2 supporte plusieurs MPM distincts. Les plus couramment rencontrés sont les suivants :

prefork : à chaque nouvelle connexion, un nouveau processus Apache est créé à partir de l'un des processus père. Ce nouveau processus chargera en mémoire tous les modules Apache présents en configuration. C'est la méthode old school, qui existe dans Apache 1.3.
worker : à chaque nouvelle connexion, un nouveau thread sera créé à partir d'un processus père. Cette méthode à pour avantage d'être plus rapide, car il n'est pas nécessaire de lancer un processus avec tous ses modules associés. Les modules étants partagés entre tous les threads d'un même processus père, l'occupation mémoire s'en retrouve diminuée.

Au vu de la liste ci-dessus, on va naturellement vouloir se tourner vers le MPM worker : plus réactif, moins de mémoire consommée, pourquoi hésiter. Le problème est que PHP ne supporte que le MPM prefork, et n'est absolument pas garanti avec le MPM worker. Ca peut fonctionner, comme ne pas le faire. Personnellement, ça a très bien fonctionné avec PHP 5.0.x, mais pas du tout avec PHP 5.1.x. Les symptômes rencontrés étaient des pertes de session, ou bien des pages blanches.

Donc pour éviter de perdre vos cheveux prématurement pour cause d'arrachage, MPM prefork uniquement. On pourrait se dire que dans ce cas là autant rester avec Apache 1.3. C'est effectivement quelque chose à penser, mais il faut se souvenir que cette version sera un jour ou l'autre abandonnée, et plus vite que la version 2.

PHP et MySQL

Vous avez deux méthodes pour créer des connexions à une base de données : les connexions permanentes, et les connexions non permanentes. Une connexion permanente est une connexion qui restera ouverte tant qu'elle n'est pas explicitement fermée (c'est à dire par l'instruction idoine, ou bien à la fin du script). Ça peut être utile pour gagner du temps en évitant de réouvrir la connexion quand on en a besoin, mais si plusieurs personnes consultent le site, le service MySQL risque de saturer rapidement sous la charge des connexions ouvertes.
À l'inverse, la connexion non permanente s'ouvre et se ferme à chaque instruction SQL envoyée au service MySQL. Les fonctions d'ouverture et de fermeture de connexion de PHP servent dans ce cas à créer ou supprimer la variable gérant les connexions. Contrairement à la connexion permanente, il y a une légère perte de temps lors de l'ouverture et de la fermeture de la connexion, mais ce dernier est négligeable (sauf peut-être si vous avez des scripts qui ont besoin de souvent lancer des requêtes). Dans le cas de la connexion non permanente, vous avez moins de chances de saturer le serveur si celui-ci a de nombreuses visites simultanées.
Pour désactiver les connexions permanentes dans PHP, il faut placer le paramètre « mysql.allow_persistent » à « Off » dans le fichier « /usr/local/etc/php.ini ».

PHP et occupation mémoire

Cela risque de paraître une évidence, mais PHP est lourd. Après quelques essais rapides, un processus Apache occupe 7 Mo en mémoire sans PHP, et 20 Mo avec. Et n'oubliez pas : plus vous aurez de connexions, plus vous aurez de processus Apache ouverts. A coup de 20 Mo par processus Apache, l'occupation mémoire grimpe assez rapidement.

Pour éviter de consommer trop de mémoire inutilement, n'installez que les module PHP qui vous sont nécessaires. De plus, si par hasard un module est problématique, vous aurez plus de chances de trouver lequel est concerné avec peu de modules installés qu'avec beaucoup. Quand je parle de module problématique, c'est dans le sens : j'accède à une page qui ne demande aucune fonction de ce module, mais Apache plante avec un code d'erreur 11. Pour trouver le module gênant, désactivez les modules un à un, puis relancez Apache et rechargez votre page jusqu'à ce que Apache ne plante plus. A une époque j'avais le module PHP Tidy qui me plantait Apache sans raison particulière.

PHP et performances.

PHP est un langage interprété, c'est à dire qu'à chaque fois qu'un script PHP va être lu et exécuté, l'interpréteur PHP va devoir contrôler sa syntaxe, puis le compiler en langage semi-natif ( appelé « bytecode »), puis l'exécuter. Pour un unique fichier PHP, le temps de contrôle puis compilation est négligeable. En revanche, pour un serveur web qui peut traiter plusieurs centaines de fichiers à la seconde, ce temps commence à peser lourd par rapport à celui de l'exécution.

Pour accélérer les choses, il existe ce que l'on appelle des « accélérateurs PHP » dont le rôle principal est d'optimiser le chargement des scripts PHP. Grosso modo, quand un script PHP sera demandé une première fois, sa syntaxe sera contrôlé, il sera compilé en bytecode de manière optimisée, et ce bytecode sera sauvé puis exécuté. Lors de la prochaine demande de ce même script, au lieu de tout recommencer à zéro, l'interpréteur PHP réutilisera le bytecode précédemment généré. Bref, un gain de temps qui peut être non négligeable.

Il existe plusieurs accélérateurs PHP, donc les deux plus connus sont :

ZendOptimizer. Il s'agit d'un accélérateur propriétaire, créé par Zend, la société qui fait aussi le Zend Engine (le moteur de PHP).
eAccelerator. Il s'agit d'un accélérateur PHP libre, dont les performances avoisinent paraît-il celles de ZendAccelerator.

J'ai d'abord essayé eAccelerator, mais j'ai eu quelques problèmes avec : cache non mis à jour, certains liens renvoyaient vers la page d'origine, etc. Avec ZendOptimizer, j'ai toujours ce genre de problèmes, mais de manière moins fréquente. Donc, je préfère n'en utiliser aucun.

En revanche, pour ceux qui veulent sauter le pas, il est possible d'accélérer légèrement ZendOptimizer si l'on ne se sert pas de fichiers cryptés par ZendGuard. Il faut rajouter dans son fichier « /usr/local/etc/php.ini », dans la section correspondant à ZendOptimizer, les lignes suivantes :

zend_optimizer.enable_loader=0
zend_optimizer.disable_licensing=0

Apache et AcceptFilter

AcceptFilter est une fonctionnalité basé sur des options du noyau permettant d'optimiser les connexions HTTP (voir le module noyau « accf_http » pour FreeBSD). Sur le papier, ça a l'air très bien. En revanche en pratique je suis loin d'être convaincu : occupation énorme en mémoire des processus (ils montaient à 45 Mo sans sourciller), processus ouverts mais jamais fermés (ce qui n'aide pas non plus pour la consommation mémoire). Le seul avantage que j'avais trouvé, quand le système n'était pas saturé, était que les connexions semblaient plus réactives. Donc mon conseil est de désactiver AcceptFilter. Pour FreeBSD, c'est facile, placez une ligne

apache22_http_accept_enable="NO"

dans « /etc/rc.conf » (le « apache22 » pouvant changer selon votre version d'Apache).

Apache et les limites en connexion.

Pour en revenir à l'occupation mémoire, quelques pistes pour éviter de mettre son serveur à genoux :

Prévoyez de la RAM, beaucoup de RAM. Pensez qu'Apache ne sera pas le seul processus à tourner sur votre machine, et que si vous utilisez un SGBD, celui-ci sera à l'aise avec beaucoup de mémoire pour son cache. Dans mon cas, le serveur a 1,2 Go de RAM installé, et MySQL est paramétré pour en utiliser 512 Mo à des fins de cache. À ces 1,2 Go de RAM sont associés 512 Mo de swap disque.
Prévoyez des limites en nombre de processus Apache. Ca ne sert à rien de vouloir laisser un nombre immense de connexions se produire si votre système ne peut pas les prendre en charge. En général, prévoyez environ une occupation swap de 200 Mo maximum, histoire de ne pas mettre la machine à genou lorsqu'elle passera son temps à swapper. Dans mon cas, je suis parti sur ces paramètres :
- 512 Mo de RAM pour les processus Apache (1,2 Go - 512 Mo pour MySQL - 176 Mo pour les autres processus). À cela je rajoute 200 Mo de marge en swap. Ca me laisse donc 712 Mo de mémoire pour Apache.
- 30 Mo par processus Apache (je prends un peu de marge) : 712 / 30 = 24 connexion simultanés. J'ai donc paramétré Apache pour ne pas dépasser les 25 processus lancés.

Conclusion

J'espère que ces quelques recettes pourront répondre à vos question. Elles ne sont pas parfaites car venues avec l'expérience.