{"id":8565,"date":"2016-07-15T12:44:47","date_gmt":"2016-07-15T12:44:47","guid":{"rendered":"https:\/\/dev.railscarma.com\/ruby-rails-scaling-app-rapid-growth\/"},"modified":"2021-06-06T12:02:02","modified_gmt":"2021-06-06T12:02:02","slug":"ruby-rails-mise-a-lechelle-de-lapplication-a-croissance-rapide","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/fr\/blog\/articles-techniques\/ruby-rails-mise-a-lechelle-de-lapplication-a-croissance-rapide\/","title":{"rendered":"Ruby on Rails\u00a0: faire \u00e9voluer votre application pour une croissance rapide"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tAugmenter la croissance d\u2019une application est aujourd\u2019hui un sujet vraiment intimidant. La plupart des ressources Internet et des articles de blog tournent autour de la mise \u00e0 l'\u00e9chelle des applications Ruby. Il est tr\u00e8s int\u00e9ressant de savoir quel est le plafond et combien Ruby on Rails peut r\u00e9aliser pour la croissance rapide des applications.\n\nLa mise \u00e0 l'\u00e9chelle augmente non pas par la vitesse mais par le d\u00e9bit<\/strong>\n\nLes h\u00f4tes \u00e9volutifs n'acc\u00e9l\u00e8rent les temps de r\u00e9ponse que lorsque les demandes passent beaucoup de temps \u00e0 attendre d'\u00eatre servies par les applications. S\u2019il n\u2019y a aucune demande existante en attente de service, la mise \u00e0 l\u2019\u00e9chelle n\u2019est qu\u2019un gaspillage d\u2019argent. Ruby on Rails fait \u00e9voluer correctement les applications de 1 \u00e0 1 000 requ\u00eates par minute et ce que nous devons savoir sur ce processus de mise \u00e0 l'\u00e9chelle est la mani\u00e8re dont le routage HTTP et les serveurs d'applications fonctionnent r\u00e9ellement.\n\nComment les requ\u00eates sont-elles achemin\u00e9es vers les serveurs d\u2019applications\u00a0?<\/strong>\n\nUne d\u00e9cision importante \u00e0 prendre en termes de mise \u00e0 l'\u00e9chelle d'une application Web avec Ruby est le type de serveur d'applications que vous devez choisir. La plupart des messages de mise \u00e0 l'\u00e9chelle de Ruby peuvent \u00eatre obsol\u00e8tes en raison du changement radical survenu au cours des 5 derni\u00e8res ann\u00e9es et du changement \u00e9clair de l'ann\u00e9e derni\u00e8re. N\u00e9anmoins, nous comprenons toujours les avantages existants de chaque choix de serveur d'applications. Nous devons simplement mieux comprendre comment ces requ\u00eates sont achemin\u00e9es vers de tels serveurs d'applications. De nombreux d\u00e9veloppeurs comprennent encore mal le processus exact de mise en file d'attente et d'acheminement de ces requ\u00eates.\n\nCycle de vie des demandes<\/strong>\n\nUne fois qu'une requ\u00eate arrive \u00e0 votre application Heroku, le premier endroit o\u00f9 elle s'arr\u00eate est l'\u00e9quilibreur de charge. Le travail d'un \u00e9quilibreur de charge est de garantir que la charge entre les routeurs de Heroku est r\u00e9partie uniform\u00e9ment. Cet \u00e9quilibreur de charge transmettra la demande \u00e0 l'un des routeurs qui lui convient le mieux. Il existe un nombre \u00e9norme de routeurs Heroku non divulgu\u00e9s et nous pouvons supposer d\u00e8s maintenant que ce nombre est assez important, environ sup\u00e9rieur \u00e0 100. Le travail des routeurs consiste \u00e0 s'adresser aux dynos de l'application et \u00e0 transmettre la requ\u00eate \u00e0 un certain dyno. La localisation des dynos peut prendre une \u00e0 cinq minutes et les routeurs tenteront de se connecter \u00e0 un dyno al\u00e9atoire dans l'application. Lorsque Heroku a d\u00e9j\u00e0 choisi un dyno al\u00e9atoire, il attend cinq secondes que le dyno r\u00e9clame la demande et \u00e9tablisse une connexion ouverte. Pendant que la requ\u00eate attend, elle sera plac\u00e9e dans la file d'attente des requ\u00eates du routeur.\n\nChoix du serveur d'applications<\/strong>\n
    \n \t
  • Webrick<\/li>\n \t
  • Mince<\/li>\n \t
  • Licorne<\/li>\n \t
  • Passager Phusion 5<\/li>\n \t
  • Puma (filet\u00e9)<\/li>\n \t
  • Puma (regroup\u00e9)<\/li>\n<\/ul>\nChacun de ces serveurs varie en termes de vitesse, mais tous peuvent traiter des milliers de requ\u00eates chaque minute. Les applications de mise \u00e0 l'\u00e9chelle ne sont pas uniquement bas\u00e9es sur les temps de r\u00e9ponse. L'application peut ralentir en raison de l'augmentation des files d'attente de requ\u00eates. Les files d\u2019attente de demandes doivent \u00eatre v\u00e9rifi\u00e9es en premier, car si elles sont vides, ce sera une perte de temps et d\u2019argent. Ceci s\u2019applique \u00e9galement aux h\u00f4tes de travail. Ils sont mis \u00e0 l'\u00e9chelle en fonction d'une file d'attente de t\u00e2ches approfondie.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Abonnez-vous pour les derni\u00e8res mises \u00e0 jour<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \t\t\t\t\t