Hace poco Oracle anunció el lanzamiento de Oracle Mix, la que según afirman es la aplicación más grande desplegada con JRuby on Rails.
Ayer, Rich Manalang, escribía una entrada en el blog de desarrolladores de Oracle en la que relataba lo que ha sido el camino hasta tener esta aplicación en producción.
Rich explica como después del éxito de Connect, la red social de Oracle se pusieron a trabajar en una aplicación para la Oracle OpenWorld. Tenía que hacerse en seis semanas, la aprobaron y contrataron los servicios de ThoughtWorks que puso cuatro desarrolladores con experiencia.
La lectura es interesante, aunque probablemente la parte más jugosa es la del rendimiento. Me permito traducir.
Después de tener las máquinas preparadas comenzamos a hacer los primeros despliegues de JRuby. El rendimiento era terrible. Entre 20-40 req/sec. en un único servidor de aplicaciones. Parece que no había activado algunos de los parámetros de producción (parámetros estándar para despliegues ruby). Conseguí 80 req/sec. en un único servidor... mejor, pero no suficiente. Al mismo tiempo, Ola y el equipo de JRuby encontraron algunos cuellos de botella interesantes dentro del código de JRuby. En un día o dos, Ola y el equipo habían parcheado el código y estabamos ya funcionando sobre las 150-200 req/sec. Después de que el servidor se calentase un poco las cosas se pusieron realmente interesantes... los números subieron un montón (400-600 req/sec).
Para mi una de las conclusiones que saco es que a pesar del desarrollo rápido, estas tecnologías están un poco inmaduras para determinadas cosas. A fin de cuentas, el hardware no era malo del todo: 4 máquinas doble núcleo, con 12 Gb de RAM, la base de datos era Oracle 10g y es de esperar que estuviera bien configurada :-) y aún así parece que hubo que tunear bastante. Y no todo el mundo se puede permitir el tener 4 consultores de ThoughtWorks on-site durante seis semanas. ¡Que estos ingleses trabajan más que por el bocadillo!
Este proceso que relatan es el que se está viendo en la mayor parte de lenguajes dinámicos surgidos durante los últimos años. Al final, todo tiene su tiempo. Esta gente con recursos y posibilidades va haciendo despliegues importantes y con sus recursos encontrando cuellos de botella y aportando parches. Poco a poco los lenguajes se van haciendo maduros, las máquinas virtuales funcionarán cada vez mejor, y pasarán a ser de consumo público.
Ahora bien, supongo que después todo el mundo los empezará a utilizar, dejará de ser especial el trabajar en ellos, y habrá que buscarse otra cosa mejor ;-)
jueves, noviembre 22, 2007
Suscribirse a:
Enviar comentarios (Atom)
Subscríbete al feed
Regístrate con Feedburner y recibirás por email todas las novedades
Comentarios Recientes
Recent Comments
Etiquetas
- programación (190)
- Arquitectura (90)
- java (78)
- Otros (76)
- empresa (62)
- sistemas (61)
- escalabilidad (56)
- agile (54)
- emprendedores (48)
- Irlanda (42)
- Open Source (31)
- google (27)
- empleo (26)
- humor (24)
- amazon (22)
- eventos (22)
- metodologías (22)
- fun (21)
- rendimiento (21)
- software (21)
- dublin (20)
- testing (18)
- startups (17)
- galicia (15)
- hadoop (15)
- spring (15)
- datacenter (14)
- seguridad (14)
- unit testing (14)
- web 2.0 (14)
- cloud computing (13)
- grails (13)
- jobsket (13)
- libros (13)
- Ingeniería (12)
- eclipse (12)
- facebook (12)
- bases de datos (11)
- virtualización (11)
- yahoo (11)
Archivo de Entradas
-
►
2011
(58)
- ► septiembre (5)
-
►
2009
(61)
- ► septiembre (3)
-
►
2008
(129)
- ► septiembre (11)
-
▼
2007
(217)
-
▼
noviembre
(21)
- Multi-tenancy: diseñando con la escalabilidad en m...
- ApacheCon 07 y web frameworks
- La lista de la verguenza: Top 100 Software vendors
- Reemplazando Flash con Applets y comparación de re...
- Historia sobre una aplicación en JRuby on Rails de...
- Notas sobre la arquitectura de Linkedin
- Transparencias de QCon San Francisco 2007
- Transparencia ante ataques de seguridad
- Caso friendster: ¿Fueron los programadores o los d...
- Patrones de acceso y las 10 mejores maneras de est...
- Dryad, la alternativa a MapReduce de Microsoft
- GigaSpaces ofrece gratis su plataforma a Startups
- IJTC 2007, día 3
- IJTC 2007, día 2
- IJTC 2007, día 1
- Amazon S3 en Europa, 10 millones de objetos y algu...
- OpenSocial, ¿lanzamiento prematuro?
- Sobre feeds y la protección de contenidos
- Una razón algo más técnica para no escribir método...
- Los sin sentidos de VMWare respecto al Open Source
- IJTC 2007 en Dublin
- ► septiembre (17)
-
▼
noviembre
(21)
Mi CV
Cosas que leo
List
También tenemos una tienda de Colchones y Sofás en Betanzos
comments
1 Respuestas a "Historia sobre una aplicación en JRuby on Rails de Oracle"10:13
Mi experiencia con una aplicación en JRuby es Mingle de Thoughtworks precisamente. Y es lenta de cojones, pero lenta, lenta, lenta!!! Posteé en mi blog sobre el tema y el mismísimo Charles Nutter (líder de JRuby) me dijo que la gente de Thoughtworks le comentó que era porque la aplicación era muy compleja.
Y una mierda va a ser eso complejo. Es un agujero negro de memoria y recursos ¡con un solo usuario necesitas 2Gb de RAM y un procesador de doble nucleo! ¿Nos hemos vuelto locos?
Creo que el problema se debe al uso y abuso del ActiveRecord. El MySQL echa chispas, y me temo que la aplicación no hace un uso óptimo de la base de datos.
Probablemente se pueda optimizar el JRuby, pero Rails es optimizable? Esa es la gran cuestión.
Yo me quedo con Grails.
Publicar un comentario