13 replies to this topic

[apicito]

Yo dudaba de que unigui pudiese soportar cargas altas de servidor, pero segun los desarroladores parece que ellos piensan que si:

[pre]> What are the limit of sytem? Can one web application be used from 500
> concurrent users at once (with adeguate hardware and well planned
> application)? Or the product is voted for a hobby market? I am very very
> interest in the product but I need to understand what are planned
> intentions for this product.
> Naturally I can pay for a professional product :-)[/pre][pre]This product is certainly targeted for professional use. As long as system
resources allow 500 simulatenous sessions should be no problem.  As
framework advances more advanced features such as pooling datamoulde will be
implemented.

The server core has went through various stress tests many times. Further
stress tests will be performed in future.

Farshad Mohajeri
[/pre]

[fredycc]

Interesante información apicito, también ya alguna vez me había preguntado lo mismo, pues es de saberse que varios factores determinan el rendimiento de cualquier aplicación, espero madure este framework rápidamente pues en lo personal me parece muy buen producto orientado a la web con Delphi.



Saludos.

[Sergio]

Yo tambien me plantee esto, pero puesto que mi aplicacion es basada en base de datos (lo normal, vamos) siempre puedes poner 2 o 3 servidores web, cada uno con su puerto y su maqina, y enviar a cada nuevo usuario a un servidor web distinto, y con este sistema no tienes limite alguno.

Por ejemplo, imagino un link en la web de la empresa para conectar con el programa, cada vez que pinchas conectas con una IP y un puerto, dimaos el 81 donde tienes escuchando un servidor web. El programa, conforme conectas, va y modifica un ficherito donde antes ponia "81" y pone un "82", de forma que el siguiente que visita la pagina ve un link cambiado de puerto, pincha, y conecta con el "servidor secundario"... y bueno, ya os imaginas, es facil crearse un balanceador de carga.

Mi preocupacion es mas bien si una sola base de datos de FireBird podria aguantar 500 usuarios simultaneos haciendo "cosas interesantes" (SQL complejas, no solo ver una lista de cosas en pantalla). Actualmente tenemos clientes con quizas 80 conexiones, y se nota, tienes que configurar FireBird bien y ponerle algo de hardware para que de la talla. Este es el cuello de botella al menos en mi caso, y no puedo usar varios servidores balanceados facilmente.

Por cierto, y aunque sea un poco off-topic (luego lo comento en FireBird): Lei un articulo donde comparaban una base de datos en un disco normal contra esa misma en un disco SSD, y aunque cada uno conseguia unas estadisticas diferentes, es facil que con el cambio el rendimiento se multiuplique por 3 o por 5 (por mucho mas segun algunos pruebas).

Es algo barato (por 150 euros tienes 64 Gigas, suficiente para una base de datos) y muy simple, y si te multiplica el rendimiento "solo por 3", ya me vale!

Tengo uno pedido, ya publicare lño que descubra cuando compare por mi mismo.

[Marc]

Hola Sergio.

Mi preocupacion es mas bien si una sola base de datos de FireBird podria aguantar 500 usuarios simultaneos haciendo "cosas interesantes" (SQL complejas, no solo ver una lista de cosas en pantalla). Actualmente tenemos clientes con quizas 80 conexiones, y se nota, tienes que configurar FireBird bien y ponerle algo de hardware para que de la talla. Este es el cuello de botella al menos en mi caso, y no puedo usar varios servidores balanceados facilmente.

¿ Porqué no puedes usar fácilmente servidores balanceados ?.

Yo trabajo mucho con bases de datos en replicación (no para balancear carga, sino para que mis clientes puedan tener una base de datos en cada local), y funcionan muy bien.

A mi me parece que podrías usar perfectamente bases de datos replicadas para balancear la carga.

Como has dicho, en la página web inicial se pone un pequeño Javascript para que redirija cada sesión cliente a un servidor Web al azar de los varios que corren la aplicación UniGUI.

Ahora solo tienes que hacer que cada servidor Apache que corre la aplicación UniGUI vaya enlazada con un Servidor Firebird distinto (es muy fácil, solo tienes que poner que la conexión sea parametrizada, y que cada servidor Apache tenga una configuración distinta).

De esta forma la carga de la base de datos es distribuida entre varios servidores Firebird. Y ya solo hace falta añadir un motor de replicación entre las distintas bases de datos.

NOTA: Algunos datos críticos, como el stock, pueden ir en una segunda base de datos común para todas las instancias de Servidores UniGUI (ahora que en Firebird 2.5 ya se pueden cruzar datos de diferentes bases de datos, y hacer que los triggers y sp's de una base de datos alteren otra base de datos, ya no hay ninguna razón para no poder dividir los datos en distintas bases de datos).

Saludos.

[Sergio]

No nos vale Marc, ya le hemos dado miles de vueltas.

El caos nuestro es algo especial, tenemos 1 sola aplicacion instalada en unas 180 empresas, y cada empresa se actualiza el programa cuando quiere, lo que trae consigo una actualizacion de la base de datos usando script.

El problema viene que, tras cada actualizacion, te tocaria rehacer todos los triggers de replicacion, y eso sin intervenir tu para nada, tiene que estar todo automatizado, y claro, si te lo planteas asi, sin tener acceso a los servidores de nadie ni estar presente en la actualizacion, ni saber si tienen replicas o no ni donde las pueden tener... pues eso, que no hay forma.

Si existiese un sistema de autoreplicacion que incluyese la estructura de los datos, seria perfecto, pero no existe que yo sepa, lo mas similar son las shadow copies, pero no estan usables hasta que la base de datos principal falla, son solo para "tomar el relevo", no para usarse en paralelo, asi que no tengo nada!

Lo comente en las listas de correo de la fundacion FireBird (somos miembros desde hace tiempo, por contribuir un poco) y me respondieron lo de las shadow copies, pero no habian mas soluciones que funcionasen tras cambios en la estructura de datos.

Supongo que en tu caso la estructura de los datos es fija y puedes montar una replica sin problemas, y tambien supongo que la instalacion la haces y supervisas tu, pero nada de eso es aplicable a nuestro caso!

[Marc]

Hola Sergio.

No nos vale Marc, ya le hemos dado miles de vueltas.

El caos nuestro es algo especial, tenemos 1 sola aplicacion instalada en unas 180 empresas, y cada empresa se actualiza el programa cuando quiere, lo que trae consigo una actualizacion de la base de datos usando script.

El problema viene que, tras cada actualizacion, te tocaria rehacer todos los triggers de replicacion, y eso sin intervenir tu para nada, tiene que estar todo automatizado, y claro, si te lo planteas asi, sin tener acceso a los servidores de nadie ni estar presente en la actualizacion, ni saber si tienen replicas o no ni donde las pueden tener... pues eso, que no hay forma.

Si existiese un sistema de autoreplicacion que incluyese la estructura de los datos, seria perfecto, pero no existe que yo sepa, lo mas similar son las shadow copies, pero no estan usables hasta que la base de datos principal falla, son solo para "tomar el relevo", no para usarse en paralelo, asi que no tengo nada!

Lo comente en las listas de correo de la fundacion FireBird (somos miembros desde hace tiempo, por contribuir un poco) y me respondieron lo de las shadow copies, pero no habian mas soluciones que funcionasen tras cambios en la estructura de datos.

Supongo que en tu caso la estructura de los datos es fija y puedes montar una replica sin problemas, y tambien supongo que la instalacion la haces y supervisas tu, pero nada de eso es aplicable a nuestro caso!

Pero ese es otro problema, ¿ no ?.

Quiero decir que estábamos hablando de la escalabilidad de una gran aplicación UniGUI, con base de datos Firebird. En esas aplicaciones sí que tienes el control de las instalaciones y los servidores, y en ellas deberías poder añadir servidores Firebird con las bases de datos en replicación para balancear su carga y poder soportar más usuarios cuando empiece a decaer el rendimiento.

Es que en caso contrario sería un caos. No me imagino tener a vuestras 180 empresas con versiones distintas del software, metidas en un mismo servidor web para acceder mediante UniGUI.

La ventaja de usar aplicaciones Web es que el proveedor (vosotros) os ocupáis de que siempre estén actualizados a la última versión, actualizando el Servidor, que está bajo vuestro control (aparte de hacer los backups y todo tipo de mantenimiento que sea necesario).

En cambio, otro problema son las aplicaciones Delphi cliente-servidor normales, en replicación.

La verdad es que me gusta hacer yo mismo las actualizaciones cuando un cliente lo pide, solo se tardan cinco minutos (descargar y ejecutar un instalador InnoSetup que reemplaza los archivos del programa y lanza una utilidad que actualiza la base de datos ejecutando los scripts que neceisite). Me quedo más tranquilo asegurándome que todo va bien.

Pero mi caso no es muy distinto al vuestro. Tenemos el programa en unas 100 tiendas y la mitad de ellas están en replicación porqué forman parte de un grupo de hasta 10 tiendas (ese es el grupo más grande que tenemos).

Ten en cuenta que la actualización de la base de datos (mediante scripts que van subiendo la versión), actualizan también los triggers de replicación a la vez que insertan nuevas tablas, etc. ...

Así que en principio los clientes podrían pasar ellos mismos las actualizaciones, incluso en tiendas con replicación (aunque como se tarda tan poco, prefiero hacerlo yo). No hay que hacer ningún mantenimiento especial en las tiendas en replicación al actualizar.

Lo único que hay que tener en cuenta, es que nuestro motor de replicación (lo programé yo mismo), verifica las versiones de las bases de datos antes de replicar. De manera que solo replica cuando las dos bases de datos tienen la misma versión. Con esto quiero decir que los clientes podrían actualizarse ellos mismos, pero verían que no reciben datos de las tiendas pendientes de actualizar (cosa bastante lógica), hasta que no pongan también allí la misma versión.

Saludos.

[Sergio]

No, Marc, nuestro caso es ese "caos" al que haces referencia!

Cada una de las empresas se instala FireBird donde quiere, como quiere, lo configura como quiere (el 99% no lo configura) y nada de servidores externos, cada uno se hace sus copias, etc., y nosotros les damos script de copias "avanzados", de forma que el peograma es consciente de que no se hicieron, todo muy mascadito.

Asi que incluso con web server, cada cual se lo instalara como quiera, y no se si alguno temrinara "alquilandono" el programa como propone, puede ser, pero es a futuro.

Asi que todo ha de ser facil y automatico!

[Marc]

Hola Sergio.

No, Marc, nuestro caso es ese "caos" al que haces referencia!

Cada una de las empresas se instala FireBird donde quiere, como quiere, lo configura como quiere (el 99% no lo configura) y nada de servidores externos, cada uno se hace sus copias, etc., y nosotros les damos script de copias "avanzados", de forma que el peograma es consciente de que no se hicieron, todo muy mascadito.

Asi que incluso con web server, cada cual se lo instalara como quiera, y no se si alguno temrinara "alquilandono" el programa como propone, puede ser, pero es a futuro.

Asi que todo ha de ser facil y automatico!

Que follón debe ser dar la asistencia a estos usuarios .

Saludos.

[Marc]

Por lo que dices UniGUI es lo mejor que podéis utilizar para proporcionarles una aplicación Web.

Es un ejecutable más que se puede ejecutar como un servicio en su servidor, y se conecta directamente a la misma base de datos que la aplicación de escritorio, con lo que no hay que instalar nada más.

Para que lo puedan usar desde el exterior, solo necesitan abrir el puerto 80 en su router, y tener una cuenta de DNS dinámico. Más sencillo imposible (la solución tradicional sería tener un hosting externo, con una aplicación PHP y una base de datos MySQL que hay que replicar con la local en las oficinas, todo eso lleva muchísima más instalación y mantenimiento que la solución UniGUI en su propio local).

Incluso las actualizaciones de la aplicación UniGUI son sencillas y se pueden integrar con la actualización de la aplicación normal. Lo único que habrá que asegurarse es de detener el servicio antes de actualizar y reiniciarlo después, pero seguro que el instalador se puede encargar de ello.

A mi en este panorama (que es algo parecido a lo que quiero hacer para mis clientes), lo que realmente me preocupa es si un ADSL normal tiene el ancho de subida suficiente para satisfacer las conexiones externas.

Saludos.

[Sergio]

Pues actualmente nuestros clientes es que YA tienen un servidor web integrado dentro del EXE que instalan, muy similar al modo servidor independiente de las uniGUI: Van a una opcion del programa, activan el servidor web por el puerto que quieran, y el programa atiende a sus clientes cuando entran por la web.

Ya es cosa suya el tema de IPs dinamicas y puertos en el router, y lo de la ADSL que comentas, que es cierto, van a tener quizas 1 Gbit de subida (100 KB/s), y en general eso no les va a valer para tener muchas conexiones, pero eso es dificil de arreglar ya que solo suelen tener opcion a ADSL (nada de cable, excepto si les llega ONO).

En estos casos, les toca alquilar un servidor en una granja y en ese servidor instalar todo, asi tienes todo el ancho de banda que quieras, no veo otra salida mejor.

Si nosotros empezasemos a vender alquiler del programa instalado aqui, tendriamos la suerte de podernos conectar con una conexion ONO de esas de 50 Mbits/s subida y 5 de bajada por 42 euros mes aprox., eso son 500KB/s, y ya nos podria permitir dejar conectarse a unos cuantos a la vez, pero la cosas no es nada escalable, solo en un datacenter puedes dar el servicio con garantias.

En cualquier caso, nuestra filosofia es que vendemos la licencia de uso, todo lo que necesitan lo tienen en la web para descargarse, y a partir de alli asesoramos al instalar, damos ayuda onlñine conectando a sus pantallas, etc., pero no nos hacemos responsables de routers, impresoras, conexiones de red o de internet, servidores apache... nada de nada.. por eso podemos dar servicio a tantos, porque solo es de lo nuestro, y lo demas, tenemos tutoriales en nuestra web y que cada uno se los lea y los aplique!

[Marc]

Si nosotros empezasemos a vender alquiler del programa instalado aqui, tendriamos la suerte de podernos conectar con una conexion ONO de esas de 50 Mbits/s subida y 5 de bajada por 42 euros mes aprox., eso son 500KB/s, y ya nos podria permitir dejar conectarse a unos cuantos a la vez, pero la cosas no es nada escalable, solo en un datacenter puedes dar el servicio con garantias.

Siempre puedes contratar más líneas ADSL y que en el punto de entrada un Javascript te envíe a un servidor UniGUI u a otro (que estarán conectados a líneas ADSL distintas) para balancear la carga.

Pero se necesita tener mucha confianza en vuestro proveedor y en vuestros equipos para hacer eso. Realmente la opción más confiable es la que comentas de contratarlo a un ISP.

En cualquier caso, nuestra filosofia es que vendemos la licencia de uso, todo lo que necesitan lo tienen en la web para descargarse, y a partir de alli asesoramos al instalar, damos ayuda onlñine conectando a sus pantallas, etc., pero no nos hacemos responsables de routers, impresoras, conexiones de red o de internet, servidores apache... nada de nada.. por eso podemos dar servicio a tantos, porque solo es de lo nuestro, y lo demas, tenemos tutoriales en nuestra web y que cada uno se los lea y los aplique!

Buena filosofía

[Sergio]

Marc, no cuentes con poder tener 5 ADSL en tu oficina, piensa que cada una requiere un nuevo par de cobre, y a tu puerta te llegara un unico par de cobre o dos a lo sumo, que es lo que se deja previsto al hacer el edificio... en mi caso solo tengo 2 pares de cobre, asi que puedo tener 2 lineas de voz y, a lo sumo, dos ADSLs (más ono, que usa otro cable), cosa que no me arreglaria nada.

Vamos, que si necesitas "un buen caño", te toca mudarte tu a una granja de servidores de las de verdad, y aqui si que puedes contratar todo lo que necesites de salida (lo estandar creo que es 100 KB/s de salida, incrementable a 1000 KB/s por poco dinero mas, es de memoria, pero andaba por debajo de 200 euros al mes).

[Marc]

Marc, no cuentes con poder tener 5 ADSL en tu oficina, piensa que cada una requiere un nuevo par de cobre, y a tu puerta te llegara un unico par de cobre o dos a lo sumo, que es lo que se deja previsto al hacer el edificio... en mi caso solo tengo 2 pares de cobre, asi que puedo tener 2 lineas de voz y, a lo sumo, dos ADSLs (más ono, que usa otro cable), cosa que no me arreglaria nada.

Vamos, que si necesitas "un buen caño", te toca mudarte tu a una granja de servidores de las de verdad, y aqui si que puedes contratar todo lo que necesites de salida (lo estandar creo que es 100 KB/s de salida, incrementable a 1000 KB/s por poco dinero mas, es de memoria, pero andaba por debajo de 200 euros al mes).

Tienes razón, no había pensado en ello.

Aunque para mi todo esto es teórico, estamos en un pueblo de Huelva y aquí no nos llega ni el 50/5 de Ono, lo máximo que podemos contratar solo llega a 800kb/s de subida. No hay forma de plantearse dar servicios por Internet desde aquí (y menos con Endesa que se nos cae la luz una vez por semana al menos).

Cualquier cosa que querramos montar lo tendremos que hacer en un ISP sí o sí.

[memofer]

SOLO ESCRIBO ESTO COMO UN COMENTARIO DE UN CORREO QUE RECIBI DE UNIGUI

-----Mensaje original-----
De: FMSoft [mailto:info@fmsoft.net]
Enviado el: martes, 05 de febrero de 2013 03:27 a.m.
Para: Guillermo
Asunto: Re: please help me with uniGUI

I can't give an exact date, but development is in progress.

Thanks


----- Original Message -----
From: Guillermo
To: 'FMSoft'
Sent: Thursday, January 31, 2013 6:54 PM
Subject: RE: please help me with uniGUI



Thank you so much!
I know it, I am rookie on uniGUI, but I'm surprised with that framework,
this is awesome. Please tell me, when going to release the official version?