Your SlideShare is downloading. ×
Grails, opción real y escalable para sitios web de alta carga
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Grails, opción real y escalable para sitios web de alta carga

1,700
views

Published on

Presentación hecha en la reunión 22 de SpringHispano y Grails.org.mx, donde hablo acerca de un proyecto donde se uso Grails para la totalidad.

Presentación hecha en la reunión 22 de SpringHispano y Grails.org.mx, donde hablo acerca de un proyecto donde se uso Grails para la totalidad.

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,700
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
33
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. De cero a 1.7 M de usuariosGrails, opción real para sitios web de alta carga y escalabilidad. Una experiencia al crear la más grande plataforma de eCommerce con Grails en Latinoamérica.
    • 2. Agenda• Negocio• Diseño inicial• Infraestructura• Problemas• El futuro
    • 3. Negocio Una tienda en linea, con una ampliay creciente gama de servicios y productos
    • 4. Negocio• Ventas en grupo• Cupones.• Pero no solo cupones...• Campañas de email masivas.• Campañas de publicidad masivas.
    • 5. Diseño inicialGrails, Terracotta, RabbitMQ & mySQL
    • 6. Grails• Grails 1.3.4 • GORM • Servicios • Controllers y TagLibs • Jobs
    • 7. GORM, lo bueno• Facilidad de crear modelos • Modelos ricos• Consultas • Criteria • DynamicFinders• Actualización del esquema de base de datos
    • 8. GORM, lo malo• No es posible probar DynamicFinder y Criteria de forma unitaria• Pruebas integrales, a veces toma mucho tiempo• Es sencillo cometer errores debido a la facilidad • Olvidar crear indices • Iterar grandes colecciones • Dejar que Grails nombre relaciones (tablas o campos)
    • 9. Servicios, lo bueno• Lógica de negocio• Servicios que “escuchan” eventos• Extensivo uso de Dependency Inyection• Composición, agregación• Reglas de negocio flexibles
    • 10. Servicios, lo malo• Abusar de Dependency Inyection • Referencias circulares • No es tema de Grails exclusivamente, con Spring se presenta también.• Duplicar nombres de Servicios, en diferentes paquetes• Olvidar quitar la administración transaccional cuando no es necesaria.
    • 11. Controllers, lo bueno• Ridículamente simple• Generar JSON/XML es trivial• Reglas de mapeo, muy sencillo y flexible (URLMappings)• Totalmente desacoplado de la vista
    • 12. Controllers, lo malo• Nada
    • 13. TagLibs, lo bueno• Estúpidamente simple crearlas :)• Apoyo de Dependency Inyection para acceder a servicios, o a cualquier componente.• Condicionar la generación de contenido• Llenar plantillas (fragmentos de una página)
    • 14. TagLibs, lo malo• Usarlas como scriptlets
    • 15. Grails, en general• Permite que un desarrollador Java, explote su conocimiento.• Aumenta la productividad debido a el uso de “Convención sobre Configuración”• Incrementa brutalmente la facilidad de convertir requerimientos de negocio en código ejecutable
    • 16. Grails• En mi humilde opinión, la mejor opción para desarrollo web en Java, de cualquier tamaño o requerimiento• Disclaimer: Es solo mi experiencia personal, no puedo garantizar el mal uso de Grails. También puedo equivocarme. Es mi punto de vista como desarrollador.
    • 17. Negocio• En Agosto de 2010 @dvd2k5 me dijo: • Hey domix; en un año tendremos un millón de usuarios• @domix • :O
    • 18. Escalabilidad y DisponibilidadVitales para estar en un negocio muy competitivo
    • 19. Terracotta• Cache distribuido• Evitamos accesos a la BD• Guardamos Objetos Java y HTML • Entidades de Hibernate • Páginas completas • Fragmentos de páginas
    • 20. Terracotta• Usamos EhCache como “fachada” • En desarrollo no usamos Terracotta • En producción y QA configurado • El código aplicativo no se ve modificado
    • 21. Terracotta• IMHO, es una de las mejores piezas de software jamas escritas en Java• Robusto, Estable• Confiable, Ligero• Casi cero administración• Configuración muy sencilla• Uptime de meses en producción
    • 22. Terracotta• Lo usamos para clusterizar sesiones HTTP, pero no quedo productivo• No quería cargar con mas trabajo a Terracotta• Evitar tener un solo punto de falla• También lo usamos muy poco tiempo para clusterizar Jobs con Quartz
    • 23. RabbitMQ• Servicio de mensajería• Diferente a JMS• Escrito en Erlang• Muy robusto, estable• Casi cero administración• Desarrollado por vmWare
    • 24. RabbitMQ• Procesamiento asíncrono• Procesos muy tardados • Envío de email • Consultas pesadas (reportes financieros)• Integración con otras aplicaciones
    • 25. RabbitMQ, lo malo• No hay muchas herramientas de administración/monitoreo• Las que hay son poco “amistosas”• Cuando falla, falla muy duro• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.
    • 26. RabbitMQ, lo malo• No hay muchas herramientas de administración/monitoreo• Las que hay son poco “amistosas”• Cuando falla, falla muy duro• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.
    • 27. RabbitMQ, nada malo• Antes he usado varios servicios de mensajería• Todos ellos basados en Java• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.• IMHO. La mejor opción.
    • 28. RabbitMQ, nada malo• Antes he usado varios servicios de mensajería• Todos ellos basados en Java• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.• IMHO. La mejor opción.
    • 29. mySQL• ¿que puedo decir?
    • 30. mySQL• Tenemos instalada una versión “tuneada” por RackSpace• Una palabra para describirla: Impresionante• He vivido engañado por muchos años. • Un pequeño comportandose como nunca he visto un grande.• Nuestro mySQL ha soportado +15 millones de queries en un día
    • 31. Infraestructura 2 versiones
    • 32. Cajas Versión 1• 2 WebServers • 1 Tomcat 6 con AJP = cluster de 2 Tomcats • Apache HTTPD con mod_proxy• 1 DBServer• 1 Firewall físico• 1 LoadBalancer físico• Rackspace Londres
    • 33. Cajas Versión 2• 4 WebServers • 2 Tomcat 6 con AJP = cluster de 8 Tomcats • Apache HTTPD con mod_proxy• 1 DBServer• 1 Firewall físico• 1 LoadBalancer físico
    • 34. Fierros Versión 2• Dual Quad Core Xeon 2.26 HGZ• 24 GB de RAM• 300 GB SAS X 3• RedHat Enterprise Linux 5.6• En Hospedaje dedicado en Rackspace Chicago
    • 35. Problemas• Quartz Jobs clusterizados • Ahora corren en una instancia propia• Indices faltantes en la base de datos• Consultas muy mal escritas• Mala configuración del log
    • 36. Solucionar problemas• Necesitas métricas, indicadores• Medición• ¿Profiler?• ¿JMX?
    • 37. CompetitividadDatos de Alexa.com del día 21 de Octubre de 2011
    • 38. ¿Como lo logramos?
    • 39. Negocio• En Septiembre de 2011 @dvd2k5 me dijo: • Hey domix; en un año tendremos 5 millones de usuarios• @domix • :O
    • 40. Estrategia actual y futura• Hacer la webapp actual lo mas estática posible• Modularizar la aplicación en un conjunto de servicios• Usar mensajería para comunicarlos• Usar Scala como lenguaje complementario a Groovy• Akka para procesamiento asíncrono• MongoDB como almacén secundario• Redis como cache recundario
    • 41. Estrategia actual y futura• Convirtiendo los servicios en un API Rest• clickOnero móvil iOS este año• clickOnero móvil Android próximo año• Facebook App próximo año• Apertura del API próximo año
    • 42. El equipo
    • 43. ¿Preguntas?
    • 44. Créditos fotos• http://flic.kr/p/e61Pt • http://flic.kr/p/2wGvZi• http://flic.kr/p/7cxoek • http://flic.kr/p/7jLN6x• http://flic.kr/p/5vSqgq • http://flic.kr/p/2VvzMw• http://flic.kr/p/6K9jb8 • http://flic.kr/p/9c7z9T• http://flic.kr/p/6h8UoU • http://flic.kr/p/J1NKm• http://flic.kr/p/24GsCj

    ×