Bonjour à tous,
Nouvel arrivant ici, travaillant régulièrement sous debian pour la mise en place de serveur Web (dédié ou VPS).
J'ai mis en place des dizaines et des dizaines de serveurs avant GPT et après. Sauf que je me pose la question de savoir quels sont les configurations nécessaires pour faire tourner un serveur rapide avec du cache, pouvant supporter une assez grosse charge sans pour autant avoir le trafic de Google.
Par exemple voici mon serveur actuel :
CPU : Intel Xeon E5-1650v4 - 6c/12t - 3.6 GHz/4 GHz
RAM : 64 Go ECC 2133 MHz
Disques de données : 2×450 Go SSD NVMe
Soft RAID
Merci à tous les Linuxien :D
# la question ?
Posté par NeoX . Évalué à 4 (+2/-1).
tu as une machine, et tu veux heberger du web ? avec ou sans php ?
partagé avec des utilisateurs simple utilisateurs (mutualisé) ?
ou tu veux dédiés des droits à tes utilsiateurs (VPS) ?
dans le premier cas, tu gardes ton debian, tu installes un panneau de config (virtualmin, plesk, cpanel), toi tu es root, eux sont utilisateurs et verrouillés dans leur dossier
dans le 2e, tu met de la virtualisation (KVM ou LXC) pour dedié des espaces à tes users,
ils seront root de leur emplacement.
perso pour le 2e j'aime bien proxmox,
tu peux avoir une machine, demain si t'en veux un 2e ou faire une migration, tu installes le 2e proxmox, tu montes un cluster entre les deux, et tu bascules tes KVM/LXC de l'un vers l'autre
[^] # Re: la question ?
Posté par kazouillepourt (site web personnel) . Évalué à 0 (+0/-1).
Merci pour ta réponse.
Alors j'ai déjà des serveurs web pour mes sites installés. La question est de les rendre le plus performant possible, avec php-fpm, un cache au petits-oignons. Je ne fais pas de mutualisé, que du VPS et dédié.
D'ailleurs, j'ai jamais utilisé de panneau de config, je fais un peu tout en root (ou en sudo), c'est vraiment si pratique que ça?
Les KVM, c'est pour partager un serveur en plusieurs par exemple? Genre une ip pour chaque espace?
Je sais pas si ma demande est très claire.
[^] # Re: la question ?
Posté par NeoX . Évalué à 5 (+2/-0).
alors c'est pas tant que site web que le code derriere qui va intervenir et la base de données si y en a une
par defaut, mysql par exemple est livrée en mode "developpement" en gros peu de concurrence, un cache limité, etc, il faut aller tuner la config pour etre plus "performant" et "production ready"
cf les docs de mysql/mariadb
le design de la base de donnée va ensuite jouer un role evidemment,
mais la maniere dont le code traite les pages, dont les images sont optimisées ou non, etc
c'est un peu comme un powerpoint,
j'ai vu des gens faire un diaporama de leur photo de vacances et ne pas comprendre que le fichier fait 5Go à la fin ?
tout simplement parce que les images etaient directement issue de l'appareil photo, sans reduction de taille, pour mettre dans un powerpoint en 1920x1080 quand la photo de base est en 12Mpx (3072x4096)
bref avant d'en arriver à optimiser le serveur web, il y a un monde avant :D
[^] # Re: la question ?
Posté par volts (Mastodon) . Évalué à 3 (+1/-0).
Ici, on parle de ce KVM.
Ça sert à "découper" un dédié en plusieurs VPS (d'où le sigle "Virtual Private Server" pour "Serveur Privé Virtuel"). Eh oui, derrière un VPS, c'est un dédié qui se cache ;) .
En revanche, l'attribution des adresses IP est indépendante de KVM, c'est une autre partie du noyau (la pile réseau) qui s'en charge.
[^] # Re: la question ?
Posté par kazouillepourt (site web personnel) . Évalué à 0 (+0/-1).
Merci pour la précision,, c'est bien ce que je pensais. Effectivement, l'ip n'est pas obligatoire, mais comme je fais gaffe a Google, il n'apprécie pas trop la mutualisation des serveurs.
[^] # Re: la question ?
Posté par Voltairine . Évalué à 4 (+2/-0). Dernière modification le 05 juin 2025 à 08:18.
Google ne pénalise pas la mutualisation des sites derrières une même IP. Une source parmi de très nombreuses autres :
https://www.seroundtable.com/sharing-ip-addresses-shared-servers-google-seo-37171.html
[^] # Re: la question ?
Posté par kazouillepourt (site web personnel) . Évalué à 0 (+0/-1). Dernière modification le 09 juin 2025 à 15:53.
He bien merci, je le saurais, au prix ou je paye mes 15aines d'ip tous les mois…
C'est toujours ça de pris en économie
# Prendre lighttpd ?
Posté par volts (Mastodon) . Évalué à 4 (+2/-0).
Lighttpd est un serveur web orienté performance, disponible en paquet chez Debian et Ubuntu.
À vue de nez, votre serveur est très largement suffisant pour faire tourner lighttpd avec ses règlages de base.
Toutefois, si vous constatez des soucis en cours de déploiement, il y a une page spéciale dédiée à l'optimisation en dernier recours des performances.
# mieux définir le problème
Posté par Krunch (site web personnel) . Évalué à 9 (+7/-0). Dernière modification le 04 juin 2025 à 19:30.
Ça veut dire quoi « une assez grosse charge » et « le plus performant possible » ? C'est quoi le but en fin de compte ? Tu as des chiffres concrets sur la charge que tu peux supporter actuellement avant d'avoir optimisé ?
Selon les réponses, il y a des optimisations qui sont plus ou moins pertinentes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mieux définir le problème
Posté par kazouillepourt (site web personnel) . Évalué à 1 (+1/-1).
C'est pour faire tourner un prestashop de 50.000 produits en 7 langues. Le site est naissant, mais sur les grosses bases de données, ça sature un peu, les requêtes sont assez longues sur les pages catégories par exemple.
[^] # Re: mieux définir le problème
Posté par Krunch (site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 04 juin 2025 à 21:10.
Expliqué comme ça, on dirait que le goulet d'étranglement est au niveau de la base de données plutôt que du serveur web. Je commencerais par regarder la nature exacte des requêtes qui sont faites. Et s'il n'y a rien à faire de ce côté (ce qui m'étonnerait parce que 50k entrées ça pourrait limite tenir dans un CSV qu'on parse à chaque requête si on refait pas le boulot 42 fois), on peut commencer à envisager de cacher ces requêtes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mieux définir le problème
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
C'est clair qu'il faut optimiser les requêtes. Optimiser cela veut aussi dire réduire le nombre de requêtes : Regarder les indexs/jointures, éviter les sous-requêtes…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# C'est super intéressant
Posté par poupou . Évalué à -1 (+0/-2).
salut!
c'est super intéressant tout ça.
vous avez des ressources, sous forme de livres, articles, site internet, à conseiller pour se former dans le domaine?
je cherche à comprendre un peu mieux les différents systèmes de serveur et ainsi pouvoir faire des choix pour mettre en place un système qui correspond à mes envies.
je vous remercie.
poupou
[^] # Re: C'est super intéressant
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0).
Si c'est de la curiosité, je recommande de commencer par bidouiller son propre serveur le plus simple possible. Après tu peux commencer à scaler au besoin en t'inspirant de ce que font les autres.
Personnellement dans les années 2000 j'ai commencé avec des articles de Linux Magazine France puis j'ai lu des trucs comme C10K, LiveJournal, digg, fefe,… avant que ça ne devienne mon boulot.
Tout ça date et les chiffres de l'époque semblent ridicules. Mais les problèmes techniques restent fondamentalement les mêmes.
De nos jours ça parle beaucoup de cloud et la dimension dans laquelle on se retrouve vite à avoir des problèmes de scaling est plutôt « comment je fais pour gérer ces centains/milliers de composants et pourquoi 92% de mon budget part chez Amazon ? » Si on veut garder un minimum le contrôle je pense qu'il reste important de comprendre ce qui se passe en dessous et de rester sur le système le plus simple possible qui corresponde aux besoins.
Mais sinon, en cherchant « large scale system design » on tombe sur des trucs tels que https://github.com/donnemartin/system-design-primer qui ont l'air pertinents.
En pratique, si je voulais me faire la main indépendamment de nos jours, je regarderais du côté du Fediverse/Mastodon. Il y a plein de problèmes de scaling intéressants qui ne nécessitent pas de bosser pour un « géant du web ».
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.