scalability smalltalk seaside

scalability - ¿La escala del mar?



smalltalk seaside (8)

Acabo de recordar que hay un enlace en las historias de éxito de Pharo: una aplicación web de Seaside con hasta 1000 usuarios simultáneos para un gran seguro de salud en Argentina.

Historias de éxito de Pharo

Seguimiento de Issys:

  • Equilibrio de carga: Apache como proxy / equilibrador (round robin con afinidad de sesión)
  • Configuración del servidor: 5 imágenes Pharo en 3 servidores diferentes (Linux y Windows 2003)
  • GUI: fuertemente basado en AJAX. Todo el código escrito en Smalltak: Seaside 3.0, integración Seaside JQuery y JQWidgetBox.
  • Persistencia: Glorp (OR mapeador) y OpenDBX (cliente DB)
  • Bases de datos: grandes bases de datos PostgreSQL y MS SQL Server

Seaside es conocido como "el marco web herético". Uno de los puntos que lo hacen herético es que tiene mucho estado compartido. Sin embargo, eso es algo que, en mi opinión actual, dificulta el escalamiento fácil.

Ruby on rails, por otro lado, comparte el menor estado de estado posible. Se sabe que la escala es bastante buena, incluso si es un perro lento en comparación con las vms de smalltalk modernas. flickr usa php y se ha escalado a una infraestructura extremadamente grande ...

Entonces, ¿alguien tiene alguna experiencia en la escala de Seaside?

Del artículo de Wikipedia, es un cerdo total. Antes de eso, no había escalado hasta el punto en que había oído hablar de eso. :)

En esta interview Avi Bryant, el creador del fundador de Seaside and Co, DabbleDB, explica cómo lo hacen a escala.

De lo que entiendo:

  • Cada cliente tiene su propia imagen de Squeak.

  • Cuando llega un cliente, Apache decide en función del nombre de usuario a qué puerto enviarlo.

  • Sobre la base del puerto se inicia la imagen Squeak del cliente.

  • De esa manera puede crecer a un número infinito de servidores.

Creo que esta solución funciona para ellos según los aspectos específicos de su aplicación que cada cliente no necesita compartir información entre ellos. Así que no hay necesidad de un DB centralizado.

De todos modos, es mejor ver la entrevista en lugar de mi resumen a medio hacer.

Reitero su pregunta un poco para: ¿Seaside le impide / lo desanima a crear aplicaciones de esta escala? Yo diría que generalmente no. Seaside no tiene una forma predeterminada para almacenar sus datos (al igual que php no lo hace, aunque Seaside le brinda algunas opciones adicionales) y mi impresión de que interactuar con sus datos suele ser el mayor obstáculo cuando se trata de escalar. .

Si desea almacenar sus datos en una base de datos SQL monolítica, como con los rieles, puede hacerlo. O puede utilizar una base de datos de objetos. O puede usar una base de datos de objetos separada para cada usuario, o una base de datos separada para cada proyecto, o una base de datos separada para cada usuario y proyecto. O puede almacenar todo en una serie de archivos planos o simplemente puede almacenar sus datos como objetos en la memoria de su máquina virtual.

Y debido a las continuaciones, no necesita recuperar sus datos de su almacén de datos en cada llamada a la página web. Como cuando está utilizando una aplicación de escritorio, puede extraer datos de su almacén de datos cuando su usuario comienza a interactuar con ella, establecer las variables apropiadas y luego usar esas variables entre llamadas web hasta que el usuario haya terminado con los datos en qué momento puede actualizar el almacén de datos Cuando no comparte el estado, debe ingresar al almacén de datos en cada llamada de web.

Por supuesto, esto no significa que la escala sea gratuita, solo significa que tiene un dominio más grande en el que buscar soluciones de escala.

Dicho todo esto, para muchas aplicaciones, los rieles se escalarán mucho más fácilmente simplemente porque existen grandes soluciones de alojamiento para rieles (y php para el caso) que le ofrecerán una gran cantidad de recursos sin tener que alquilar y configurar una caja personalizada.

Estas son solo mis impresiones de leer y hablar con la gente.

Sí, Seaside desciende fantásticamente. Un solo desarrollador puede crear y mantener aplicaciones complejas para grupos pequeños muy bien.

[volviendo a esto después de algunos años] Esto en realidad es mucho más importante que escalar. La velocidad de la computadora aún crece mucho, y el 99% de todas las aplicaciones ahora pueden ejecutarse en una máquina. La velocidad de desarrollo, y especialmente el mantenimiento, ahora domina totalmente el TCO.

Respuesta corta: puedes escalar aplicaciones de Seaside como el infierno yah

Respuesta larga: en el dominio de TI, la escala es una cosa pero tiene dos dimensiones:

  1. horizontal
  2. vertical

Casi todos pensaron en escalar en la dimensión vertical. Eso fue hasta que Intel y sus amigos llegaron a algunas barreras físicas y comenzaron a agregar núcleos para compensar la imposibilidad actual de agregar MHz.

Fue entonces cuando todos empezamos a ser más conscientes de la escala horizontal como el camino a seguir.

¿Por qué te digo esto?

Debido a que Seaside es una imagen de pequeño tamaño que se ejecuta en una máquina virtual y que es aproximadamente la misma situación de un sistema en un servidor de un procesador monocore.

Tomando eso como base, puedes escalar aplicaciones web haciendo un grupo de servidores. Es lo más natural que se puede hacer, lo que es tolerante a los fallos, lo que es topológicamente inteligente es lo más flexible que se puede hacer, supongo que tienes la idea ...

Entonces, si para la escala, haces lo mismo que Intel y amigos, abrazas la forma horizontal. Y es incluso más barato que la forma vertical (que lo llevará a servidores IBM y Sun que son tan buenos como costosos).

Las aplicaciones de RoR normalmente se escalan horizontalmente. Google tiene innumerables servidores baratos para hacer lo suyo. Funciona perfectamente bien, sin importar cuán dramatizadas estén las personas para impresionarte y tirarte un montón de ballenas de twitter que no puedes olvidar.

Si te hablan de eso, solo debes ser educado y escuchar lo que dicen, pero recuerda esto:

  1. Perfecto es el enemigo del bien.
  2. Lo perfecto sin terminar nunca será tan valioso como lo bueno hecho.

Por cierto, Amazon también hace algo así (y es como un par de geolocalización de pareja para que aumenten las posibilidades de atender sus solicitudes con el clúster más cercano a su ubicación).

Por otro lado, la forma en que Avi se ajustó a dabbledb (la compañía de aplicaciones web basada en Seaside comprada por twitter) estaba usando una vm por cuenta de cliente (iniciando y cerrando las que se solicitan).

Tener mucho estado en una imagen no hace que el escalamiento sea imposible ni complicado.

Sólo diferente.

El camino a seguir es con un equilibrador de carga que utiliza sesiones pegajosas para que pueda tener una imagen atendiendo todas las solicitudes de una sesión de usuario. Usted hace cosas para que cualquier imagen de trabajador detrás del equilibrador de carga pueda asistir a cualquier usuario de una aplicación determinada. Y eso es todo.

Para poder hacer eso necesitas compartir los objetos persistentes entre los trabajadores. Los trabajadores deben poder acceder a todas las bases de datos de los usuarios en cualquier momento y deben lidiar bien con la concurrencia.

Diseñamos el flujo de aire escalable de esa manera.

También es económicamente conveniente porque puede comenzar con N muy pequeño (dependiendo de la memoria RAM de su primer servidor) e incrementarlo a pedido hasta que alcance el límite de hardware.

Una vez que alcanza el límite de hardware, simplemente agrega otro host al clúster y vuelve a configurar el equilibrador (y el acceso a las bases de datos).

Sencillo, económico y elegante.