Apache vs lighttpd vs nginx

Bonjour, j’ai fait le teste d’apache, lighttpd et nginx sur un applicatif maison car la charge du dédié utilisant cet applicatif est importante et Apache commence à donner des signes de fatigue.

J’ai essayé de rester logique et de me rapprocher de la configuration que j’avais en production.

Les informations:

Server: AMD Phenom(tm) II X4 920 Processor, 12Go de ram ddr2 800MHz, gouvenor cpu performance, raid6 avec 8hdd, kernel 2.6.31-10
Client: Laptop Dell inspirons 1555, intel core2duo P8600, 4GB
Rewrite rules activé, gzip compression pour les fichiers js et css, mod expire, php fastcgi, redirection, alias, auth, status
Via le réseau j’ai vérifié les entêtes, la compression, le cache.. via l’extension webdevelopper de firefox
Les autres réglages sont par défaut sauf:

Nginx:

worker_processes 20;
worker_connections 1200;
partial log
use epoll;
output_buffers  16 32k;
gzip_buffers    16 16k;
access log off for: jpg|jpeg|gif|css|png|ico|js

Lighttpd:

server.max-fds = 5000
server.max-open-files = 1000
server.event-handler = « linux-sysepoll »
no log
« mod_rewrite »,
« mod_redirect »,
« mod_alias »,
« mod_auth »,
« mod_status »,
« mod_setenv »,
« mod_simple_vhost »,
« mod_compress »,
« mod_expire »
For cgi:
« max-procs » => 60,
« PHP_FCGI_CHILDREN » => « 10 »
« PHP_FCGI_MAX_REQUESTS » => « 10 »

Apache:

Worker

Pour nginx j’ai du utiliser php-fpm pour le background fast-cgi de php.

Voilà l’environnement gentoo utilisé:

Gentoo use flags:

www-servers/nginx-0.8.33  USE= »aio fastcgi ipv6 pcre ssl status zlib -addition -debug -flv -imap -perl -pop -random-index -realip -securelink -smtp -static-gzip -sub -webdav »
www-servers/lighttpd-1.4.26  USE= »fastcgi gdbm ipv6 pcre php ssl -bzip2 -doc -fam -ldap -lua -memcache -minimal -mysql -rrdtool -test -webdav -xattr »
www-servers/apache-2.2.14-r1  USE= »ssl static threads -debug -doc -ldap (-selinux) -suexec » APACHE2_MODULES= »actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta -charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http -substitute -version » APACHE2_MPMS= »-event -itk -peruser -prefork worker »

Et voilà les résultats:

Un fichier js avec plusieurs variante d’options, pour voir les fichiers compresser et statique, sauf dans le cas d’un proxy (quoi que ces serveurs n’ont pas été testé comme ça) il faut plus tenir compte de la partie réseau, surtout que le teste est fait via en réseau gigabyte, la bande passante de l’internaute et de votre serveur sera en général inférieure:

En requetes/secondes

Ensuite différente taille de fichier statique non compresser tel que des images:

En requêtes secondes

Et très important le php, interpréter via des rewrites rules ou en 404 not found, les temps de requêtes (les meilleurs sont les plus petits):

temps moyens des requêtes en ms

Le nombre de requêtes qui n’ont pas fonctionné (ayant affiché une page d’erreur au lieu de la page normale):

nombre de requêtes totales n’ayant pas fonctionné

Puis enfin le nombre que requêtes secondes, incluant celle n’ayant pas fonctionné (voir + haut):

nombre de requêtes secondes

Vu que nginx ayant dans ce cas énormément de requêtes n’ayant pas fonctionné, la vitesse ne lui sert à rien.

Conclusion

Apache est à la traîne sur tous les terrains.

Lighttpd: Il est très bon pour la compression de fichiers statiques, car il les met en cache. Le fam permet de ne pas aller voir la date de modification à chaque accès, mais il ne semble pas y avoir de gain. Pour les fichiers normaux il est un peu moins bon de nginx mais largement meilleur qu’apache. Il intègre tout ce qu’il faut pour la gestion et l’intégration de php via fast-cgi.

NginX: Il est très bon pour les fichiers statiques, semble avoir des problèmes à dé-servir les fichiers php avec php-fpm pour fast-cgi server (ou php-fpm qui ne suit pas), il ne profite pas d’un cache pour les fichiers statiques envoyés en compressé ce qui le rend un peu plus lent, par contre lors des benchmarks il a été le seul à tirer partie à 100% de mon cpu multi-coeur, et cela ce ressent dans les fichiers traditionnels et non compresser, tout est prévu en natif, donc pour les serveurs utilisant plein de fonctionnalité c’est très performant.

Attention, dans un cas optimale tout les images sont mis en cache côté navigateur via le mod expire, idem pour les css et php, donc si vos visiteurs reste longtemps et charge plein de pages d’un site, ou si vous avez plein de visites à une page la partie statique ou dynamique sera plus ou moins utilisé en fonction des cas.

Qt 4.6 compilé avec MinGW64 avec wine sous linux

Bonjour,

Vous devez sans doute en avoir mare de devoir lancé un machine virtuelle pour compiler vos application Qt sous windows, avec visual studio et ces dépendances? J’ai la solution, cela permet en autre d’automatiser la création, et donc de tout faire via un .sh:

  • Créer votre futur dossier wine
  • Lancer toujours wine et Qt avec le préfix WINEPREFIX= »/votre/chemin/ »
  • Installé TDM MinGW, et ajouter le à votre variable d’environnement PATH dans regedit en recherche la clef ayant pour nom PATH
  • Compilé le début de Qt en 32Bits avec TDM MinGW pour avoir notamment qmake.exe,uic.exe,moc.exe,rcc.exe en 32Bits
  • Garder ces exe dans un dossier à part, lancer une commande watch pour les recopier à intervalle régulier dans dans le dossier bin/ de Qt car avec la version MinGW64 c’est des exe 64Bits qui vont être généré, donc incompatible avec un wine 32Bits
  • renommer votre dossier MinGW
  • Installez MinWG64 la version snapshot la plus récente en MinGW-w64-mingw-i686.zip ou un truc comme ça
  • Copier tout les binaires dans bin/ de votre dossier MinGW qui est en 32Bits pour cible 64Bits et renommer les copies sans le mingw……- devant
  • Faite un mingw32-make distclean
  • lancer le configure puis le make comme pour une installation traditionnelle
  • Quand tout est compilé arréte le script qui ecrase vos binaires dans le dossier bin/ de Qt

J’ai rencontrer les erreurs suivantes:

  • Avec Qt 4.6.1 j’ai du désactivé le mmx, sse, sse2

Pour pouvoir avoir un maximum de compression du binaire final j’ai fait en static, pour notamment pouvoir le compresser avec upx en lzma quand upx supportera les binaires windows 64Bits.

Cette article vous permet aussi avec quelque adaptation de compiler Qt en 64Bits sous windows sans avoir besoin de visual studio en 64Bits, donc potentiellement d’utiliser Qt Creator ou tout autre IDE Qt portable basé sur MinGW.

Teste de vserver sous gentoo avec un invité debian

Bonjour,

Je viens de tester vserver sous linux gentoo pour héberger exclusivement des debians. Ca permet de remplacer la virtualisation par l’isolation, pour gérer efficace l’espace disk et éviter de ce trimbaler avec un gros hdd virtuel.

Mes 1ere sont impression sont:

  • Bien plus flexible
  • Bien plus performant qu’une solution avec nfs
  • Gentoo comme invité est adapté (via un stage4), mais debian pas du tout, il faut le faire à la main
  • Pas de firewall pour le système invité (tout est dans l’hôte) donc pas de fail2ban, ou applicable depuis l’hote
  • Petit problème sous debian avec le nom d’hôte à fixer à la main
  • Patch grsec non applicable, patch très important en isolation car le noyau de l’hôte est directement exposé au pirate dans le système invité
  • Fichier de configuration complet/long à prendre en main

Ajout d’ultracopier à l’overlay gentoo sunrise

Bonjour, après un dur travail avec l’équipe de l’overlay sunrise pour gentoo, que je remercie au passage, j’ai le plaisir de vous annoncer un ebuild de meilleur qualité et peu étre l’intégration dans l’overlay sunrise.

J’espère que cela débouchera sur l’inclusion d’ultracopier dans gentoo. J’espère aussi inciter les autres distributions à inclure les packets dans leur distribution.

Test de KDE 4.4 et KpackageKit pour gentoo et portage

Bonjour, je suis en train de tester l’overlay kde pour gentoo (en kde 4.3.82 car les autres il manque trés souvent les sources), de nombreux bug à signalé.

PyKDE ne marche pas, et de nouveau packet que je ne connait pas bloque à la compilation.

Et concernant Kpackagekit, l’installation que j’ai fait à la main ne semble pas marché, je teste via l’overlay et des le 1er packet j’ai:

../../src/eggdbus/eggdbustypes.h:31:38: error: eggdbus/eggdbusenumtypes.h: No such file or directory

Pas de bol.

Pour dolphin activé le use flag semantic-desktop et faite emerge -av nepomuk

ATI Radeon 4570 Mobile sous linux

Aprés une trés longue attente pour le support de ma ATI Radeon 4570 de mon portable dell inspiron 15 (studio 1555) sous linux, j’en vois enfin le bout.

Je suis sous gentoo amd64 avec un kernel 2.6.33 (et mesa 7.7 rc3, lib drm 2.4.16) qui active enfin la 3D en openGl 1.5 ce qui est déjà un début, et le signe que le DRM du kernel marche maintenant. Attention, ne pas activé KMS sous peine de crash kernel du genre:
radeon 0000:01:00.0: Fatal error during GPU init
[drm] radeon: finishing device
BUG: unable to handle kernel NULL pointer dereference at 0000000000048
IP: [] ttm_bo_reserve+0x18/0xec
PGD 0
Oops 0000 [#1] PREEMPT SMP
...
Call trace:
printk
rv770_suspend
rv770_fini
radeon_device_fini
radeon_driver_unload
radeon_driver_load_kms
drm_get_dev
local_pci_probe
..........

La transparence est bien plus rapide, j’ai 1500 sous glxgears, et trés peu d’extension openGL d’activé. Mais je suis déjà content d’avoir ça car ça avance. Je suis pressé d’avoir la 3D complétement pour KDE et aussi la gestion d’énergie de ma carte 3D.

Si non pour le reste du matos en général c’est bien supporté, controleur ahci, … et c’est bien optimisé, je note ce pendant:

  • conflicts with ACPI region SMBI
  • Virtualisation activé dans le bios mais pas sous linux car dans le dmesg il me dit que c’est désactivé dans le bios