forked from quentin/quentin.dufour.io
longue traine
This commit is contained in:
parent
9e9dcdc3e4
commit
c647db6b43
1 changed files with 1 additions and 1 deletions
|
@ -47,7 +47,7 @@ export default function () {
|
||||||
|
|
||||||
Je n'ai volontairement pas poussé l'infrastructure au maximum, mais on tient sans problème 100 utilisateurs en instantané, ce qui fait ~800req/sec et 8Mo/sec de transfert de données. Sur 1 minute, ça fait 6 000 utilisateurs. Quand on était en page d'accueil sur Hacker News, on a vu que les visites s'étalaient en réalité plutot sur 1h ou 2h, meme si le trafic n'était pas réparti de manière homogene, mais plus sous la forme d'une gaussienne. Sans faire les calculs, je dirais qu'en cas de "coup de projecteur", on peut tenir les ~10 000 utilisateurs sans trop de soucis. En informatique, on pense souvent en terme d'ordres de grandeurs. À mon avis, l'ordre de grandeur suivant, un burst de ~100 000 utilisateurs est imaginables sans remettre en question notre architecture mais avec des améliorations à différents endroits. Par contre l'ordre de grandeur suivant, 1 million, nous forcerait à repenser en profondeur notre système. Toute cette réflexion reste encadrée pour moi par deux articles très importants, [C10K](http://www.kegel.com/c10k.html) et [C10M](https://highscalability.com/the-secret-to-10-million-concurrent-connections-the-kernel-i/). Le premier date de 2003, et constate que les serveurs industriels ont la capacité de supporter 10 000 connexions simultanés, et réfléchit à comment concevoir du logiciel qui permette d'exploiter ces capacités. On pourrait dire que C10M, c'est le même constat entre 10 et 20 ans plus tard, mais que cette fois-ci on est passé à 10 millions de connexions, là encore en remettant encore à plat le logiciel qu'on conçoit. Alors bien sûr, ici on parle de connexions qui ne font pas grand chose, mais quand même, c'est pertinent de savoir où on se situe, surtout en 2024 où on écrit encore des logiciels qui ont du mal à gérer 4 ou 5 connexions simultanées...
|
Je n'ai volontairement pas poussé l'infrastructure au maximum, mais on tient sans problème 100 utilisateurs en instantané, ce qui fait ~800req/sec et 8Mo/sec de transfert de données. Sur 1 minute, ça fait 6 000 utilisateurs. Quand on était en page d'accueil sur Hacker News, on a vu que les visites s'étalaient en réalité plutot sur 1h ou 2h, meme si le trafic n'était pas réparti de manière homogene, mais plus sous la forme d'une gaussienne. Sans faire les calculs, je dirais qu'en cas de "coup de projecteur", on peut tenir les ~10 000 utilisateurs sans trop de soucis. En informatique, on pense souvent en terme d'ordres de grandeurs. À mon avis, l'ordre de grandeur suivant, un burst de ~100 000 utilisateurs est imaginables sans remettre en question notre architecture mais avec des améliorations à différents endroits. Par contre l'ordre de grandeur suivant, 1 million, nous forcerait à repenser en profondeur notre système. Toute cette réflexion reste encadrée pour moi par deux articles très importants, [C10K](http://www.kegel.com/c10k.html) et [C10M](https://highscalability.com/the-secret-to-10-million-concurrent-connections-the-kernel-i/). Le premier date de 2003, et constate que les serveurs industriels ont la capacité de supporter 10 000 connexions simultanés, et réfléchit à comment concevoir du logiciel qui permette d'exploiter ces capacités. On pourrait dire que C10M, c'est le même constat entre 10 et 20 ans plus tard, mais que cette fois-ci on est passé à 10 millions de connexions, là encore en remettant encore à plat le logiciel qu'on conçoit. Alors bien sûr, ici on parle de connexions qui ne font pas grand chose, mais quand même, c'est pertinent de savoir où on se situe, surtout en 2024 où on écrit encore des logiciels qui ont du mal à gérer 4 ou 5 connexions simultanées...
|
||||||
|
|
||||||
Jusqu'ici je parle de trafic soudain, mais pour de nombreux sites, c'est un flux continu. Dans ce cas, les visites sont beaucoup plus espacées dans le temps. Mettons un site web qui s'adresse aux particuliers, d'expérience il verra une large partie de ses visites se faire entre 7h et 9h le matin, lors de la pause méridienne, disons entre 12h et 14h puis surtout le soir, de 18h à 22h, soit au total quand même 8 heures. À 6 000 utilisateurs par minutes parfaitement répartis, ça nous fait 2.9 millions de visiteurs par jours (on suppose que consulter les pages suivantes est négligeable passé la première requête). Bien sûr, mon modèle est très naïf là, et trop imprécis pour affirmer quelque chose de définitif. Mais disons que, dès lors que le trafic se lisse sur la journée, on a pas trop de mal à gérer 1 million d'utilisateurs par jour.
|
Jusqu'ici je parle de trafic soudain, mais pour de nombreux sites, c'est un flux continu. Dans ce cas, les visites sont beaucoup plus espacées dans le temps. Mettons un site web qui s'adresse aux particuliers, d'expérience il verra une large partie de ses visites se faire entre 7h et 9h le matin, lors de la pause méridienne, disons entre 12h et 14h puis surtout le soir, de 18h à 22h, soit au total quand même 8 heures. À 6 000 utilisateurs par minutes parfaitement répartis, ça nous fait 2.9 millions de visiteurs par jours (on suppose que consulter les pages suivantes est négligeable passé la première requête). Bien sûr, mon modèle est très naïf là, et trop imprécis pour affirmer quelque chose de définitif. Mais disons que, dès lors que le trafic se lisse sur la journée, on a pas trop de mal à gérer 1 million d'utilisateurs par jour. Bon, il ne faut pas perdre de vu que ce budget de 1 million par jour, il est à partager entre tout le monde ! Mais là encore, on a les statistiques de notre côté : des abonnements Twitch aux marchandises sur Amazon en passant par la taille des instances Mastodon, on va avoir une [longue traîne](https://fr.wikipedia.org/wiki/Longue_tra%C3%AEne) : un ou quelques sites webs avec beaucoup de visites, et très rapidement toute une myriade de petits sites avec très peu de visites par jour, qui se fondent dans l'épaisseur du trait. On peut donc dimenssionner pour quelques gros sites et le reste suivra.
|
||||||
|
|
||||||
Mon test n'est pas du tout exhaustif ou représentatif de tout le web statique - mais c'est le mieux qu'on ait et on devra s'en contenter pour le moment. Par exemple, un site qui serait beaucou plus lourd (image, audio) pourrait avoir un comportement différent (on atteindrait peut-être une limite de bande passante - à tester), et c'est juste un exemple parmis des milliers de situations possibles (HTTP 2 vs HTTP 1.1 ? Versions & Cipher de TLS ? etc.).
|
Mon test n'est pas du tout exhaustif ou représentatif de tout le web statique - mais c'est le mieux qu'on ait et on devra s'en contenter pour le moment. Par exemple, un site qui serait beaucou plus lourd (image, audio) pourrait avoir un comportement différent (on atteindrait peut-être une limite de bande passante - à tester), et c'est juste un exemple parmis des milliers de situations possibles (HTTP 2 vs HTTP 1.1 ? Versions & Cipher de TLS ? etc.).
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue