Je dois préciser que mes connaissances sur le sujet datent un peu car cela fait 10 ans que je n’héberge plus rien. Mais j’ai lu quelques articles dans la communauté admin sys qui vont exactement dans mon sens.
J’ai quand même auto-hébergé mon blog pendant une décennie. Je me suis pris certains afflux monstrueux (avec des pointes à 100.000 visiteurs uniques sur 2 heures). Mon blog tournait à l’époque sur Wordpress : et bien ça a tenu sans problème particulier autre qu’une surcharge CPU durant ces quelques heures. (si mes souvenirs sont bons, j’avais quand même pas mal chipoté avec monit pour tuer régulièrement les processus apache qui ne répondaient plus)
Après, je n’avais pas de plugins partout, je tentais déjà à l’époque de simplifier mon code et ma gestion serveur en minimisant le nombre de process.
J’ai fait beaucoup d’erreurs. J’ai eu deux fois un serveur que je gérais piraté (un utilisateur qui avait un logiciel php non à jour dans les deux cas). J’ai eu des gros soucis dans ma gestion de backup, dans ma gestion du matériel. J’en ai compris que l’admin serveur c’est hyper difficile, hyper exigeant.
Mais y’a un truc que j’ai appris : la mise à l’échelle et l’optimisation, ça se pense dans le code de l’appli web. Et une appli web mal foutue peut metter à genoux n’importe quelle infrastructure avec quelques dizaines de requêtes.
La mise à l’échelle au niveau des serveurs, c’est un truc hyper compliqué qui peut souvent faire pire que mieux. Un truc que j’ai vu, par exemple : c’est des serveurs redondants qui, à chaque requête, communiquaient entre eux. Du coup, chaque serveur se prenait deux fois plus de requêtes que s’il n’y avait pas eu de de redondance. Ou alors une utilisation foireuse des CDN qui fait que tout le réseau plante si soit le serveur soit le CDN sont surchargés (ça semble être la norme de ce que je vois).
De mon expérience, je soupçonne que le site des JO soit, comme tout site moderne, codé avec les pieds par la boîte du fils du cousin d’un patron du CIO. Que ce code a ensuite été balancé sur un docker car personne ne sait l’installer. On a donné ce docker à un admin sys en stage en lui disant de scaler, alors il a googlé "docker + amason S3", déployer le machin, mit le budget pour laisser Amazon faire la mise à l’échelle sauf que le docker, au moment de la commande, appelle un serveur SQL qui lui est dans un data center et qui sert de goulot d’étranglement mais personne ne sait comment ça fonctionne. Et ça a été facturé 10 millions au CIO.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Solidité
Posté par ploum (site web personnel, Mastodon) . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 8.
Je dois préciser que mes connaissances sur le sujet datent un peu car cela fait 10 ans que je n’héberge plus rien. Mais j’ai lu quelques articles dans la communauté admin sys qui vont exactement dans mon sens.
J’ai quand même auto-hébergé mon blog pendant une décennie. Je me suis pris certains afflux monstrueux (avec des pointes à 100.000 visiteurs uniques sur 2 heures). Mon blog tournait à l’époque sur Wordpress : et bien ça a tenu sans problème particulier autre qu’une surcharge CPU durant ces quelques heures. (si mes souvenirs sont bons, j’avais quand même pas mal chipoté avec monit pour tuer régulièrement les processus apache qui ne répondaient plus)
Après, je n’avais pas de plugins partout, je tentais déjà à l’époque de simplifier mon code et ma gestion serveur en minimisant le nombre de process.
J’ai fait beaucoup d’erreurs. J’ai eu deux fois un serveur que je gérais piraté (un utilisateur qui avait un logiciel php non à jour dans les deux cas). J’ai eu des gros soucis dans ma gestion de backup, dans ma gestion du matériel. J’en ai compris que l’admin serveur c’est hyper difficile, hyper exigeant.
Mais y’a un truc que j’ai appris : la mise à l’échelle et l’optimisation, ça se pense dans le code de l’appli web. Et une appli web mal foutue peut metter à genoux n’importe quelle infrastructure avec quelques dizaines de requêtes.
La mise à l’échelle au niveau des serveurs, c’est un truc hyper compliqué qui peut souvent faire pire que mieux. Un truc que j’ai vu, par exemple : c’est des serveurs redondants qui, à chaque requête, communiquaient entre eux. Du coup, chaque serveur se prenait deux fois plus de requêtes que s’il n’y avait pas eu de de redondance. Ou alors une utilisation foireuse des CDN qui fait que tout le réseau plante si soit le serveur soit le CDN sont surchargés (ça semble être la norme de ce que je vois).
De mon expérience, je soupçonne que le site des JO soit, comme tout site moderne, codé avec les pieds par la boîte du fils du cousin d’un patron du CIO. Que ce code a ensuite été balancé sur un docker car personne ne sait l’installer. On a donné ce docker à un admin sys en stage en lui disant de scaler, alors il a googlé "docker + amason S3", déployer le machin, mit le budget pour laisser Amazon faire la mise à l’échelle sauf que le docker, au moment de la commande, appelle un serveur SQL qui lui est dans un data center et qui sert de goulot d’étranglement mais personne ne sait comment ça fonctionne. Et ça a été facturé 10 millions au CIO.
Mes livres CC By-SA : https://ploum.net/livres.html