Esto va a traer cola...
 

Hola amigos:

Digo que esto va a traer cola porque no soy capaz de encontrar información acerca de lo que voy a preguntar, y de paso, pongo a debatir...

Estoy haciendo una aplicación para móviles (en Titanium) las cuales deben conectarse a un servidor de forma muy asidua, como si de un cliente/servidor REST se tratase, y tengo la necesidad de programarme mi propio "REST" en FreePascal, cuyos CGI compilados me han dado siempre unos resultados excelentes. Sin embargo, a grandes cargas, o mejor dicho, a gran escala de accesos a un CGI compilado desconozco su comportamiento, o sea, no dudo en absoluto de su rapidez y la mas que notable mejoría que puede presentar frente a un script en PHP, sin embargo desconozco y no soy capaz de encontrar información sobre los recursos del sistema, uso de la memoria, microprocesador, etc. y tengo miedo que cuando le entren 300 accesos colapse el servidor.

A todo esto..., hablo de FreePascal Linux, que es el sistema de mi servidor. Un servidor Dual Core 2,4 Ghz., 2 Gb. Ram y 100 Mb. Ancho de banda asimétricos (Datacenter Francés).

PHP es 10 veces mas lento al ser interpretado, pero no es menos cierto que el intérprete hoy por hoy está integrado como módulo en Apache, y no sé si en este caso utiliza una sola instancia del módulo para 300 accesos, o duplica la instancia. Igual que no sé si un CGI en Pascal se cargaría en la caché de Linux hasta el punto de usar esa única instancia en memoria para ejecutarlo las veces que hagan falta sin colapsarse.

Como digo, me han dado muy buenos resultados los CGI en FreePascal, pero siempre los he usado como programa web, con accesos moderados, no como por ejemplo 1.000 móviles accediendo 3 o 4 veces por minuto.

La cuestión es: ¿CGI compilado en Freepascal o PHP?.

Gracias amigos!!

En terminos generales, el ppal cuello de botella es el I/O (Todo lo que toque disco duro).

Lo unico que puede darle la ventaja a php, ruby, python es tener listo alguna libreria que acelera algo, acceso a un api especial o una implementacion especializada. De lo contrario, un lenguaje compilado *deberia* ser mas "rapido".

PERO, como todo "mide 2 veces, corta 1". La unica forma de estar seguro es hacer pruebas de desempeño, y comparar entre ambos.


-----
Busca en internet "escale ruby|php|python|web app" y veras tips generales de como se escalan las aplicaciones en internet. Veras que muchos de esos tips aplican para todo tipo de frameworks y pocos son especificos de cada lenguaje.

Si estas trabajando contra una BD, es eso lo que mas probable sea tu cuello de botella (recuerda: BD= I/O). El codigo que recide en el servidor web (php o freepascal) generalmente no hace gran cosa.

----

Por otro lado, 1.000 moviles a 4/min no me parece algo dificil de lograr, si tu app esta bien hecha, optimizas el acceso a la BD, usas cacheo y especialmente usas metodos asincronicos para no bloquear las llamadas/respuestas en tu servidor web. Usando algo asi, en python por ejemplo se puede llegar a 1.000 request por segundo sin sudar.

En resumen? La arquitectura y la adecuada seleccion de los componentes y librerias seran el factor determinante en el desempeño de tu app. Si ademas, el codigo esta ya en pascal y reescribirlo es mas costoso, pues porque no hacerlo en lo que sabes y preocuparte luego? La gente de twitter hizo asi, empezo con ruby (que es leeeeentiiiissiiiiimmooooo, sobre todo en ese entonces) y luego cuando llegaron los usuarios empezaron a optimizar. Muchos empiezan con lo basico, y progresivamente van mejorando, tuneando, reemplazando de forma selectiva componentes, etc:

Gracias mamcx:

Incluso sin ser mi intención optimizar nada en un principio, sí que es verdad que la aplicación REST la estoy programando en FreePascal pero sin entorno ojo..., a base de un simple editor de textos (JED, que me gusta mucho) y compilar en consola (ppc64), el resultado es una aplicación CGI compilada que apenas ocupa 700k.

Por otro lado no uso BD, la estructura que me estoy haciendo a medida va en base a ficheros, es decir, cada usuario un directorio, y dentro de cada directorio un fichero básico con su información de registro, y un fichero de intercambio con la aplicación del móvil. Esto me permite loguear al usuario y enviarle información personalizada sólo para él, incluso si su móvil está apagado. No uso BD precisamente porque tal y como lo estoy haciendo, si quisiera añadir un campo nuevo, enviando información en formato XML a esos ficheros, luego puedo interpretarla perfectamente con sólo actualizar la aplicación, es decir, que el servidor REST se va a quedar hecho para no tocarlo y me va a permitir añadir todo lo que sea necesario.

Obviamente el acceso directo al fichero, lectura del mismo y respuesta, va a ser siempre mucho mas rápido que accediendo a una BD, que finalmente está basada en ficheros, pero hay que pasar por la consulta y la cola, mientras que de la otra forma es mas directa.

Veo que tienes experiencia en el tema..., con lo que te he comentado, ¿crees entonces que soportaría bien esos 1.000 accesos aproximadamente 4 veces por minuto?.

Gracias!!

Aunque traiga cola, procura poner títulos descriptivos a tus preguntas, gracias ;)

Pues describes el caso de uso donde un servidor web es super-optimo: servir archivos. Puede que te resulte mejor si pones al frente de tu app un servidor como nginx. Si el resultado final es un archivo, este mini-servidor web es tremendamente optimo.

Si te sale bien asi... pero eso no excluye para nada una base de datos. En especial, si es tan capaz como Postgress.


No es tan obvio (sin medir primero). Es posible ser mas rapido que servir archivos desde el disco (recuerda: I/O) y los motores sql son maquinas bien aceitadas. Ademas, dependiendo de como sean los datos, su acceso y su forma de operar existen formas especificas de hacer que algo sea mas o menos rapidos.


La respuesta es si o no. Depende de como esta hecha tu app y como son los datos. Ademas, depende de que *realmente* es lo que necesitas optimizar. Simplificando, es diferente:

1- Quiero que cada respuesta sea lo *mas rapido* posible
VS
2- Quiero poder responder al mismo tiempo al *mayor numero* de clientes.

Son cosas que tienen relacion (mas rapida la respuesta, mas numero de clientes) pero difiere en que es posible ser "lento" y aun asi servir a mas clientes a la vez.

-----
P:D Si unicamente estas devolviendo archivos, y no haces gran cosa en la autenticacion, entonces se puede poner a volar eso a mil, mezclando nginx, cacheo en memoria o mejor usando memcached o redis. Hace poco lei por ahi alguien que armo 40.000 request/seconds en un portatil. Estamos hablando que si no hay logica seria de por medio estas en el mejor panorama posible.

Magistral mamcx!!.

Haces un razonamiento muy bien definido, y por lo que veo, según lo que yo quiero hacer, no debería tener problemas.

A ver, no es que vaya a intercambiar ficheros en sí, sino que el CGI va a leer su contenido y se lo va a mandar a la APP, o sea, que en realidad no es una transferencia de ficheros.

En cuanto a la rapidez, pues cada consulta puede derivar en una transferencia de no mas de 200 bytes a lo sumo. 1k en casos donde una APP esté apagada por 3 días y luego lo tenga que leer todo junto. La verdad es que no es nada.

En un par de días o tres terminaré la aplicación del servidor. ¿Se os ocurre algún método para ponerlo a parir sin tener 1.000 APPs accediendo?.

Un saludote!!

Osea, como hacer la prueba? Puedes usar http://httpd.apache.org/docs/2.2/programs/ab.html, o cualquier otro programa o cliente (incluso hecho por ti) para simular las llamadas.

O usar un servicio como https://www.pingdom.com/ o similares. Todo depende de como es que se llama tu servidor, como se hace el flujo, etc.