[pyar] Benchmark de frameworks python

[Juan Carizza]

Opción 1:
Elegís el framework que mejor performe, implementas el sistema en ese
framework luego re-escribis el código varias veces para que performe mejor.

Opción 2:
Elegís cualquier framework, implementas el sistema en ese framework y luego
re-escribis el código varias veces hasta que performe mejor.

Falcón puede atender hasta 10.000 conexiones por segundo lo que sería
0.0001 segundos por cada conexión por lo tanto el problema esta claramente
en lo que hagas en el endpoint de tu API y el tiempo que tardes en procesar
el request y no en la cantidad de request que puedas atender x segundo
porque eso lo podes solucionar escalando horizontalmente.

El lun, 8 de junio de 2015 21:30, Ariel Camino <arielcamino en gmail.com>
escribió:

>
> On 08/06/15 21:02, Alfonso de la Guarda wrote:
> > Ariel,
> >
> >
> > Yo creo que los benchmarks sí son importantes porque te permiten
> > establecer un techo para tu aplicación, así como que tengas en claro
> > en el corto, mediano o largo plazo las estrategias que tendrás que
> > seguir para atender "n" usuarios en determinado tiempo.  Obviamente no
> > puedes considerar todos los escenarios pero sí hacer números sobre la
> > base de usuarios posibles en un futuro cercano, la cantidad de datos
> > que vas a manejar, etc. todo eso influye en como vas a lidiar con la
> > escalabilidad de tu aplicación pero lo que no puedes predecir es el
> > crecimiento de esta porque esto depende de factores exógenos.
> >
> > Para mi caso, mi solución maneja  100 MB de datos diarios y se ve
> > afectada por la cantidad de usuarios que acceden a dicha data, si
> > hacemos una simple multiplicación tenemos que en 30 días tendré 3 GB
> > de data (sin incluir índices ni datos procesados o inferidos), cómo
> > haces para buscar información dentro de esta data que no está
> > estructurada? qué pasa cuando tengas 3 meses (9 Gb teóricos) y 100
> > usuarios diarios? Los frameworks se ven afectados siempre por la
> > persistencia de sus datos, es decir la base de datos y es entonces que
> > todo tiene que valer en tus decisiones, no puedes simplemente decir:
> > lo voy hacer en tal tecnología porque me gusta, no al menos en
> > negocios donde hay una inversión económica.
> >
> > Conozco bastante bien las experiencias de muchos usuarios en el mundo
> > que han escalado sus aplicaciones para servir miles o millones de
> > usuarios pero -precisamente- es en esos casos que aplicas el
> > conocimiento vertido por ellos para evitar en el muy corto plazo estar
> > haciendo refactoring o simplemente rehaciendo todo.
> > Saludos,
> >
> > --------------------------------
> > Alfonso de la Guarda
> > Twitter: @alfonsodg
> > Redes sociales: alfonsodg
> >     Telef. 991935157
> > 1024D/B23B24A4
> > 5469 ED92 75A3 BBDB FD6B  58A5 54A1 851D B23B 24A4
>
> Hola, la verdad que no conozco en detalle a qué te referís con manejar
> 100MB de datos diarios, pero definitivamente no estoy de acuerdo con
> esta frase:
>
> "Yo creo que los benchmarks sí son importantes porque te permiten
> establecer un techo para tu aplicación "
>
> Para mí un framework web no determina el techo, porque justamente cuando
> realmente necesitas escalar, vas a terminar realizando determinados
> ajustesque van a impactar seriamente en la velocidad, y probablemente
> deje igual de parados a cualquier par de frameworks  (por ponerte un
> ejemplo bottle y django), o con tiempos de respuestas muy similares.
>
> Y te lo digo siendo fanático de profilear y mejorar aplicaciones web :)
> (tanto en el backend como el frontend), pero bueno es mi opinión, no es
> mi intención generar un flame :P
>
> Te recomiendo que sea cual sea el lugar donde vayas a deployar la
> aplicación, que siempre hagas un benchmark del hardware en cada
> instancia, no importa que sea el mismo proveedor, el mismo plan, y el
> mismo datacenter.
>
> Mira como andan los discos SSD de linode:
> http://serverbear.com/benchmark/2015/06/03/FJewDmCIW20AU59H#io
>
> ese es un test que hice el sábado, hace un año atrás digitalocean lo
> pasaba por arriba, y ahora cambió radicalmente (linode ahora es varias
> veces más rápido en todos los tests).
>
> Sobre todo por el volumen de datos que vas a manejar, entiendo que no
> vas a poder cachear todo en memoria.
>
> Salutes,
> --
> Ariel Camino
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20150609/993d2498/attachment.html>