Przejście na aiohttp
Opened this issue · 0 comments
Tbh. Flask trochę przeszkadza reszcie aplikacji. Muszę obchodzić to, że serwer zupełnie blokuje wątek tworząc pełen osobny proces tylko na serial.
To znacznie komplikuje architekturę programu, i wymaga uruchomienia pełnych osobnych procesów na komunikację po serialu i na serwer.
Serial już został przekonwertowany na asyncio w c4998de, co już tworzy dobrą podstawę by serwer także zmienić tak by korzystał z asyncio.
Flask jednak to niezbyt wspiera... Na szczeście istnieje aiohttp. Jest proste, działa dobrze z asyncio (pod to powstało :V) i co ważne ma biblioteki zastępujące wszystko z czego korzystam do Flaska.
"A co z moimi wątkami!" - w zasadzie będzie lepiej.
Asyncio opiera się na event loopie, więc jest to dalej jeden wątek, tylko dobrze zarządzany. Jednak event loop ma tę wadę, że jeśli pojedyncze zadanie zajmuje zbyt długo, to blokuje całą pętlę.
Dlatego też asyncio ma nawet kilka sposobów na uruchamianie zadań w osobnym wątku. Polecanym sposobem na blokujący kod jest loop.run_in_executor korzystające z concurrent.futures. Co jest lepszym rozwiązaniem niż trzymanie procesu tylko na Flaska i nie wychodzenie z niego już specjalnie dalej poza to co biblioteki robią czasami w tle (np. pymongo).
Dodatkowo aiohttp jest we wszystkim poza najprostszymi zadaniami (szczególnie w rzeczach wymagających jakiegokolwiek I/O) znacznie szybsze od Flaska. Kilka benchmarków:
- https://klen.github.io/py-frameworks-bench/ (Flask odrobinę szybszy w serializacji otrzymanych danych do JSON, ale aiohttp jest najszybszym frameworkiem gdy potrzebne jest zebranie odpowiedzi z innego miejsca jak np. baza danych)
- https://currentsapi.services/en/blog/2019/03/27/python-microframework-benchmark/.html (aiohttp, japronto i tornado są podobne, z japronto minimalnie na czele. Flask daje ~50% wydajności tych frameworków)
- https://y.tsutsumi.io/2017/09/23/aiohttp-vs-multithreaded-flask-for-high-io-applications/ (w zastosowaniach wymagających sporej ilości I/O aiohttp deklasuje Flaska, nawet gdy ten jest uruchomiony na masie wątków).
Najlepiej wydajność podsumowuje chyba wykres z ostatniego linku:
I tak, wydajność w I/O jest ważna, bo w zasadzie aplikacja istnieje jako interfejs do bazy danych i połączenia z arduino po serialu.
Więc TL;DR - przejście na aiohttp uprości architekturę aplikacji (brak konieczności tworzenia dwóch wątkówi dwóch instancji pymongo/motor przy starcie), ułtawi interakcję webapliakcji z serialem, poprawi wydajność i da okazję do naprawienia różnych błędów popełnionych przy tworzeniu wersji na Flaska - w tym też okazję do zajęcia się #47