Je serais assez étonné qu'ils n'aient pas des gens qui
connaissent très bien les interpréteurs des navigateurs et
c'est le même qui est utilisé côté serveur.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Parce que perdre de la RAM, ça peut aller côté client (dans une
certaine mesure, parce que ça veut dire quand même que
certaines personne ne pourront pas accéder au site), mais
perdre du CPU, ça veut dire que le temps d'affichage va
augmenter.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 5.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.