El escalado de una aplicación web escrita en Python se realiza utilizando las mismas técnicas que se utilizan en otros idiomas, teniendo en cuenta las características de VM. El diseño más escalable para una VM determinada buscará maximizar la concurrencia, lo que significa que debe aprovechar la multitarea, entre las cuales se encuentra el código asincrónico.
En CPython, se traduce mediante el uso de varios procesos (o subprocesos si el daño de GIL no se nota), cada uno de los cuales aloja la misma aplicación basada en un bucle de eventos (un planificador cooperativo de espacio de usuario). Global Interpreter Lock (GIL) es dañino cuando el código ejecutado consume mucha CPU (como la descompresión de MPEG basada en CPU) porque incluso si la máquina es multinúcleo, solo se ejecutará un subproceso por proceso de CPython en cualquier momento. Al menos las funciones de bloqueo, como las operaciones de E / S, liberarán GIL y permitirán que se ejecuten otros subprocesos del mismo proceso, según las órdenes del planificador del núcleo, es por eso que GIL podría no ser notable en una aplicación Python multiproceso que se ejecuta en CPython. Tenga en cuenta el hecho de que gunicorn admite procesos múltiples, pero cada proceso solo puede tener un hilo.
Para obtener más información sobre Python GIL, visite https://wiki.python.org/moin/Glo…
- ¿Cómo probar lo que construyó un desarrollador web? Nos encanta lo que está construido, solo queremos asegurarnos de que sea seguro, escalable, etc. ¿Existe un servicio que 'pruebe'?
- ¿Es la aplicación secreta un poco turbia? ¿La gente entiende cómo agregará valor a la sociedad?
- Experiencia del usuario: ¿Cómo se puede mejorar una aplicación web para el presupuesto participativo ciudadano para PCMC?
- ¿Se pueden enviar notificaciones push a las aplicaciones web?
- ¿Qué lado del cliente JS será el mejor para una aplicación web a gran escala, en términos de rendimiento y usabilidad?
El código asincrónico como cualquier otro código que aproveche la multitarea tiene una mala reputación. En el caso del código asincrónico, se debe principalmente a las funciones anónimas de JavaScript, lo que lleva a espaguetis de código y se basa históricamente solo en funciones de devolución de llamada. Esto es un cambio con el advenimiento de “rendimiento” (cf. Gevent) y “rendimiento de” (cf. asyncio) y generadores ES 6, cf. http://tirania.org/blog/archive/…. El código basado en la devolución de llamada asincrónica se hace más fácil de manejar en Python solo porque tiene un sistema de tipo orientado a objetos realmente basado en la clase.
Es falso decir que nadie considera que GIL sea perjudicial en ese contexto, ya que los procesos son más costosos en términos de memoria que los hilos. Si no hubo GIL y con un código de gestión de subprocesos adecuado, algún tipo de árbitro de subprocesos, el proceso con múltiples subprocesos permitirá escalar mejor. Los procesos son gestionados por el kernel y el sistema init, dicho esto, a mayor escala, se prefiere la gestión distribuida de procesos porque es más fácil de integrar con la infraestructura de equilibrio de carga cf. herramientas de diagnóstico en tiempo real para sistemas distribuidos.
Cuando las personas se mudan a PyPy o Stackless o Jython, no siempre se debe a GIL:
– PyPy es un compilador JIT con un GIL. PyPy se elige principalmente para aprovechar la ganancia de velocidad. También se dice que puede requerir menos memoria, por ejemplo, PyPy puede calcular __slots__ y evitar la necesidad de usar un dict para cada uno de los tipos no integrados (el uso de __slots__ también agiliza la resolución de los atributos). PyPy también tiene como objetivo eliminar GIL a través de la memoria transaccional cf. http://pypy.org/tmdonate.html
– Jython no tiene GIL pero también puede aprovechar todos los programas desarrollados para la JVM
– Stackless Python tiene un GIL pero tiene como objetivo evitar la necesidad de confiar en los hilos para la concurrencia, es algo similar a una solución de bucle de eventos, excepto que su solución, llamada microthreads, es más genérica y más poderosa que un simple bucle de eventos. Por ejemplo, puede encurtir un microthread y enviarlo a otro proceso, posiblemente en otra máquina. Encontré esa característica, la capacidad fácilmente disponible para mover una tarea a otra máquina, solo en Erlang-VM (también conocido como BEAM) y Termite Scheme VM que está inspirado en BEAM. Stackless se usa ampliamente en el juego EVE Online de CCP, tanto del lado del cliente como del servidor. El único marco web basado en Stackless, lo sé, es http://www.nagare.org/ y no estoy seguro de que aprovechen la función de “selección de tareas”. Consulte https://pypi.python.org/pypi/gre… para obtener microthreads para CPython.
Entonces, sí, las personas pueden encontrar beneficioso mudarse a otras máquinas virtuales de Python, pero no siempre y solo por el lago de GIL.
Escalar una aplicación de sitio web probablemente tendrá que abordar primero el problema más general de tratar con una base de código más grande, que generalmente se dice que es un punto débil de Python como un lenguaje que atribuyo principalmente a un lago de herramientas o lago de conocimiento en las herramientas disponibles y FUD. La mayoría de las veces, cuando una empresa se aleja de Python (o lenguajes similares) debido a la base de código más grande, eligen primero un lenguaje tipado estático porque se dice que es más fácil de administrar (a). También lo hacen porque:
b) Un gran grupo de trabajo potencial cf. Ejército de programadores
c) “los lenguajes estáticos son más rápidos”
d) Herramientas más fácilmente disponibles
Las principales compensaciones son una reducción del poder de expresividad fácilmente disponible, entre los cuales se encuentra la metaprogramación. Esto puede mitigarse con herramientas adecuadas o lenguajes adecuados como Scala, que se usa en Twitter para reemplazar a Ruby (y Java), consulte Programación de sistemas en Twitter.
No argumentaré que “Python es más fácil de escribir, por lo tanto, hay menos errores, por lo tanto, una iteración más rápida y, por lo tanto, mejores productos” y, en cambio, argumentaré que todos los puntos anteriores se abordan o pueden abordarse, excepto el Army Of Programmers, que se trata por separado después de:
a) “la base de código grande escrita en un lenguaje estático es más fácil de administrar”, esto se debe principalmente a una respuesta más rápida del editor o compilador que aprovecha la escritura estática. En Python puede aprovechar las herramientas de pelusa como pylint con pylint-brain que, entre otras cosas, hacen inferencia de tipos. A la larga, desde la perspectiva del diseño del lenguaje, se argumenta que la escritura estática enchufable y opcional es una mejor solución, cf. http://lambda-the-ultimate.org/n…
c) “los lenguajes estáticos son más rápidos” No creo que sea un argumento importante en el sentido, que no tenga en cuenta la “reducción del poder expresivo” que generalmente es una parte integral de pasar a un “lenguaje tipado estático “. Pero aún así, Python es más lento que los lenguajes basados en C y JVM, incluso si PyPy y otros intentan abordar eso y hacer que Python sea competitivo. También son investigaciones activas realizadas en la compilación de Python para código de máquina optimizado como Cython, compilador de numba y otros.
d) “herramientas más fácilmente disponibles” esto está respaldado por tres ideas entrelazadas:
– evitar la necesidad de un equipo políglota
– aliviar el dolor de interactuar con otras herramientas
– y en realidad más herramientas disponibles en el idioma. Una gran cantidad de software dirigido a las aspirantes a infraestructuras a escala web están escritas y solo están disponibles en Java.
El último argumento “Army Of Programmers” es cierto pero:
– Encontrar programadores de Python es más fácil que antes.
– No puedo respaldar mi afirmación con mucha experiencia en Java que dice que creo que Python como lenguaje es más fácil de aprender y dominar que el lenguaje Java.
– Es más fácil encontrar un buen programador que conozca Python y esté dispuesto a escribir Python que encontrar un buen programador dispuesto a escribir Java.
Entonces, sí, Python puede ser técnicamente parte y es parte de productos de escala web, incluso si la mayoría de las veces no podemos estar seguros de que no es solo para reemplazar Makefiles cf. http://en.wikipedia.org/wiki/Pro…
La elección de Python para una aplicación de escala web debe pasar por el mismo (o mejor) escrutinio que lleva a algunos grandes nombres a pasar a un lenguaje tipeado estático.
Gracias a Jython, puedo escribir consultas de bases de datos en Python para la base de datos basada en Java. Conozco algo de Java, de todos modos, no me importa usar Hadoop y otros softwares publicitarios de “escala web”.
Creo que Python es una mejor herramienta para lidiar con el código asincrónico que JavaScript, entre los muchos activos que Python tiene como lenguaje sobre JavaScript. Dicho esto, excepto Tornado, no hay un marco listo para lidiar con el problema de c10k. Los marcos clásicos, todos ellos no destinados a ser utilizados para la web en tiempo real, la recuperación ha sido infructuosa, imposible o con un éxito marginal.
Cuando escribo un éxito marginal, pienso en Gevent, Python 3 y Stackless.
