Estoy viendo el tutorial de Flask, y sugiere crear una nueva conexión de base de datos para cada solicitud web. ¿Es la forma correcta de hacer las cosas? Siempre pensé que la conexión a la base de datos solo debería crearse una vez para cada hilo. ¿Se puede hacer eso, manteniendo la aplicación como segura para subprocesos, con matraz u otros servidores web de Python?Cómo conservar la conexión de la base de datos en un servidor web python
Para fines de aprendizaje, tal vez sí. Pero en una aplicación real que se ejecuta en un entorno de producción que no es una situación ideal en absoluto.
Normalmente, siempre desearía tener un grupo de conexiones entre su aplicación y la base de datos. No importa qué idioma/base de datos esté usando, esta es una solución común.
Un grupo de conexiones de bases de datos mantiene abiertas varias conexiones. La capa de aplicación simplemente toma una conexión que no se usa, las conexiones se liberan cuando la capa de aplicación ya no las necesita. Por "liberado" quiero decir que vuelven a la piscina para volver a utilizarla.
En pocas palabras, las conexiones no se abren/cierran por solicitud. Se adquieren/liberan desde/hacia el grupo de conexiones de la base de datos. Por ejemplo, con Python y mysql puede ir por PySQLPool.
Aquí hay una buena comparación de rendimiento con diferentes soluciones. (PostgreSQL)
versión corta: Look A en pgBouncer
Versión larga: http://www.askthepony.com/blog/2011/07/django-and-postgresql-improving-the-performance-with-no-effort-and-no-code/
es la creación de una nueva conexión de cada solicitud el camino a seguir? No. Para aplicaciones grandes, recomendamos utilizar SQLAlchemy (que puede tener un grupo de conexión configurado), incluso si no está interesado en el ORM. Los documentos tienen una sección sobre eso en realidad: http://flask.pocoo.org/docs/patterns/sqlalchemy/#sql-abstraction-layer
En mi experiencia, a menudo es una buena idea cerrar las conexiones con frecuencia. En particular, a MySQL le gusta cerrar las conexiones que han estado inactivas por un tiempo, y en ocasiones eso puede dejar la conexión persistente en un estado obsoleto que puede hacer que la aplicación no responda.
Lo que realmente quiere hacer es optimizar el "tiempo de conexión muerto", la fracción del tiempo que una conexión está activa pero que no está funcionando. En el caso de crear una nueva conexión con cada solicitud, ese tiempo muerto realmente es solo el tiempo de instalación y desmontaje. Si solo hace una conexión una vez (por hilo), y nunca va mal, entonces el tiempo muerto es el tiempo de inactividad.
Cuando su aplicación solo atiende unas pocas solicitudes, la cantidad de conexiones que se producirán también será pequeña, por lo que no hay mucha ventaja de mantener una conexión abierta, pero inactiva. En el otro extremo, cuando la aplicación está muy ocupada, las conexiones casi nunca están inactivas, y cerrar una conexión que se volverá a abrir inmediatamente también se desperdicia. En el medio, cuando a veces se reciben nuevas solicitudes de vuelo, pero a veces no, tendrá que hacer algunos ajustes de rendimiento en cosas como el tamaño de la agrupación, el tiempo de espera de solicitud, etc.
Una aplicación muy ocupada, que utiliza un grupo de conexiones para mantener las conexiones abiertas, solo verá un tipo de tiempo muerto; esperando solicitudes que nunca volverán porque la conexión se ha dañado. Una solución simple a este problema es ejecutar una buena consulta conocida (que en MySQL se deletrea SELECT 1) antes de proporcionar una conexión del grupo a una solicitud y reciclar la conexión si no se devuelve rápidamente.
Estoy tratando de evitar la ruta ORM, porque agrega una capa adicional de abstracción, cuando las cosas se pueden hacer fácilmente. – Pankaj
¿Existe una solución más simple que una agrupación de conexiones? Puedo permitirme mantener algunas conexiones abiertas. Tendré solo unos pocos trabajadores, por lo que una conexión por trabajador no es un problema. – AlexC