Myself I built an RSS reader using aiohttp and then forked the code to make an image sorter.
I had a lot of people tell me I was crazy to write aiohttp servers because of the problems the previous poster mentioned but I had a long run of it working pretty well. On the other hand I’ve frequently had the experience of writing something in Python that falls apart like a tower of Jenga blocks the moment somebody else touches it. (Quite different from my experience with Java, Javascript, C#, PHP, …)
Once I started serving images along with the text and using the app over a 2Mbps link it seemed to me the aiohttp server was getting a little unreliable.
Most basically, an aiohttp server can only use one CPU thread at a time with the consequences that if one request holds the CPU for 5 seconds the server stops processing requests completely.. Although the aiohttp server could be reliable if you are almost entirely waiting for data to get back from the database, the residual amount of CPU load is going to put an upper bound on what the server can handle in the best case. If a coder is not so careful you get burned. My RSS reader has an AI component which runs completely in batch jobs, I don’t do any inference during requests which limits my flexibility and makes the application less “real-time” than it could be.
You can imagine systems where one aio server hands tasks off the another aio server but the blocking situation doesn’t get any better and if you want to make the system scalable there has to be at least one multiprocess or multithreaded server somewhere. At some point I am like “I have a 16 core machine but I am only using 1 core like my laptop in the 1990s” It didn’t help that my aio database drivers aren’t in conda which is another build hassle.
So last week I tore up the image sorter and rewrote it in Flask (my aio framework looks like Flask so it’s not too hard) and I run it out of gunicorn, I put a reverse proxy in front to deal with some Tailscale problems so I have IIS serving the images.
> Once I started serving images along with the text and using the app over a 2Mbps link it seemed to me the aiohttp server was getting a little unreliable.
Does that imply that it was due to images being heavier, and thus if you were to stream something like video from aiohttp it would not go so well?
For video I think I'd use nginx or something like that. The aiohttp server is meant for serving dynamic content, nginx is using async io too but it is written in C and optimized in every way.
Currently for my case the worst problem is head-of-line blocking, the system could be downloading 50 large images but to put a tag on a gallery it needs to load a small HTML page for a modal dialog, then it has to populate a dropdown box after a tag category is selected, then process the form request.
Since all these images are queued to download, the system has trouble prioritizing the HTML requests. The best answer to this for me is to build that thumbnailer to get the image size down, but I am also thinking of putting images on an entirely different port.
I had a lot of people tell me I was crazy to write aiohttp servers because of the problems the previous poster mentioned but I had a long run of it working pretty well. On the other hand I’ve frequently had the experience of writing something in Python that falls apart like a tower of Jenga blocks the moment somebody else touches it. (Quite different from my experience with Java, Javascript, C#, PHP, …)
Once I started serving images along with the text and using the app over a 2Mbps link it seemed to me the aiohttp server was getting a little unreliable.
Most basically, an aiohttp server can only use one CPU thread at a time with the consequences that if one request holds the CPU for 5 seconds the server stops processing requests completely.. Although the aiohttp server could be reliable if you are almost entirely waiting for data to get back from the database, the residual amount of CPU load is going to put an upper bound on what the server can handle in the best case. If a coder is not so careful you get burned. My RSS reader has an AI component which runs completely in batch jobs, I don’t do any inference during requests which limits my flexibility and makes the application less “real-time” than it could be.
You can imagine systems where one aio server hands tasks off the another aio server but the blocking situation doesn’t get any better and if you want to make the system scalable there has to be at least one multiprocess or multithreaded server somewhere. At some point I am like “I have a 16 core machine but I am only using 1 core like my laptop in the 1990s” It didn’t help that my aio database drivers aren’t in conda which is another build hassle.
So last week I tore up the image sorter and rewrote it in Flask (my aio framework looks like Flask so it’s not too hard) and I run it out of gunicorn, I put a reverse proxy in front to deal with some Tailscale problems so I have IIS serving the images.