Ruby on Rails: scalare la tua app per una crescita rapida

Al giorno d'oggi, la scalabilità della crescita di un'app è un argomento davvero intimidatorio. La maggior parte delle risorse Internet e dei post di blog ruotano attorno al ridimensionamento delle applicazioni Ruby. È molto interessante sapere qual è il limite massimo e quanto Ruby on Rails può ottenere per la rapida crescita delle applicazioni. La scalabilità aumenta non in base alla velocità ma al throughput Gli host scalabili stanno accelerando i tempi di risposta solo quando le richieste trascorrono molto tempo in attesa di essere servite dalle applicazioni. Se non ci sono richieste esistenti in attesa di servizio, il ridimensionamento si rivela solo uno spreco di denaro. Ruby on Rails scala correttamente le applicazioni da 1 a 1.000 richieste al minuto e la cosa considerevole che dobbiamo sapere su questo processo di scalabilità è la quantità di come funzionano effettivamente il routing HTTP e i server delle applicazioni. Come vengono instradate le richieste ai server delle applicazioni? Una decisione importante da prendere in termini di scalabilità di un'applicazione web con Ruby è il tipo di server delle applicazioni che devi scegliere. La maggior parte dei post di ridimensionamento di Ruby potrebbero essere obsoleti a causa del cambiamento drammatico avvenuto negli ultimi 5 anni e del cambiamento vorticoso dell'anno scorso. Tuttavia, comprendiamo ancora i vantaggi esistenti di ciascuna scelta di server applicativo. Dobbiamo solo essere più informati su come vengono instradate queste richieste a tali server delle applicazioni. Molti sviluppatori hanno ancora poca comprensione dell'esatto processo di come queste richieste vengono accodate e instradate. Ciclo di vita delle richieste Una volta che una richiesta arriva alla tua app Heroku, il primo posto in cui si ferma è il bilanciatore del carico. Il compito di un bilanciatore del carico è garantire che il carico tra i router di Heroku sia distribuito uniformemente. Questo bilanciatore del carico trasmetterà la richiesta a qualsiasi router adatto ad esso. Esistono un numero enorme di router Heroku non divulgati e possiamo supporre in questo momento che il numero sia piuttosto elevato, approssimativamente superiore a 100. Il lavoro dei router è quello di eseguire il banco prova dell'applicazione e passare la richiesta a un certo banco prova. Potrebbero essere necessari da uno a cinque minuti per individuare i banchi prova e i router tenteranno di connettersi con un banco prova casuale nell'applicazione. Quando Heroku ha già scelto un lancio casuale, attende cinque secondi affinché il lancio rivendichi la richiesta e stabilisca una connessione aperta. Mentre la richiesta attende, verrà inserita nella coda delle richieste del router. Scelte del server applicativo

• Webrick
• Magro
• Unicorno
• Phusion Passeggero 5
• Puma (filettato)
• Puma (raggruppato)

Ciascuno di questi server varia in termini di velocità, ma tutti possono gestire migliaia di richieste ogni minuto. Le applicazioni di scalabilità non si basano solo sui tempi di risposta. L'applicazione può rallentare con l'aumento delle code di richieste. Le code di richiesta dovrebbero essere controllate prima perché se fossero vuote, sarebbe uno spreco di tempo e denaro. Ciò è applicabile anche agli host lavoratore. Vengono ridimensionati in base alla coda di lavoro approfondita.