Auteur | Message |
---|---|
Rano
| Jean ![]() Inscrit le : 13/04/2005 |
# Le 28/03/2009 à 18:13 Merci pour le kernel, je l'ai mis en place pour tester. Il me semble que c'est la première fois que j'essaie d'installer un kernel et que le serveur reboot |
Rano
| Jean ![]() Inscrit le : 13/04/2005 |
# Le 30/03/2009 à 10:48 Finalement, j'ai laissé tombé, ça n'apporte vraiment rien dans mon cas. Akarys a dit : > tu mets LightHttpd sur le port 80 et Apache sur le port 8080. Oui, oui. Je connais cette manip. Ca marche mais ça permet surtout à ralentir (même si très peu) toutes les pages dynamiques... ![]() J'en ai profité pour faire quelques tests avec ab en tapant directement sur apache ou nginx->apache et le résultat est strictement identique. Même avec 100 requetes concurrentes, les résultats sont équivalents. Parfois "apache" plus rapide, parfois "nginx->apache" plus rapide, mais en moyenne je tombe sur les mêmes résultats. Nginx a l'air vraiment optimisé pour ça. |
are
| Aurélien ![]() Inscrit le : 09/03/2009 |
# Le 07/04/2009 à 09:49 Bon.. |
devtribu
| Olivier ![]() Inscrit le : 16/06/2005 |
# Le 07/04/2009 à 09:55
are a dit : Bon.. ![]() J'ai eu le meme probleme avec lighthttpd, je suis revenu en arriere sans trop chercher a comprendre. La charge en full apache est supportable pour le moment Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f |
Bool
| Olivier ![]() Inscrit le : 09/05/2005 |
# Le 07/04/2009 à 10:32 Il me semble que certains IE 6 non à jour (service pack j'sais plus combien) ont un soucis avec le keepalive + la compression, ou une connerie du genre. |
are
| Aurélien ![]() Inscrit le : 09/03/2009 |
# Le 09/04/2009 à 12:07 En effet, ce doit être un truc du genre.. j'ai tester sous IE6/7/8 sans soucis, enfin bon.. je laisse en place car les résultats sont satisfaisant pour notre part ;-) |
petitnuage
| Sam Inscrit le : 20/11/2008 |
# Le 14/04/2009 à 00:50 J'ai tout de même l'impression qu'il s'agit d'une astuce de Sioux qui est adapté à certains services bien particuliers, mais pas à tous les services. Je devine que le gain le plus intéressant en ajoutant lighttpd ou nGinx en plus d'Apache est lorsque le serveur a une bande passante importante tout en ayant peu de fichiers statiques, mais très sollicités, à défaut de quoi l'intérêt est limité. |
are
| Aurélien ![]() Inscrit le : 09/03/2009 |
# Le 23/04/2009 à 12:50
petitnuage a dit : J'ai tout de même l'impression qu'il s'agit d'une astuce de Sioux qui est adapté à certains services bien particuliers, mais pas à tous les services. Je devine que le gain le plus intéressant en ajoutant lighttpd ou nGinx en plus d'Apache est lorsque le serveur a une bande passante importante tout en ayant peu de fichiers statiques, mais très sollicités, à défaut de quoi l'intérêt est limité. N'oublions pas qu'Apache peut être grandement accéléré, ne serait-ce qu'en désactivant les .htaccess dans chaque dossier. Il en va de même avec le PHP qui peut profiter d'un cache code tel que APC que j'utilise avec beaucoup de satisfaction. Une astuce de sioux, peut-être, en tous cas: - quand je charge http://www.hugolescargot.com ![]() => Apache reçoit une requète => Lighttpd en reçoit 85 - quand je charge http://www.hugolescargot.com/coloriages-animaux-na... ![]() => Apache reçoit une requête => Lighttpd en reçoit 129 Et quand tu consulte ces benchmarks : - http://www.howtoforge.com/benchmark-apache2-vs-lig... ![]() - http://www.howtoforge.com/benchmark-apache2-vs-lig... ![]() Tu constate que Lighttpd à une capacité à traiter plus de fichier statique qu'Apache 2.0 ![]() Si j'ai le temps un de ces 4 je testerai Apache2.0+Lighttpd et seulement Apache2.0 via AB, comme cela on sera fixer ![]() |
Liliandev
| Lilian ![]() Inscrit le : 06/03/2009 |
# Le 11/05/2009 à 20:47 Je suis plutôt pour utiliser Nginx que Lighty car Nginx est encore plus léger et plus puissant (cf Benchmarks existants) Lilian | High-Tech |
are
| Aurélien ![]() Inscrit le : 09/03/2009 |
# Le 12/05/2009 à 17:22 Possible, je n'ai pas tester Nginx, peut-être à une autre occasion. |
Bool
| Olivier ![]() Inscrit le : 09/05/2005 |
# Le 12/05/2009 à 17:32 Si tu utilises des applis que tu ne contrôles pas (OpenX par exemple) ou bien que tu penses utiliser les logs Apache, si. |
are
| Aurélien ![]() Inscrit le : 09/03/2009 |
# Le 13/05/2009 à 11:30 Bien vu :-) |
Liliandev
| Lilian ![]() Inscrit le : 06/03/2009 |
# Le 13/05/2009 à 16:04 Ben disons que pourquoi ne pas utiliser un module ? alors que celui-ci fait tout pour toi Lilian | High-Tech |
Rano
| Jean ![]() Inscrit le : 13/04/2005 |
# Le 14/08/2009 à 01:14
Bool a dit : Si tu utilises du Debian 64bits, cadeau : http://apt.daevel.fr:9999/daevel/linux-image-2.6.2... ![]() ... Et comme le fichier config est inclus dans le paquet (merci Debian), tu peux le recompiler à loisir. Petit déterrage ![]() ![]() |
Bool
| Olivier ![]() Inscrit le : 09/05/2005 |
# Le 14/08/2009 à 01:25 * Installation des paquets Debian : aptitude install kernel-package libncurses-dev fakeroot \ * Téléchargement du kernel (depuis http://www.kernel.org/ ![]() wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-... * Reprendre le précédent fichier de configuration (il est dans le /boot/ normalement) : cp /boot/config-xxx .config * Vérifier les éventuelles nouveautés : make oldconfig * Configuration du kernel à proprement parler : make menuconfig * Lancer la compilation : fakeroot make-kpkg clean > /dev/null Tadam, dans les grandes lignes c'est amplement suffisant. J'en ai profité pour ré-uploader mes derniers kernels. La version 2.6.30.4 pour core2 intègre justement LVS. Mais attention, dixit tatave ![]() le kernel qu'ovh propose a une stabilité vis à vis du hardware qu'aucune distribution generique ne pourra proposer. tout ceci se terminera pas de ralage en disant "ovh c'est de la merde". car lorsqu'on parle d'un serveur, on parle de performances et d'une utilisation de resources très importante. et il faut patcher le kernel pour avoir quelque chose qui tient la route 365 jours par an. ça fait parti de la valeur ajoutée de nos offres. c'est notre metier. maintenant si l'instabilitée vous interesse, c'est parti pour les montages russes. (Message édité le 14-08-2009 à 01h33 par Bool) |
Rano
| Jean ![]() Inscrit le : 13/04/2005 |
# Le 14/08/2009 à 01:42 Ouais, j'ai lu ce thread en entier. Depuis ce matin je me bas avec des kernel et je me suis souvenu que tu les avais proposé donc je suis revenu ici |
Rano
| Jean ![]() Inscrit le : 13/04/2005 |
# Le 14/08/2009 à 09:14 Pour LVS apparemment depuis peu OVH oblige à ce que les paquets repassent par le point d'entrée du LVS. Tu confirmes Bool ? Je pense que c'est pour ça que j'ai du mal là. Apparemment on ne peut plus faire ça : http://www.linuxvirtualserver.org/VS-IPTunneling.h... |
Bool
| Olivier ![]() Inscrit le : 09/05/2005 |
# Le 14/08/2009 à 09:31 Oui, ça fait partie de leurs dernières modifs en terme de sécurité il parait. |
abravanel666
| Sylvain Inscrit le : 19/07/2009 |
# Le 14/08/2009 à 09:48 Salut |
MathieuC
| Mathieu ![]() Inscrit le : 15/07/2005 |
# Le 22/10/2009 à 14:33 Je remonte ce sujet car je suis en train d'experimenter avec NginX et j'ai un probleme que je n'arrive pas a resoudre. /etc/nginx/sites-available/default server { listen 80; server_name www.domaine.com; # Les requêtes sont transmises au processus Apache écoutant en local sur le port 8080 location / { proxy_pass http://127.0.0.1:8080/; ![]() include /etc/nginx/proxy.conf; } # On distribue les fichiers statiques directement location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ { root /var/www/domaine.com/; expires 30d; } } /etc/nginx/proxy.conf proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; |
Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.
© MHN - Tous droits réservés | CNIL N°844440 | 24/02/2025 3:57:10 | Généré en 14.77ms | Contacts | Mentions légales |