OVH Cloud OVH Cloud

[Apache] Server web charge

33 réponses
Avatar
Panic
Hello,

je cherche une solution pour faire un serveur web, efficace.

On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.

Qqun a une idée ? :)

Tks,
Panic.

10 réponses

1 2 3 4
Avatar
Panic
DDM wrote:

sans hésitation FreeBSD.


Pour une/plusieures raison(s) en particulier ? :)

Panic

Avatar
DDM
je cherche une solution pour faire un serveur web, efficace.

On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.


sans hésitation FreeBSD.

DDM

Avatar
DDM
Panic wrote:

DDM wrote:


sans hésitation FreeBSD.



Pour une/plusieures raison(s) en particulier ? :)

c'est vrai que ma réponse était rapide.

Comme je ne suis pas encore chez moi, je ferais encore une réponse ...
rapide. D'ailleurs je suis étonné que personne n'ai répondu pour vanter
les mérites des BSD.
Différents tests trouvés sur Internet sur la charge d'un serveur mettait
souvent FreeBSD vainqueur.
Une partie de ces tests ont été refait par un petit groupe avec des
moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat,
windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus
souvent le mieux.
Il faudrait que je retrouve un semblant de lien pour preuve. ( et que
les herbergeurs présents sur cette liste nous donne un avis...)

DDM


Avatar
manu
Panic wrote:

On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant
aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres pour edition(emacs)/transfert(scp) de leurs fichiers.


Les trois font l'affaire. BSD est stable, BSD supporte la charge, et les
3 BSD sont des BSD. Si j'ose dire.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3


Avatar
M.D
Dans l'article <blhn64$17q$,
disait...
Panic wrote:

DDM wrote:


sans hésitation FreeBSD.



Pour une/plusieures raison(s) en particulier ? :)




Pour:
L'extremement bonne qualité et cohérence de sa documentation.

Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)


c'est vrai que ma réponse était rapide.
Comme je ne suis pas encore chez moi, je ferais encore une réponse ...
rapide. D'ailleurs je suis étonné que personne n'ai répondu pour va nter
les mérites des BSD.
Différents tests trouvés sur Internet sur la charge d'un serveur mett ait
souvent FreeBSD vainqueur.
Une partie de ces tests ont été refait par un petit groupe avec des
moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat,
windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus
souvent le mieux.



<off topic>
Juste par curiosité: En quoi un Linux Debian avec le même
noyau et les mêmes outils, le même FS peut-il être plus
performant qu'un Linux RedHat ou Mandrake ?
</off topic>

--
Marc



Avatar
Erwan David
M.D écrivait :

Dans l'article <blhn64$17q$,
disait...
Panic wrote:

DDM wrote:


sans hésitation FreeBSD.



Pour une/plusieures raison(s) en particulier ? :)



Pour:
L'extremement bonne qualité et cohérence de sa documentation.

Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)


Euh le noyau GENERIC fourni a tout ce qu'il faut pour ipf ou
ipfw. Bon c'était pas le cas pour ipf en 4.2, mais maintenant y'a plus
à recompiler le noyau pour ça.




Avatar
pornin
According to M.D :
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)


Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).


<off topic>
Juste par curiosité: En quoi un Linux Debian avec le même
noyau et les mêmes outils, le même FS peut-il être plus
performant qu'un Linux RedHat ou Mandrake ?
</off topic>


En l'occurrence ce n'est pas exactement le même noyau. Chaque
distributeur Linux propose un ensemble de logiciels sous forme de
packages, configurés et ajustés par le distributeur, et le noyau ne
fait pas exception. Autrement dit, RedHat fournit des noyaux avec
des patchs "RedHat", Mandrake fournit des noyaux avec des patchs
"Mandrake", etc... Il y a aussi des paramètres configurables via
sysctl ou /proc, et qui influent sur la performances.

Le fond de commerce de RedHat et (surtout) Mandrake, c'est le poste
utilisateur, donc ces distributeurs favorisent l'interactivité, parfois
au détriment des performances dans les usages de type "serveur". Ceci
peut expliquer que Debian s'en sorte mieux sur les tests de charge de
serveur.

Quant aux filesystems, justement, ils ont tendance à ne pas utiliser
les mêmes. Debian tourne par défaut en ext2, qui est très rapide (en
lecture comme ne écriture) mais peu sûr en cas de coupure de courant.
Les gros serveurs sont de toutes façons sur un UPS donc ce n'est pas
un problème ; les coupures de courant arrivent surtout sur les postes
utilisateurs, parce que l'utilisateur se prend les pieds dans le câble
d'alimentation. Donc, pour les mêmes raisons de "marché", RedHat et
Mandrake privilégient les filesystems plus sûrs et fournissant la
meilleure "user experience" (donc les filesystems journalisés, qui
évitent un long fsck au reboot) mais dont les performances sont un peu
en dessous.

Et puis il y a la mémoire. Une RedHat ou une Mandrake, par défaut,
lance plus de choses qu'une Debian. Ça part rapidement dans le swap,
mais ça augmente la pression sur le système de gestion de mémoire
virtuelle, et ça peut se sentir (un peu) sur les performances.

Tout ceci contribue à faire de Debian un OS plus performant que Redhat
et Mandrake pour un serveur. Notez bien que j'ai dit "performant" ; je
n'ai pas dit "adapté".


Sinon, je recommande effectivement FreeBSD. Il est un peu plus optimisé
que les autres BSD sur PC, et surtout il gère nettement mieux les PC à
plusieurs processeurs. Quand on a un serveur avec pas mal de charge, on
a souvent envie de mettre deux ou quatre processeurs en batterie.


--Thomas Pornin

Avatar
Erwan David
(Thomas Pornin) écrivait :

According to M.D :
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)


Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).


Même pas, le module ipf existe de base...


Avatar
talon
Thomas Pornin wrote:
According to M.D :
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)


Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).



Plus exactement, sous FreeBSD-5.1 on est obligé de recompiler un noyau
pour utiliser ipfilter (*), mais sous FreeBSD-4.8 il suffit de charger le
module ipl.ko. En réalité les scripts de démarrage se chargent de faire
kldload ipfw.ko ou kldload ipl.ko, donc il y a juste besoin de le
mentionner dans /etc/rc.conf et de renseigner les fichiers de règles.

(*) Ceci à cause d'une option PFILL_HOOKS qui manque dans le noyau
générique, de façon trés inappropriée.

--

Michel TALON


Avatar
Eric Masson
"Erwan" == Erwan David writes:






Erwan> Même pas, le module ipf existe de base...

Pour une 4, c'est effectivement finger in ze noze.

Mais comme le disait Michel Talon récemment, sur une 5, l'option
PFIL_HOOKS est devenue obligatoire pour pouvoir charger un packet filter
autre qu'ipfw et cette option n'est pas intégrée dans GENERIC.

Tu me diras qu'une 5 n'est pas faite pour un environnement de
production, certes.

Eric Masson

--
fgu> Je reviens sur mon post de 11h27 : Au lieu de :"2ème DD en
fgu> Secondary Master (SM)" ce serait plutôt : "2ème DD en Primary Slave
fgu> (PS)"
-+-<http://www.le-gnu.net>-La dialectique du maître et de l'esclave -+-





1 2 3 4