Serving Files in Python: How FastAPI Failed Us | Hacker News Reader

Serving Files in Python: How FastAPI Failed Us

medium.com

5 pointsalsadi10 comments

As the post points out, Python web frameworks have historically not prioritized improving the performance of serving static files, and that seems… fine?

If we assume that all projects have a finite amount of engineering effort available, then triaging is expected. The best practice for production web applications for decades has been to serve them from behind a reverse proxy. From there, it is usually fairly trivial to use path matching to serve static files from the reverse proxy itself, a tool that is much better suited to this purpose and can easily saturate any link you throw at it without breaking a sweat.

It seems perfectly reasonable for the maintainers of these web frameworks to defer improving the performance of static file serving indefinitely given this.

Many things have changed since the old days. In PEP 3333 sendfile is exposed as opposed to PEP 333 (so in the WSGI days they had no way of doing it, but in ASGI they can do it).

The assumption that nginx is always there no longer hold, specially in microservices, ex. Running behind haproxy (does not service static files) or running bechind cloud provides like AWS ALB.

These don’t seem to be equivalent comparisons when you start using different ways of running the applications and whatnot. On one hand this compares uvicorn running an ASGI FastAPI app and another tests a raw script running a server it seems. I need to do some research on aiohttp’s server to speak definitively but as written, I don’t trust these results.

I made it like that to be as fair as possible and as simple as possible. I've done other experiments with same results. If you think I was not fair to the fastapi part feel free to edit the fastapi part in the form of github gist. And give me the link.

BTW being ASGI is not excuse because ASGI spec (PEP 3333) have a section on how to expose and make use of sendfile kernel routine.

https://peps.python.org/pep-3333/#optional-platform-specific...

You’re correct, sort of. But you’re not testing JUST FastAPI’s performance, you’re also testing Uvicorn’s. For them to be equivalent tests, both need the same run patterns. It’s closer to comparing Flask running as a script with flask running behind gunicorn as written and as I read it.

And no, I’m not going to fix your benchmarks for you. This does not provide any value to me but does come at a time cost.

I appreciate you raising the issue and performing research on it, that’s valuable and I applaud you for that. I simply don’t believe that this is a valid benchmark from a technical soundness perspective.

As I pointed out in my other comment, serving a static file should be a single call to a kernel routine called sendfile (sendfile in c or in python io.sendfile or loop.sendfile). No loop, no memory copy, no further context switch.

Again if you think I was not fair to fastapi, suggest a change to the fastapi part. Do not cripple the competing solution.

If you want believe the time is wasted by the introduction of uvicorn layer as opposed to pure python implementation, I can run the fastapi in pure python ASGI without that layer, it would be worse. Because you uvicorn is one of the best implements.

here I've eliminated uvicorn, nothing changed

https://gist.github.com/muayyad-alsadi/3a1e1cdbafca34df8b178...

Looking forward to the pull requests

It's reported here and they suggest adding nginx with x-accel which is basically surrending.

https://github.com/tiangolo/fastapi/issues/5803

Reply on news.ycombinator.com