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.

Crash de ultracopier sous windows

Bonjour, hélas je repousse la sortie d’ultracopier, car sous windows il y as des crash sur les version récente.

Sous windows il y a utilisation de Qt 4.6.0, alors que pour développer j’utilise Qt 4.5.3 sous linux. J’espère que les problèmes vienne juste de Qt.

Au menu de la prochaine version:

  • Réglage de la taille de bloque par défaut à 1024Ko pour moins d’utilisation de cpu
  • Ajout de nombreuse langue (celle tirer des statistiques du site)
  • Résolution de nombreux bug lié à l’application d’une langue
  • Mise en cache des traductions au endroit clef pour optimisé les performances
  • Et de nombreuse autre corrections

J’essaye de fini le plus rapidement possible tout ces bugs pour sortir la version finale.

Version 0.2.0.11 d’ultracopier

Bonjour, normalement c’est enfin la dernière version avant la final.

Et je vais pourvoir enfin me concentrer sur la réalisation des plugins.

Les nouveautés dans cette version sont:

  • Peu enchaîné 2 copie dans la même fenêtre à la suite
  • Meilleur prévention du bug de blocage
  • Plus de commentaire de la source du thread de copie
  • Le packet debian ne dépend plus du CFLAGS et CXXFLAGS de l’hôte de compilation
  • Pour windows 32Bits, utilisation de la version statique de Qt aussi
  • Réparation de la mise à jour de l’image du bouton play/pause

Lib qt pour la lecture du lzma et du tar

Bonjour, je viens enfin de finir mal lib pour la lecture du lzma et du tar, les 2 peu étre lu indépendamment, il y a un minimum de contrôle d’erreur, tout est minimisé pour prendre le moins de place possible et pour étre le plus claire possible, pour rester au maximum multiplateforme et léger cette limitation sont en place, par exemple seul les fichiers dans les archives tar sont supporté.

Cela vas me permettre de commencer à supporter un certain nombre de chose sous ultracopier, comme l’importation des ressources. Bien sur après avec fixer le dernier bug de la version actuelle.

Tout est commenté pour que des développeurs c++ puis comprendre l’algorithme.

Lien:

http://files.first-world.info/qt-project/lzma-decode-qt-src.tar.bz2

Bug fix pendant le developpement du support des plugins

Bonjour, j’ai sortie une nouvelle version, et je développe à coté le support des plugins et de l’updater pour ultracopier.

Elle corrige un certain nombre de bug cité dans l’un des post juste avant. Donc notamment sur Mac.

Pour le support des nouveaux truc, je pense passer pour l’instant par .tar.lzma, xml, http, … tout ce que qt supporte ou tout ce que j’ai coder à coté en Qt.

Lib lzma en Qt pour la décompression

Bonjour,

Le SDK lzma étant peu ou mal documenté, j’ai perdu énormément de temps à comprendre sont fonctionnement. C’est un prérequit pour le support des plugins dans ultracopier.

J’ai donc décidé de refaire ma propre lib en Qt pour l’utiliser de façon synchrone ou asynchrone avec un thread. Tout semble correctement marché. Un légère interface affiche la taille d’entrée et celle de sortie. Mais en interne tout est bien décodé, c’est juste pas utilisé. Voila l’url que vous attendez tous:

lzma-decode-qt-src.tar.bz2

Je pense faire de même pour les archives tar, un interface Qt, synchrone pour y accéder.

Divers bug d’ultracopier sous Mac

Bonjour, hélas aprés avoir tester ultracopier sous Mac j’ai noter de nombreux bug mineur:

  • Ressources manquantes dans l’application
  • Sous Mac un .app en interface est un fichier, alors que en gestion c’est un dossier, ce qui pose certain problème à ultracopier
  • Impossible de réutilisé un fenêtre qui à déjà été utilisé mais pas fermé

Amélioration noté:

  • Moins de priorité pour plus de simplicité
  • Version debug pour Mac

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