Discussion :

[Aquarius77]

Bonjour,

J'aurais quelques questions concernant la compilation d'Apache sous Linux.

En faisant ./configure --help on obtient toutes les options de compilation.
Sur le site d'apache, il est fait mention de l'option suivante:
--enable-nonportable-atomics=yes

Je ne retrouve pas cette option dans le configure. Elle semble pourtant améliorer les performances. Est-elle déconseillée ? Un oubli dans le configure ?

Toujours dans le configure on a l'option:
-enable-static-support

Ca semble impacter les utilitaires apache mais je ne comprends pas bien à quoi ça sert ?

En compilant également php avec apxs on obtient le "shared object" php_mod.so.
Le truc c'est que moi j'essaye de compiler en static les modules, pour me passer de mod_so.
Y'a-t-il un moyen de convertir mod_php.so en librairie statique pour ensuite transmette cette librairie à la phase de link d'apache avec par exemple
LDFLAGS ou LIBS ?

Exactement la même question pour la compilation de php avec support opcache qui génère là encore un fichier so.

J'ai lu qu'en théorie il faut éviter d'utiliser les mpm worker et event avec mod_php (non thread safe). Est-ce toujours d'actualité ? Plantage assuré ?

Sinon dans la conf d'apache il y a l'option followsylinks. J'ai lu qu'il était préférable de laisser cette option qui permet de suivre les liens symboliques. Mais si on n'a pas de liens symboliques dans son arborescence www ? y'a-t-il un risque de sécurité si on désactive l'option ? est-ce que ça dégrade les perfs ?
Même question pour la directive DirectoryIndex. Si on ne la précise pas (et qu'on veille à pointer sur des fichiers), y'a-t-il des impacts sur les perfs ?

Merci d'avance à celui ou ceux qui se pencheront sur mes questions.

[Marc3001]

Beaucoup de questions en perspective ;-)

En faisant ./configure --help on obtient toutes les options de compilation.
Sur le site d'apache, il est fait mention de l'option suivante:
--enable-nonportable-atomics=yes

Je ne retrouve pas cette option dans le configure. Elle semble pourtant améliorer les performances. Est-elle déconseillée ? Un oubli dans le configure ?

Je dirais un oubli du configure... A utiliser sur Linux/x86 ou Sparc. Ca limite grandement les cas.... Je doute que tu en aies besoin...

Toujours dans le configure on a l'option:
-enable-static-support

Ca semble impacter les utilitaires apache mais je ne comprends pas bien à quoi ça sert ?

Comme pour les modules les binaires support (htpasswd, checkgid, rotatelogs,...) seront compilés statiquement plutôt que dynamiquement. Ca peux impacter les perfs si ta conf fait usage intensif de ces binaires.... A part des cas bien spécifiques, je doute que tu y voies une différence de perfs.

En compilant également php avec apxs on obtient le "shared object" php_mod.so.
Le truc c'est que moi j'essaye de compiler en static les modules, pour me passer de mod_so.
Y'a-t-il un moyen de convertir mod_php.so en librairie statique pour ensuite transmette cette librairie à la phase de link d'apache avec par exemple
LDFLAGS ou LIBS ?

Il faut lancer le configure de php en lui spécifiant le chemin des sources apache et compiler apache en lui spécifiant le chemin des sources php. Modop ici.

Exactement la même question pour la compilation de php avec support opcache qui génère là encore un fichier so.

Comme au dessus. Tu peux jouer avec le configure de php avant de lancer la compile d'apache.

J'ai lu qu'en théorie il faut éviter d'utiliser les mpm worker et event avec mod_php (non thread safe). Est-ce toujours d'actualité ? Plantage assuré ?

PHP n'est pas thread safe, il faut donc éviter de l'utiliser avec les mpm multi-threadé si activé via le module mod_php. Cela ne fera pas planter apache au démarrage mais tu peux avoir des soucis de plantage/incohérence de données au cours de la vie du process.
Tu peux utiliser ces mpm si tu utilises un autre myen que mod_php comme fpm et fcgi par exemple. Je crois savoir qu'au niveau perfs c'est même mieux que mod_php + mpm_worker (A tester).

Sinon dans la conf d'apache il y a l'option followsylinks. J'ai lu qu'il était préférable de laisser cette option qui permet de suivre les liens symboliques. Mais si on n'a pas de liens symboliques dans son arborescence www ? y'a-t-il un risque de sécurité si on désactive l'option ? est-ce que ça dégrade les perfs ?

Aucun impact sur les perfs. Si tu n'as aucun lien symbolique et ne prévois pas d'en utiliser, il vaux mieux désactiver l'option. Le risque apparaît si elle est activée et non l'inverse.

Même question pour la directive DirectoryIndex. Si on ne la précise pas (et qu'on veille à pointer sur des fichiers), y'a-t-il des impacts sur les perfs ?

Aucun impact sur les perfs, ça autorise ou non les clients à lister les répertoires

[Aquarius77]

pour tes explications Marc

En faisant ./configure --help on obtient toutes les options de compilation.
Sur le site d'apache, il est fait mention de l'option suivante:
--enable-nonportable-atomics=yes
Je ne retrouve pas cette option dans le configure. Elle semble pourtant améliorer les performances. Est-elle déconseillée ? Un oubli dans le configure ?
Je dirais un oubli du configure... A utiliser sur Linux/x86 ou Sparc. Ca limite grandement les cas.... Je doute que tu en aies besoin...

je compile sur du x86_64...du coup je sais pas trop.

Toujours dans le configure on a l'option:
-enable-static-support
Ca semble impacter les utilitaires apache mais je ne comprends pas bien à quoi ça sert ?
Comme pour les modules les binaires support (htpasswd, checkgid, rotatelogs,...) seront compilés statiquement plutôt que dynamiquement. Ca peux impacter les perfs si ta conf fait usage intensif de ces binaires.... A part des cas bien spécifiques, je doute que tu y voies une différence de perfs.

Le truc c'est que j'essaie avec et sans cette option, et quand je fais un "ldd" ou un "file" sur l'un des utilitaires j'obtiens la même chose (shared libs, link dynamic)...je précise que j'active aussi le static sur les utilitaires dans le configure.

Pour le modop fourni il n'est malheureusement valable qu'avec Apache 1.x. Avec apache 2.x la compil php doit passer par l'option apxs2, qui ne génère plus que le libphp5.so...j'essaye de voir si il y aurait un moyen de préciser à la compil que je voudrais aussi avoir la librairie statique libphp5.a.

Je poursuis mon enquête, et je me prépare à un nouveau run de questions