dl.google.com est écrit en Go qui sert pour tous les téléchargements de Google (dont les mises à jour de Chrome)
C'est intéressant. En fait il n'ont fait presque qu'un code glue autour de groupcache et les API étant bien faites, il n'a pas besoin de faire de copies intermédiaires entre groupcache et la réponse HTTP. Ce qui joue nettement sur le débit ce qui est leur priorité. J'ai pas vu d'endroit où il parlait de la manière dont il charge les données depuis VCS.
C'est marrant, il parle d'utiliser un système de fichiers distribué, mais n'en utilise pas.
Pour ce qui est des event loop :
il parle du fait que l'event loop était bloquée. Si tu utilise un paradigme et que tu le viole tu va avoir des problèmes. Si dans 2 ans, ils commencent à faire des recopies en usespace de données, leur débit va en pâtir
il parle du débit limité par l'event loop, la présentation de sozu y fait écho en expliquant qu'ils ne font pas non plus de passage par le userspace grâce à splice(2)
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 1.
C'est intéressant. En fait il n'ont fait presque qu'un code glue autour de groupcache et les API étant bien faites, il n'a pas besoin de faire de copies intermédiaires entre groupcache et la réponse HTTP. Ce qui joue nettement sur le débit ce qui est leur priorité. J'ai pas vu d'endroit où il parlait de la manière dont il charge les données depuis VCS.
C'est marrant, il parle d'utiliser un système de fichiers distribué, mais n'en utilise pas.
Pour ce qui est des event loop :
splice(2)Sympa, au final ils ont une perf inférieure à nginx. J'aime bien les conclusions du bench qu'ils mettent en avant :
Mais c'est un reverse proxy qui a l'air super sympa (plus que sozu pour mon usage perso), je vais l'essayer.