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.
por
pobrecito hablador
el Lunes, 18 Abril de 2011, 07:43h
(#1274246)
Tu asumes que el problema que tiene Twitter no puede resolverse con RoR, y yo te digo que lo que pasa es que la gente de Twitter no sabe resolverlo con RoR.
Son dos cosas MUY diferentes.
Si realmente te interesa el tema, busca un poco en Google. Hay entrevistas y comentarios de ex-desarolladores de Twitter y gente que estaba en en núcleo de la empresa (y ahora pacen en pastos más verdes) que te confirmarán lo que te digo.
Respecto a la facilidad de encontrar talento, es es una cuestión de volumen: hay más profesionales con competencias en Java que en Ruby (y Rails).
¿Qué consecuencias tiene eso? Que puedes arrancar algo como Twitter con una pequeña empresa sin muchos recursos teniendo un par de gurús de RoR, pero si los pierdes, es más fácil encontrar media docena de desarrolladores competenes con Java, que sin ser tan buenos como los gurús, resuelven.
Es muy complicado contratar gurús: ya tienen trabajo, normalmente ganan buena pasta, y les cuesta cambiar de curro porque ya trabajan en lo que les gusta. Conozco solo a un par, pero es así.
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:0)Son dos cosas MUY diferentes.
Si realmente te interesa el tema, busca un poco en Google. Hay entrevistas y comentarios de ex-desarolladores de Twitter y gente que estaba en en núcleo de la empresa (y ahora pacen en pastos más verdes) que te confirmarán lo que te digo.
Respecto a la facilidad de encontrar talento, es es una cuestión de volumen: hay más profesionales con competencias en Java que en Ruby (y Rails).
¿Qué consecuencias tiene eso? Que puedes arrancar algo como Twitter con una pequeña empresa sin muchos recursos teniendo un par de gurús de RoR, pero si los pierdes, es más fácil encontrar media docena de desarrolladores competenes con Java, que sin ser tan buenos como los gurús, resuelven.
Es muy complicado contratar gurús: ya tienen trabajo, normalmente ganan buena pasta, y les cuesta cambiar de curro porque ya trabajan en lo que les gusta. Conozco solo a un par, pero es así.
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.