Tunear la BD

[ni-jvaldivia]

Por ahora tenemos la db dentro de un container en docker (puede encontrarse en docker-compose) y se deployea todos los containers en un servidor con 4GB de RAM (creo que @aniversarioperu tiene la info completa de los specs del server).

Hay queries que terminan matando al server:

y terminan retornando un Timeout al usuario.

Mi propuesta seria revisar si es que la bd se esta consumiendo todo (que asumo que es lo mas probable), tunearlo (configuracion basica de tuneo se puede sacar de pgTune(https://pgtune.leopard.in.ua/#/)) y separarlo a otro servidor si es que se come todo de la aplicacion cosa que podemos tener mejor performance al hacer las requests + scrappear.

[aniversarioperu]

creo que @manubellido tenia algunas ideas de como hacer esto?

[manubellido]

@ni-jvaldivia sabes qué tipos de requests o algún ejemplo? Independientemente recomiendo integrar sentry (https://sentry.io/for/django/). Tienen un tutorial muy bueno acerca de con integrar con django: https://docs.sentry.io/platforms/python/guides/django/.

[manubellido]

Otra cosa a considerar es: cómo están funcionando las búsquedas actualmente? Ya se está usando el nuevo campo de full text search?

[josevaldiviaromero]

Si @manubellido es una buena idea tener sentry, eso nos va a ayudar a tener idea de los errores en prod. Voy a crear un issue tambien para eso.

Con respecto a la request, no recuerdo exactamente la request (y por eso deberiamos tener sentry jaja). Pero he estado probando en mi local environment: http://localhost:8000/search/?q=pcm esta query demora artito:

Por lo que veo las busquedas se hacen con el campo de full text search.

[lisbeth-s4]

A mí me parece que la demora es en python no en la base de datos. Ver imagen adjunta. Es posible que la demora se origine durante el procesamiento de 93k registros durante la paginación.

[lisbeth-s4]

Bueno, otras queries también demoran en el SQL. Curioso que demore a pesar que la query (motivo) esté dentro del full search index.

[manubellido]

Excelente @lisbeth-s4! Ese es un gran hint. Ya sé lo que pasa, aunque no tengo pruebas, tampoco tengo dudas:

Cada búsqueda es ordenada por date: https://github.com/manolo-rocks/django-manolo/blob/master/visitors/views.py#L88

y esto es super lento si es que no se tiene un index en ese campo como es el caso: https://github.com/manolo-rocks/django-manolo/blob/master/visitors/models.py#L89 (lo que sucede es que la función tratará de ordenar los 93k registros antes de darte la página indicada.

Si añadimos el index, db_index = True en ese campo, las cosas mejorarán.

[josevaldiviaromero]

Claro, tiene mucho sentido...

[aniversarioperu]

sigue lenta la pagina cuando la busqueda devuelve demasiados resultados a pesar del indice en date

Estuve probando y parece que es la paginacion la que consume bastantes recursos y demora en ejecutarse. Supongo que no es de mucha utilidad retornar al usuario paginacion de 59k paginas ya que no podra examinar todas y seguro que hara busquedas mas especificas que devuelvan menos paginas y seran las que al final llegue a examinar.

Creo que sera necesario limitar el numero de paginas que se devuelvan al usuario.

[manubellido]

el problema estaba en el paginator al momento de calcular el número de resultados. En el PR #143 explico un poco más.