Auteur Sujet: Référentiel général de l’écoconception des services numériques (Lu 2209 fois)

vivien · « **Réponse #12 le:** 13 octobre 2023 à 13:34:00 »

L'hébergement mutualisé en 2007 / 2008 n'était souvent pas adapté pour des services tel qu'un forum.

On était limité en requêtes PHP et en taille de base SQL (25 Mo par base de mémoire).

Je me souviens de plusieurs services que j'ai aidés, car ils ne trouvaient pas de solution dans le mutualisé et à l'époque il était courant de demander aux services un peu gourmands de passer sur un serveur dédié.

Je ne sais pas si ont peu retrouver de vieux messages sur ce sujet et je n'ai pas suivi ce que proposent les hébergeurs mutualisés, car cela a fortement évolué.

alain_p · « **Réponse #13 le:** 13 octobre 2023 à 13:54:23 »

Citation de: Leon le 13 octobre 2023 à 13:26:20

De plus, héberger plusieurs sites web sur un seul serveur physique, c'est très très ancien comme concept. Ca n'est pas nouveau, ça n'est pas une tendance récente. Les hébergement mutualisé, ça existe en tant qu'offre commerciale depuis plus de 20 à 25 ans (oh, fichtre, je suis vieux). Même sans virtualisation, ça existait.

Oui, je sais, hôte virtuel. Mais là, tu héberges ton site sur un serveur physique qui consomme 200 W. A côté, tu veux l'héberger sur un serveur de virtualisation "hyperconvergé" qui consomme 1000 W. Où est le gain en consommation ?

Après, tout dépend du site web, et de la puissance de traitements/ressources dont il a besoin.

vivien · « **Réponse #14 le:** 13 octobre 2023 à 14:01:32 »

Mon serveur consomme 40 à 50 watts hors période de déni de service, pas 200 watts.

Sur un serveur hyperconvergé qui consomme plusieurs centaines de watts, on va mettre de nombreux clients.

alain_p · « **Réponse #15 le:** 13 octobre 2023 à 14:03:27 »

Oui, mais en fait au lieu de rassembler 10 serveurs physiques sur un seul, tu vas faire héberger 1000 sites sur autant de serveurs physiques, qui consomment chacun 1000 W...

alain_p · « **Réponse #16 le:** 13 octobre 2023 à 14:07:14 »

Quelques statistiques Forbes pour 2023, 1.13 milliards de sites web, 1 nouveau créé toutes les 3s. :

Citer

Top Website Statistics For 2023

...
General Website Statistics
1. There are about 1.13 billion websites on the internet in 2023

While there are 1.13 billion websites in the world[1], only a fraction of these are actively used and updated. A staggering 82% are inactive, meaning only 200,121,724 of the 1.13 billion websites are actively maintained and visited.
2. A new website is built every three seconds

Assuming you read 300 words per minute (WPM), by the time you finish reading this article, 200 websites have been created.[1]
...

https://www.forbes.com/advisor/business/software/website-statistics/

alain_p · « **Réponse #17 le:** 13 octobre 2023 à 14:10:12 »

En fait, un spécialiste des sites web "légers" (en fait à faible latence), c'est Google, avec le célèbre exemple de sa page de recherche minimaliste.

Mais donc là, c'est plutôt pour réduire la latence, pour faire adopter ses services en priorité, que pour des raisons écologiques, car derrière, il consomme beaucoup...

PeGGaaSuSS · « **Réponse #18 le:** 13 octobre 2023 à 14:13:13 »

Citation de: kgersen le 13 octobre 2023 à 12:26:28

Le numérique a quelle part dans le total des émissions et consommation des ressources ?
Est-ce qu'on ne monopolise pas trop de gens et de compétences a s'occuper de cela au lieu de les mettre sur d'autres domaines qui sont plus impactants ?

Oh que si. Mais bon c'est sur que c'est plus simple de s'enfermer là dedans que de réaliser que ce que tu fais dans ta vie pro n'a aucune utilité pour la société.
Pendant longtemps on aurait pu croire qu'au pire c'était juste du gâchis de ressources (financières et humaines), mais la semaine écoulée prouve qu'en fait ce genre de distraction est mortifère, pour les individus et la société. Sans parler des conséquences "effet de bord" qui ne sont jamais prises en compte et qu'on prends la tronche que bien après.

alain_p · « **Réponse #19 le:** 13 octobre 2023 à 14:13:37 »

Citation de: kgersen le 13 octobre 2023 à 12:26:28

Le numérique a quelle part dans le total des émissions et consommation des ressources ?

On avait cité des projections il y a quelque temps, peut être de RTE, où les projections pour 2035 je crois, parlaient de 10% de l'électricité produite consommée par les datacenters.

Leon · « **Réponse #20 le:** 13 octobre 2023 à 17:36:37 »

Citation de: alain_p le 13 octobre 2023 à 14:03:27

Oui, mais en fait au lieu de rassembler 10 serveurs physiques sur un seul, tu vas faire héberger 1000 sites sur autant de serveurs physiques, qui consomment chacun 1000 W...

Je crois qu'on a compris, ça fait 4 fois que tu reformules la même idée. L'effet rebond, tout ça, tout ça.

Citation de: vivien le 13 octobre 2023 à 13:34:00

L'hébergement mutualisé en 2007 / 2008 n'était souvent pas adapté pour des services tel qu'un forum.

On était limité en requêtes PHP et en taille de base SQL (25 Mo par base de mémoire).

Je me souviens de plusieurs services que j'ai aidés, car ils ne trouvaient pas de solution dans le mutualisé et à l'époque il était courant de demander aux services un peu gourmands de passer sur un serveur dédié.

Je ne sais pas si ont peu retrouver de vieux messages sur ce sujet et je n'ai pas suivi ce que proposent les hébergeurs mutualisés, car cela a fortement évolué.

Tu parles des hébergements mutualisé type OVH? Pourtant, plusieurs forums assez conséquent tournaient sur les mutu OVH à l'époque.
Même s'il y a eu de (très) gros plantages sur l'hébergement mutu, et des problèmes récurrents sur l'équilibrage de charge des serveurs, la qualité semblait être au rendez-vous globalement.
OVH fournissait, en 2008, des bases SQL jusqu'à 250Mo sur le Mutu, voir capture d'écran.
https://web.archive.org/web/20081114164709/http://www.ovh.com/fr/particulier/produits/sql_large.xml

L'hébergement mutualisé Free fonctionnait assez mal, en cas de process PHP gourmand, et aussi côté bases de données, ce qui est logique vu que ça a toujours été gratuit.

Je sais qu'à cette époque (2008), certains hébergeurs proposaient des VPS managés basés sur OpenVZ pour des sites web assez conséquent avec base de donnée. Donc ressources mutualisées mais potentiellement avec de bonnes performances.

Leon.

vivien · « **Réponse #21 le:** 13 octobre 2023 à 18:32:21 »

Sur l'hébergement Start1G, la base de donnée est de 5 Mo :

Même en passant sur un hébergement pro, il y a 5 base de données, mais de 40 Mo chacune :

Catalyst · « **Réponse #22 le:** 13 octobre 2023 à 18:54:25 »

Citation de: vivien le 13 octobre 2023 à 13:34:00

Je ne sais pas si ont peu retrouver de vieux messages sur ce sujet

Quand tu es passé du mutu au self hosting :

https://lafibre.info/evolution/serveur-pour-lafibre-info/?PHPSESSID=6kjcaaseln0gjvn493a2gf8fkm

vivien · « **Réponse #23 le:** 13 octobre 2023 à 19:48:15 »

Merci Catalyst, donc voici ce qui posait problème pour un hébergement mutualisé :

Citation de: vivien le 01 mars 2007 à 23:59:08

Suites aux problèmes rencontrés avec l’hébergement OVH mutualisé, l'hébergement du forum est effectué sur mon serveur perso, qui dispose d'une connexion citéFibre.

[...]

Pour les problèmes avec OVH, ils limitaient les requêtes en base de donnée a 3 requêtes en //, ce qui limite la monopolisation des ressources par un seul client mais qui est insuffisant pour ce forum.
La base de donnée a ensuite été purement désactivé par OVH qui trouvait qu'elle demandait une charge trop importante pour un hébergement mutualisé "Start10G".

Citation de: vivien le 03 mars 2007 à 10:25:22

Je ne pense pas que la saturation chez OVH soit du à la bande passante mais plutôt au temps de traitement du code PHP (génération des pages par le CPU) ou serveur mysql saturé (en mutualisé chez OVH les serveurs sont séparés en 3 : NAS pour le stockage des fichiers, serveurs MySQL pour les bases et serveur Apache/PHP)

De temps en temps j'avais une page avec une erreur en guise de page d'accueil (obligation de faire un reload), pour moi c'étais soit un time-out soit PHP (si la page est trop longue a générer, il la zap. c'est fortement visible sur les pages perso free pour les grosses pages en PHP étant donné que ces serveur ont un time-out court et qu'ils sont surchargés) ou MySQL.