Consulta sobre el interpretador de rails vs. al de PHP5

Hola amigos de la lista, estuve en una conferencias de framework de
desarrollo de software en venezuela y estaban hablando de RoR, el
ponente
hizo na demostracion y todos quedaron fascinados con la rapidez en que
se
puede desarrollar bajo rails.
Pero en el ciclo de preguntas y respuestas hubo una pregunta que por
supuesto la hizo un guru de PHP y dijo:

Como se comporta el interpretador de rails en aplicaciones grandes donde
existe una concurrencia de mas de 500 usuarios?

puede igualar a PHP?

el ponente no supo responder… lamentablemente!

Les pregunto a ustedes a ver que opinan al respecto…

muchas gracias

Hola,

Como se comporta el interpretador de rails en aplicaciones grandes
donde existe una concurrencia de mas de 500 usuarios?

aprovechando el fin de las olimpiadas, haré in simil deportivo… el
término concurrente es como las gimnastas chinas… muy elástico… qué
significa 500 usuarios concurrentes? 500 usuarios por segundo? eso sería
algo así como 30000 usuarios por minuto? o sea, 1800000 usuarios en una
hora pico? Siendo generosos vamos a pensar que es un site no
multinacional y que tiene sólo 3 horas pico al día… eso da para 5400000
usuarios sólo en las horas pico. Con ese tráfico, sólo con la publicidad
ese sitio puede generar 5000+ euros diarios, o lo que es lo mismo, un
par de millones de euros al año. No tiene mala pinta

Vamos, que estamos hablando de unos volúmenes que no todo el mundo tiene
en mente cuando empieza con su start-up, y a los que cuesta un poquito
llegar… y hacer ese tipo de preguntas así a bulto no parece que sea
algo muy del mundo real.

puede igualar a PHP?

A la hora de diseñar una arquitectura para atender tal cantidad de
peticiones, te aseguro que algo de lo que menos importa es el lenguaje
de programación. La gestión de la base de datos, de la caché, y la
distribución del tráfico/funciones entre diferentes máquinas es una
parte muy importante a la hora de hacer que una aplicación pueda
soportar tráfico intenso.

Si una persona es capaz de diseñar una arquitectura para dar soporte a
ese número de usuarios en PHP, será capaz de hacerlo en Rails, o en J2EE
o en XXXXXX. Dependiendo de la plataforma, necesitará algunos recursos
más o menos (procesadores y memoria, básicamente), pero si hablamos de
ese tráfico, te lo puedes permitir.

–
javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

2008/8/25 Manuel P. [email protected]

Hola amigos de la lista, estuve en una conferencias de framework de
desarrollo de software en venezuela y estaban hablando de RoR, el ponente
hizo na demostracion y todos quedaron fascinados con la rapidez en que se
puede desarrollar bajo rails.
Pero en el ciclo de preguntas y respuestas hubo una pregunta que por
supuesto la hizo un guru de PHP y dijo:

Como se comporta el interpretador de rails en aplicaciones grandes donde
existe una concurrencia de mas de 500 usuarios?

En el trabajo usamos rails y te aseguro que con 500 usuarios… las
máquinas
se aburrirían.

puede igualar a PHP?

Ruby no es tan rápido como PHP, pero si quieres algo realmente rápido,
te lo
programas en ensamblador y punto. Además te aseguras de no tener
problemas
con las librerías.

Un Saludo.

El día 26 de agosto de 2008 1:06, Guillermo [email protected]
escribió:>>

Como se comporta el interpretador de rails en aplicaciones grandes donde
existe una concurrencia de mas de 500 usuarios?

En el trabajo usamos rails y te aseguro que con 500 usuarios… las máquinas
se aburrirían.

hombre… Si son ‘concurrentes’ como en el ejemplo que pone javier
ramirez, no creo que se aburra ni Rails ni los de sistemas.

puede igualar a PHP?

Ruby no es tan rápido como PHP, pero si quieres algo realmente rápido, te lo
programas en ensamblador y punto.

Pero que bruto eres¡ … esa es la frase que usaba yo cuando todos
‘os’ metíais conmigo por ser javero.

f.

ok gracias por las respuestas pero no consigo algo concreto… es de
lógica
que se debe disponer de un hierro o hardware fuerte para que cualquier
aplicación web tenga un buen desempeño. Pero si cuento con unos buenos
servidores de aplicacion (con apache como servidor web) y un buen
servidor
de base de datos (con SGBD ==> postgres) es de logica que la aplicacion
va
andar bien.

Ok ahora cuento mi problema personal, tengo una aplicacion que tiene mas
de
500 usuarios concurrentes (y creanme que es asi porque se pretende
migrar un
sistema web, del gobierno, muy viejo que esta desarrollado en ASP con
base
de datos SQL) .

Esta aplicación web actual es del gobierno de venezuela y tiene mucha
demanda y en las horas pico estaba colapsando mucho y lo que se hizo fue
colocar dos servidores de aplicacion con balanceo de carga y esos dos
apuntan a un servidor de base de datos dedicado.

Entonces: ¿ustedes creen que rails, corriendo en apache bajo linux y con
BD postgres, se comporte bien para un sistema de tanta demanda de
usuarios
como el que se pretente migrar?

El 26 de agosto de 2008 7:06, Edgar G.
[email protected]escribió:

2008/8/26 Manuel P. [email protected]

Entonces: ¿ustedes creen que rails, corriendo en apache bajo linux y con
BD postgres, se comporte bien para un sistema de tanta demanda de usuarios
como el que se pretente migrar?

Y no crees que dependerá de como de bien se haga la aplicación. Rails no
es
una applicación, ni un lenguaje (por lo que no tiene sentido compararlo
con
PHP por ejemplo) es un framework. Si la aplicación está bien diseñada
claro
que puede funcionar bien.

Manuel,

Efectivamente PHP es más rápido que Ruby. Usualmente la velocidad es
el punto mas usado para descalificar a ruby. Si la velocidad del
lenguaje es el punto “más importante” entonces la elección debería ser
C o en su caso Assembler

En la web sin importar el framework/lenguaje que utilices la
escalabilidad de tu “aplicación web” la va a dar la arquitectura que
implantes.

En mi opinión una de las cosas más importantes de Rails además de lo
rápido que se hace el desarrollo, es que esta velocidad de desarrollo
se hace reforzando el seguimiento de las “mejores prácticas”: tests (o
specs segun el gusto), patrones, etc…

Saludos desde Venezuela

2008/8/26 Manuel P. [email protected]:

puede igualar a PHP?
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Edgar González González
E-mail: [email protected]
http://edgar.gonzalez.net.ve
http://www.hasmanydevelopers.com
http://www.rubycorner.com
http://www.to2blogs.com
http://www.lacaraoscura.com

Hola,

Ok ahora cuento mi problema personal, tengo una aplicacion que tiene
mas de 500 usuarios concurrentes (y creanme que es asi porque se
pretende migrar un sistema web, del gobierno, muy viejo que esta
desarrollado en ASP con base de datos SQL) .

Como ya te dije el término “concurrente” es muy ambiguo

ya que estamos hablando de un sitio real (originalmente decías que un
gurú de PHP fue el que preguntó por los 500 usuarios concurrentes), qué
quieres decir exactamente con 500 usuarios concurrentes?

En el momento máximo de pico, cuántos request por segundo necesitas?
Puedes tener 500 usuarios logados a la vez, pero quizás estén ejecutando
solamente 5 o 10 request por segundo en total. O realmente quieres decir
que tienes 500 peticiones concurrentes cada segundo?

Y una vez sabido el número de request/segundo… de esas peticiones son
todas diferentes? o puedes servir contenido cacheado directamente desde
apache sin necesidad de que se calcule nada?

saludos,

–
javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

El día 26 de agosto de 2008 15:29, Alberto Q.
[email protected]
escribió:>

Si se trata de un sistema web del gobierno, si serian unas 500 peticiones
concurrentes; no creo que le sirva el mostrar contenido cacheado.

Personalmente, desde mi gran inexperiencia con Rails, no creo que
Rails esté pensado para este tipo de aplicaciones.

Aunque como dicen por ahí arriba, la performance de un lenguaje
depende de la calidad del desarrollo, la optimización de los accesos a
BD y de la arquitectura hardware de detrás.

Yo optaría por algo como Java. … hala!.. se levantó el flame

f.

Fernando G. wrote:

Personalmente, desde mi gran inexperiencia con Rails, no creo que
Rails este pensado para este tipo de aplicaciones.

Yo creo que el problema va mas alla de “con PHP si, con Rails no”.

El intérprete de PHP es más rápido que el de Ruby. Por tanto, siendo
todo lo demás igual, con los mismos “hierros” podrías procesar más
peticiones con una aplicación en PHP.

El problema es la condición “siendo todo lo demas igual”. Como ha dicho
Guillermo, igual podrias programarlo en ensamblador. ¿Cuánto te cuesta
en PHP montar una caché de consultas? ¿O usar memcache para guardar
fragmentos, o las sesiones de usuario? ¿O la posibilidad de automatizar
los tests de la aplicación? ¿Y que además la aplicación quede como un
todo coherente y que no quede hecha una suma de pegotes? No dudo que
pueda hacerse, pero según vas añadiendo “incógnitas” a la ecuación, el
sudoku se va complicando.

La elección del framework y lenguaje es sólo una pieza más del
rompecabezas: el modelo de datos de la aplicación o el equilibrio entre
escrituras y lecturas puede influir en la arquitectura final tanto o más
que el framework que estés escogiendo.

Saludos.

Si solo necesitas un servidor web, no uses apache, hay alternativas
mucho más ligeras y rápidas por ejemplo nginx + mongrel

2008/8/27 Manuel P. [email protected]:

de datos SQL) .
El 26 de agosto de 2008 7:06, Edgar G. [email protected]

implantes.

Hola amigos de la lista, estuve en una conferencias de framework de

[email protected]
http://www.hasmanydevelopers.com

–
Edgar González González
E-mail: [email protected]
http://edgar.gonzalez.net.ve
http://www.hasmanydevelopers.com
http://www.rubycorner.com
http://www.to2blogs.com
http://www.lacaraoscura.com

Y una vez sabido el número de request/segundo… de esas peticiones son
todas diferentes? o puedes servir contenido cacheado directamente desde
apache sin necesidad de que se calcule nada?

Si se trata de un sistema web del gobierno, si serian unas 500
peticiones
concurrentes; no creo que le sirva el mostrar contenido cacheado.

Manuel el performance de tu sistema no estará medido unicamente en la
velocidad de respuesta que de un servidor web, o un SGDB, sino tambien
en la forma que este esté desarrollado. Una base de datos con un mal
diseño tambien lo afectará, asi como el realizar peticiones mal
formuladas,
etc.

Te recomiendo que busques benchmarks realizados a servidores web
trabajando
con apps en rails y en php, realices tus comparaciones y luego agregues
el
factor
“tiempo de desarrollo” y escalabilidad de tu aplicación.

Saludos,

2008/8/26 Manuel P. [email protected]:

bueno leyendo las respuesta de todos ustedes, a quienes les doy las gracias,
de verdad que no se llega a nada… no hay una repsuesta concreta…

Porque no existe

Estoy en una indecision muy grande debido a que no sé que decision tomar
sobre bajo que plataforma desarrollaria un proyecto de este tamaño…
si me inclino por tiempo de desarrollo y escalabilidad de la aplicacion
Rails es lo mejor que hay. Existen framework de PHP como kumbia, cakePHP y
symphony que requieren de mucha configuracion y hay que echar mucho codigo.
Rails se los lleva por los cachos en ese sentido, sobre todo en la parte del
modelo ya que ActiveRecord reconoce automaticamente las estructuras de tus
tablas en base de datos (eso en kumbia y symphony no se puede)

Yo usaria la herramienta donde te sientas mas comodo. Si va a ser tu
primer proeycto rails, y encima muy grande, no creo que sea
inteligente.

Pero es necesario tambien tomar en cuenta el rendimiento del framework y del
lenguaje en que se basa dicho framework…

Yo me asustaria mas por los programadores que contratás que por el
framework (sobre todo si usas PHP que te sale un vBulletin que es
imposible de escalar facilmente)

–

¡Falta Uno! - http://www.falta-uno.com.ar/
Ricardo M.

bueno leyendo las respuesta de todos ustedes, a quienes les doy las
gracias,
de verdad que no se llega a nada… no hay una repsuesta concreta…

Estoy en una indecision muy grande debido a que no sé que decision tomar
sobre bajo que plataforma desarrollaria un proyecto de este tamaño…
si me inclino por tiempo de desarrollo y escalabilidad de la aplicacion
Rails es lo mejor que hay. Existen framework de PHP como kumbia, cakePHP
y
symphony que requieren de mucha configuracion y hay que echar mucho
codigo.
Rails se los lleva por los cachos en ese sentido, sobre todo en la parte
del
modelo ya que ActiveRecord reconoce automaticamente las estructuras de
tus
tablas en base de datos (eso en kumbia y symphony no se puede)

Pero es necesario tambien tomar en cuenta el rendimiento del framework y
del
lenguaje en que se basa dicho framework…

Por el tiempo de desarrollo y por lo facil y amigable que es el framwork
RoR
voy a lanzarme por alli y que Dios me agrre confesado…

A finales del 2008 les comentaré como se comportó el rails para este
sistema, sino sirvio voy preso seguro pero creo que esta va ser una
prueba
fuerte de que rails tiene un alto performace y asi taparle la boca a
muchos
seguidores de JAVA y de PHP

voy por rails, es una desicion tomada. Luego les cuento mis estimados
amigos

El día 26/08/08, Edgar G. [email protected] escribió:

no hay respuestas concretas, hay que elegir lo que mejor se ajuste a
tu trabajo y todo depende de millones de pequeñas decisiones
y de la forma en que estructures tu plataforma, código, tests… da
igual Ruby, PHP o Java si no eres un buen programador/arquitecto de
sistemas
el lenguaje no hace al programador

la ventaja de rails es que te da unos patrones muy fuertes sobre como
estructurar tu app

marze!

El 27/08/2008, a las 1:07, Manuel P.
escribió:

bueno leyendo las respuesta de todos ustedes, a quienes les doy las

top 100 de las aplicaciones rails mas visitadas del mundo:

por experiencia, es mas facil escribir codigo/aplicaciones mas
ineficiente/s con PHP que con rails, rails implementa diversos
mecanismos de cache, optimizacion de consultas, mecanismos de
seguridad, etc…

saludos,

Solo comentar que los frameworks de php, y salvo que recuerde mal, no
son la
mayoría thread safe, ya que no hay compartición de memoria en las
diferentes
peticiones.

Manuel P. wrote:

bueno leyendo las respuesta de todos ustedes, a quienes les doy las
gracias,
de verdad que no se llega a nada… no hay una repsuesta concreta…

Hola Manuel, he leido todo el hilo y si parece que no te dieron una muy
buena respuesta espero que con lo que escriba te ayude un poco a ubicar
como anda Rails en todo esto.

Primeramente hasta donde se, el interprete de ruby (el clásico realizado
por Matz) es mucho mas veloz que php [1], lo malo es que no es thread
safe o lo mismo: no es programación multihilo como php o otros lenguajes
actuales, lo cual para la concurrencia que tu dices no es tan bueno.

Ahora no por esta “insignificante” caracteristica y por brindar las
grandes potencialidades que ofrece este lenguaje, se desarrollo el
framework Rails, que también algunos módulos de este framework tienen
esta característica singular, como ActiveRecord y el dispatch que
distribuye las funciones a los diferentes modulos del framework.

Ahora no muchos estan de acuerdo con esto que llevaron a una pobre
reputación con el caso twitter, que por culpa de ello cualquier
personilla sin conocer rails se pone a chillar que rails no escala, y
apacerieron alternativas a rails, la mas conocida por el momento es
merb, es thread safe que pronto saldra la version 1.0, pero aun asi
muchas personas le metieron duro al asunto y por eso salio la formula
ganadora: mongrel + nginx.

Ahora rails no se esta quedando con las manos cruzadas pronto la versión
2.2 sera multihilo y también todos sus modulos [2], además que para
diciembre, espero no tarden mas, saldra la versión 1.9 de ruby que tiene
muchas mas mejoras en rapidez, thread safe, y fibbers [3], asi que se
ofrece un futuro muy pero muy prometedor.

Bien si no quieres esperar y viendo tu decisión, que es la mejor, no te
arrepentiras, te aconsejaría los siguientes ingredientes:

1.- Utiliza Apache y passenger (mod_rack) [4]
2.- Utiliza una versión mejorada de la VM de ruby rubyenterpriseedition,
que además es muy fácil de instalar [5].
3.- Utiliza un mejorado adaptador de postgres [6]

La verdad que manejo rails desde hace tiempo, antes era un tanto difícil
el deployar y escalar pero ahora ya aparecieron soluciones muy
consistentes y fáciles, por que rails es impresionante asi que no tengas
miedo a caer preso.

Saludos y cualquier duda me comentas.

[1]
http://izumi.plan99.net/blog/index.php/2008/01/17/ruby-vs-php-performance/
[2]

[3]
http://www.rubyinside.com/ruby-1-9-what-to-expect-presentation-1008.html
[4] http://www.modrails.com/
[5] http://www.rubyenterpriseedition.com/
[6]
http://www.espace.com.eg/neverblock/blog/2008/08/24/neverblock-and-activerecord-concurrent-db-access-without-threads/

Como algunos ya te han ido diciento, una respuesta concreta no existe,
porque no conocemos todos los detalles del proyecto y eso marca
diferencias
que no se pueden apreciar en un hilo.

Sin embargo una cosa sí voy a puntualizar, aunque ya se ha apuntado
algo. La
elección del lenguaje, no va a garantizar el éxito de tu proyecto, yo
más
bien confiaría que las personas lo hiciesen y por ellos es importante un
buen equipo y eso en parte puede determinar la tecnología; pero también
garantizarán que tu proyecto escale, el tener una arquitectura, un buen
diseño, políticas de test, pruebas de carga a poco que tengáis algo
funcional, el uso de algunas herramientas de cache, un buen diseño de
una
arquitectura de sistemas… y todo esto teniendo en cuenta el tiempo
de
desarrollo y el dinero que hay para llevarlo acabo.

Yo si tuviese que decantarme por un lenguaje, para en un proyecto
crítico,
como parece que planteas, y utilizaría lo que más domino, porque en
proyectos críticos, experimentos los justos. ¿PHP? ¿Java? RoR?
Ensamblador?
Bueno, tienes que aunar tiempo, herramientas que podras utilizar y tu
dominio de la tecnología. Si fuese mi caso, por ejemplo yo nunca lo
haría
con PHP, por muy maravilloso que sea, simplemente, no he trabajado nunca
con
él, por lo que el fracaso está asegurado. Pero tampoco elegiría java,
porque
todo el mundo diga que escala ;).

Voy a recoger un poco el testigo de Fernando: ( ). Bueno, yo no
usaría
java para garantizar escalabilidad sin más. Porque hay cosas que tienen
precio, y Java tiene tiempos de desarrollo largos, se necesita gente con
expereincia suficiente, una arquitectura bastante buena, o al final esos
500
usuarios concurrentes no entran ni con miles de máquinas. Por otro lado,
al
usar java, probablemente vamos a hacer una inversión en máquinas, que
quizás
no esté soportada por el proyecto, al igual que los tiempos tienen que
ser
razonables, porque lo que si te puede aportar RoR es un desarrollo ágil
y
más “rápido”, lo que en Java te va a llevar más tiempo, creo que la
gente
que ha desarrollado en Java y en RoR como es caso de Fernando o como es
el
mio propio, esto es evidente.

Por otro lado, habría que ver que esos 500 usuarios concurrentes van a
existir y saber como apuntaba Javier, cuando o a que nos estamos
refiriendo.

saludos,

jesús.

Jesús Navarrete

Independent Developer