On peut donner des informations au noyau sur comment on va utiliser des pages de mémoire (random, séquentiel, et sous Linux des choses amusantes comme le "poisoning" d'une région mémoire, pour tester).
Il y a un pendant pour les fichiers, fadvise.

Petit outil livré avec apache pour benchmark un serveur web, avec stats assez lisibles à la fin.

Perso je l'ai attaqué comme ça (pour avoir une page avec accès BDD) :
ab -k -c 100 -n 1000 https://strasweb.fr/actualite/

Et puis à la fin pour nettoyer un peu les kilomètres de log, à coup de 1000 requêtes ça va vite :
sed -i -E '/(ApacheBench|server-status)/d' /var/log/apache2/access.log
EDIT: /!\ attention cela change le fichier (numéro d'inode en tous cas) et après apache a plus l'air de loguer… il faut le relancer a priori…

Setup de php-fpm avec apache 2.4 : faisable mais pas immédiat.

En fait selon les sources on n'a pas les mêmes infos, en particulier concernant le lien entre apache et fpm : socket unix ou TCP ?
Ici (http://www.vincentliefooghe.net/content/configuration-apache-24-php-fpm) on lit que les socket unix sont pas dispo, dans la doc shaarliée que si. D'autres (https://bz.apache.org/bugzilla/show_bug.cgi?id=54101 en bas) disent qu'il faut donner le chemin du document_root à chaque vhost (donc chiant).
Au final en compilant avec encore une autre source (http://z-issue.com/wp/apache-2-4-the-event-mpm-php-via-mod_proxy_fcgi-and-php-fpm-with-vhosts/) on obtient quelque chose de satisfaisant :

• on utilise bien le socket unix (apparemment dispo depuis 2.4.9, on a 2.4.10 dans Debian Jessie), probablement moins d'overhead pour du local.
• on a bien une config globale, en ne donnant pas le chemin de la racine de chaque vhost mais le nom du pool fpm (c'est quoi l'embrouille ?!)

La seule chose à faire donc, à part activer les modules apache, serait de créer une fichier /etc/apache2/conf-available/php5-fpm.conf en mettant :
<FilesMatch ".php$">
SetHandler "proxy:unix:///var/run/php5-fpm.sock|fcgi://www/"
</FilesMatch>

<Proxy fcgi://www/>
</Proxy>
et de l'activer : a2enconf php5-fpm
Ici, "www" est le nom du pool fpm, défini par défaut à l'installation du paquet.

En tous cas chez moi ça marche comme ça, avec le MPM event.

Apache 2.4 est supposé permettre d'utiliser le MPM event en prod' car stable. Ici une explication de ce que ce MPM a de mieux que worker.
En gros il y a un thread spécial qui réagit aux événements sur les socket en attente (connexions en mode keepalive etc. avec epoll ou kqueue), au lieu de laisser ça à chaque thread. Les thread ayant effectué les traitements sont donc libres de travailler à autre chose pendant les temps morts.
A priori ça se remarque avec un apache2ctl status, même avec des sessions en keepalive on ne voit plus de thread marqué 'K' : c'est le thread dédié qui attend, les autres sont dispos.

Tableau de comparaison de libc Linux écrit par l'auteur d'une d'elles, musl (donc pas forcément impartial). J'ai trouvé intéressant quand même, rien que pour la liste des points de comparaison choisis et les notes sur les tests effectués.

Envie de savoir si la compilation a bien profité d'extensions processeur ? Il "suffit" de voir si des instructions spéciales correspondantes sont utilisées. Ici un script bash autour d'un gros coup de grep sur la sortie d'objdump.

Après perso j'ai testé pour AVX et sans avoir spécialement activé AVX il trouvait déjà des instructions … donc je sais pas, peut-être qu'il y en a trop qui sont considérées AVX ?
En tous cas en recompilant avec -march=native, j'avais bien des binaires différents, et même très différents niveau taille (des plus petits, des plus gros…).

"MiniMagAsm is minimalistic, but powerful and flexible content management system ( CMS ), implemented entirely in assembly language. " voila tout est dit :P