Rendimiento del sistema Tryton
0 recomendaciones636 vistas
El documento aborda diversas optimizaciones y características en el rendimiento de Tryton, incluyendo operaciones en batch y el manejo de registros. También discute la integración con PostgreSQL y el uso de múltiples procesos para mejorar la eficiencia. Finalmente, se mencionan futuras mejoras y tecnologías potenciales para mejorar la gestión y escalabilidad del sistema.
![1.2/Operaciones en batch: create()
parties = []
for x in xrange(1000):
party = Party()
Party.code = random()
Party.create([x._save_values for x in parties])
o
Party.save(parties)](https://image.slidesharecdn.com/rendimiento-tryton-160826082142/85/Rendimiento-del-sistema-Tryton-4-320.jpg)
![1.4/Cache
● Pre-carga de 2000 registros (configurable)
● Anti-patrón: acceso aleatorio a los datos cargados
mediante search/browse
Party = Pool().get('party.party')
parties = Party.search([])
for party in parties:
for address in party.addresses:
pass](https://image.slidesharecdn.com/rendimiento-tryton-160826082142/85/Rendimiento-del-sistema-Tryton-6-320.jpg)
Rendimiento del sistema Tryton
- 3. 1.1/Operaciones en batch: create() ● Listas de registros: @classmethod def create(cls, vlist): pass
- 4. 1.2/Operaciones en batch: create() parties = [] for x in xrange(1000): party = Party() Party.code = random() Party.create([x._save_values for x in parties]) o Party.save(parties)
- 5. 1.3/Operaciones en batch: save() for party in parties: party.code = random() party.save() for party in parties: party.code = random() Party.save(parties)
- 6. 1.4/Cache ● Pre-carga de 2000 registros (configurable) ● Anti-patrón: acceso aleatorio a los datos cargados mediante search/browse Party = Pool().get('party.party') parties = Party.search([]) for party in parties: for address in party.addresses: pass
- 7. 1.4/Adjuntos ● Problema con python a nivel de comunicación. Introducido workaround en Tryton. Muy lento para ficheros de algunos MB ● Se guardan en el sistema de ficheros
- 8. 1.5/Campos funcionales ● Trabajar en batch si no se puede hacer uso de la cache: @classmethod def get_value(cls, names, records): pass def get_value(self): pass
- 9. 2/Procesos
- 10. 2.1/Múltiples procesos ● Reverse proxy con NGINX o bien WSGI a partir de la 4.0 ● Cron integrado: lanzado en un proceso independiente del que recibe las peticiones RPC ● celery_tryton ● Jasper server
- 11. 3/PostgreSQL
- 12. 3.1/PostgreSQL ● MVCC ● Isolation Level: Repeatable read – No serializable ● Actualizar versiones: 9.4 vs 9.5 24s vs 18→
- 13. 3.2/Fichero de configuración ● Fichero de configuración ● shared_buffers ● work_mem ● maintenance_work_mem ● asynchronous_commit ● fsync ¡¡On!!→ ● ¿¿ huge_pages ??
- 14. 4/Sistema
- 15. 4.1/Soft & hard ● PyPy vs cPython ● Pyhon no libera memoria una vez consumida ● Un proceso python podemos esperar que consuma entre 400MB y 1GB – si excede debería ser un problema ● SSD está muy bien, ¿lo necesitas?
- 16. 5/Futuro
- 17. ● PosgreSQL 9.6 – varios procesos para ejecutar una consulta – excelente escalabilidad hasta 4 procesos ● Mecanismo estándar para guardar binarios en el sistema de ficheros ● Desaparición de los Properties ● ¿Ejecución asíncrona de consultas SQL? ● ¿Utilizar C en python-sql? ● Mejorar gestión de las jerarquías – Adjancency list 5.1/Futuro
- 18. http://www.NaN-tic.com Albert Cervera i Areny albert@nan-tic.com @albertnan linkedin.com/in/albertca