El hecho de que hayan reducido el tiempo de respuesta de 800ms a 250ms y reduciendo el uso de CPU a la mitad no ha tenido absolutamente nada que ver, verdad? lo hacen porque asi pueden contratar a mas gente. claro.
No es mala publicidad para RoR, es simplemente la confirmacion de que Rails esta muy bien en muchos casos, pero para backend en entornos de muchisimo trafico (twitter tiene mas de 1000 millones de peticiones diarias) es mejor usar otras opciones.
Como curiosidad, la arquitectura que han montado ahora se parece muchisimo a la que tenemos en mi departamento, trabajo en el backend de un buscador que, aunque no tenemos el trafico de twitter ni de lejos, si que tenemos mas de 100 millones de usuarios y recibimos unas 800 peticiones por segundo de media.
En mi caso no tenemos necesidad de usar la rama de tiempo real de Lucene (aunque mirare las aportaciones que han hecho, a lo mejor nos interesa migrar), pero lo de las llamadas sincronas me ha dolido.
--
Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
En TFA hablan de un cambio de arquitectura y una especializacion. Peras y manzanas. El titular es sensacionalismo contra Ruby.
para backend en entornos de muchisimo trafico es mejor usar otras opciones.
Esto es FUD. Ese entorno de muchisimo trafico ha estado usando -y sigue usando- Ruby, y un framework de caracter generalista. Ahora han modificado la arquitectura para atender a sus necesidades con algo _especializado_ (ellos mismos explican QUE hacian en los hilos en Ruby y que hacen ahora), y eso es mucho mas significativo que la tecnologia usada, y como prueba ahi tienes los detalles sobre los frameworks "generalistas" utilizados en Java.
Existen ya multiples opciones en el mundo de Ruby que tienen todas las ventajas del lenguaje *y* que ademas rinden. El trabajo en Rubinius o JRuby es un buen ejemplo (y para el que quiera lo mismo que la JVM, ahi esta Mirah). El canto de que Ruby no escala para estos entornos es pasado, como, por cierto, lo ha sido durante mucho mas tiempo el mismo canto sobre Java.
Si nos ponemos en los extremos, estoy muy seguro de que una buena implementacion en C daria sentido a la frase "Java esta bien para muchos casos, pero para backend en entornos de muchisimo trafico es mejor usar otras opciones".
El hecho de que hayan reducido el tiempo de respuesta de 800ms a 250ms y reduciendo el uso de CPU a la mitad no ha tenido absolutamente nada que ver, verdad? lo hacen porque asi pueden contratar a mas gente. claro.
Tambien han migrado de mysql a lucene, gran parte de la reducción del tiempo de busqueda puede ser por eso simplemente. Una consulta mal hecha a la bd puede dar como resultado que de 50ms pases a tardar 500ms.
-- Si no obtienes respuesta sera porque no la mereces.
Re:antes de crucificar a Rails
(Puntos:2, Interesante)( http://barrapunto.com/ | Última bitácora: Lunes, 24 Febrero de 2014, 10:03h )
No es mala publicidad para RoR, es simplemente la confirmacion de que Rails esta muy bien en muchos casos, pero para backend en entornos de muchisimo trafico (twitter tiene mas de 1000 millones de peticiones diarias) es mejor usar otras opciones.
Como curiosidad, la arquitectura que han montado ahora se parece muchisimo a la que tenemos en mi departamento, trabajo en el backend de un buscador que, aunque no tenemos el trafico de twitter ni de lejos, si que tenemos mas de 100 millones de usuarios y recibimos unas 800 peticiones por segundo de media.
En mi caso no tenemos necesidad de usar la rama de tiempo real de Lucene (aunque mirare las aportaciones que han hecho, a lo mejor nos interesa migrar), pero lo de las llamadas sincronas me ha dolido.
Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
Re:antes de crucificar a Rails
(Puntos:2)( http://www.flawedcode.org/ )
para backend en entornos de muchisimo trafico es mejor usar otras opciones.
Esto es FUD. Ese entorno de muchisimo trafico ha estado usando -y sigue usando- Ruby, y un framework de caracter generalista. Ahora han modificado la arquitectura para atender a sus necesidades con algo _especializado_ (ellos mismos explican QUE hacian en los hilos en Ruby y que hacen ahora), y eso es mucho mas significativo que la tecnologia usada, y como prueba ahi tienes los detalles sobre los frameworks "generalistas" utilizados en Java.
Existen ya multiples opciones en el mundo de Ruby que tienen todas las ventajas del lenguaje *y* que ademas rinden. El trabajo en Rubinius o JRuby es un buen ejemplo (y para el que quiera lo mismo que la JVM, ahi esta Mirah). El canto de que Ruby no escala para estos entornos es pasado, como, por cierto, lo ha sido durante mucho mas tiempo el mismo canto sobre Java.
Si nos ponemos en los extremos, estoy muy seguro de que una buena implementacion en C daria sentido a la frase "Java esta bien para muchos casos, pero para backend en entornos de muchisimo trafico es mejor usar otras opciones".
Unix have fun [barrapunto.com]
Re:antes de crucificar a Rails
(Puntos:2)( http://www.fsf.org/ | Última bitácora: Domingo, 09 Mayo de 2004, 05:32h )
Tambien han migrado de mysql a lucene, gran parte de la reducción del tiempo de busqueda puede ser por eso simplemente.
Una consulta mal hecha a la bd puede dar como resultado que de 50ms pases a tardar 500ms.
Si no obtienes respuesta sera porque no la mereces.