• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Grails, opción real y escalable para sitios web de alta carga
 

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

on

  • 1,752 views

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.

Statistics

Views

Total Views
1,752
Views on SlideShare
1,747
Embed Views
5

Actions

Likes
3
Downloads
30
Comments
0

3 Embeds 5

http://us-w1.rockmelt.com 3
http://a0.twimg.com 1
http://paper.li 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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

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

  • 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.
  • Agenda• Negocio• Diseño inicial• Infraestructura• Problemas• El futuro
  • Negocio Una tienda en linea, con una ampliay creciente gama de servicios y productos
  • Negocio• Ventas en grupo• Cupones.• Pero no solo cupones...• Campañas de email masivas.• Campañas de publicidad masivas.
  • Diseño inicialGrails, Terracotta, RabbitMQ & mySQL
  • Grails• Grails 1.3.4 • GORM • Servicios • Controllers y TagLibs • Jobs
  • GORM, lo bueno• Facilidad de crear modelos • Modelos ricos• Consultas • Criteria • DynamicFinders• Actualización del esquema de base de datos
  • 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)
  • Servicios, lo bueno• Lógica de negocio• Servicios que “escuchan” eventos• Extensivo uso de Dependency Inyection• Composición, agregación• Reglas de negocio flexibles
  • 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.
  • Controllers, lo bueno• Ridículamente simple• Generar JSON/XML es trivial• Reglas de mapeo, muy sencillo y flexible (URLMappings)• Totalmente desacoplado de la vista
  • Controllers, lo malo• Nada
  • 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)
  • TagLibs, lo malo• Usarlas como scriptlets
  • 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
  • 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.
  • Negocio• En Agosto de 2010 @dvd2k5 me dijo: • Hey domix; en un año tendremos un millón de usuarios• @domix • :O
  • Escalabilidad y DisponibilidadVitales para estar en un negocio muy competitivo
  • Terracotta• Cache distribuido• Evitamos accesos a la BD• Guardamos Objetos Java y HTML • Entidades de Hibernate • Páginas completas • Fragmentos de páginas
  • Terracotta• Usamos EhCache como “fachada” • En desarrollo no usamos Terracotta • En producción y QA configurado • El código aplicativo no se ve modificado
  • 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
  • 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
  • RabbitMQ• Servicio de mensajería• Diferente a JMS• Escrito en Erlang• Muy robusto, estable• Casi cero administración• Desarrollado por vmWare
  • RabbitMQ• Procesamiento asíncrono• Procesos muy tardados • Envío de email • Consultas pesadas (reportes financieros)• Integración con otras aplicaciones
  • 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.
  • 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.
  • 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.
  • 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.
  • mySQL• ¿que puedo decir?
  • 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
  • Infraestructura 2 versiones
  • 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
  • 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
  • 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
  • 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
  • Solucionar problemas• Necesitas métricas, indicadores• Medición• ¿Profiler?• ¿JMX?
  • CompetitividadDatos de Alexa.com del día 21 de Octubre de 2011
  • ¿Como lo logramos?
  • Negocio• En Septiembre de 2011 @dvd2k5 me dijo: • Hey domix; en un año tendremos 5 millones de usuarios• @domix • :O
  • 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
  • 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
  • El equipo
  • ¿Preguntas?
  • 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