[HN Gopher] Show HN: FastWSGI, an ultra-fast WSGI server for Python
___________________________________________________________________
Show HN: FastWSGI, an ultra-fast WSGI server for Python
Author : james_roberts
Score : 31 points
Date : 2021-12-15 20:47 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jedberg wrote:
| Those are some amazing performance metrics! What's the catch? Is
| there a tradeoff or did you really find a 10x efficiency?
| james_roberts wrote:
| Thanks! I was quite surprised myself when I saw the numbers for
| the basic WSGI app. I'm still trying to figure out exactly why
| my server is so much faster than other servers out there...
|
| My guess is that I avoid calling Python as much as possible.
| Most of the parsing and the `start_response` code is all
| written in C instead of Python.
|
| Flask applications seem to have some bottleneck. I don't see
| the same performance numbers as I do with the basic WSGI app.
|
| *A note: Those tests are just "Hello World" tests on a single
| worker. They should be taken with a grain of salt...
| dabeeeenster wrote:
| Would love to see benchmarks comparing this to FastAPI?
|
| Thanks for this project - will definitely be keeping my eye on
| it!
| necovek wrote:
| FastAPI is an entire web framework using ASGI, whereas this is
| just a WSGI server.
|
| You could compare FastAPI vs FastWSGI+Flask or any other WSGI
| framework.
| james_roberts wrote:
| I've been developing a Python extension, written in C, that
| provides users with an ultra-fast WSGI server that they can run
| their WSGI applications on (Flask, Django, uWSGI etc).
|
| I have also recently managed to get it working on multiple
| platforms (Linux, MacOS and Windows).
|
| If you want to significantly speed up your WSGI based
| applications, check it out!
|
| It is still in early development at the moment. Any feedback
| would be greatly appreciated!
|
| === [Links] ===
|
| Github: https://github.com/jamesroberts/fastwsgi
|
| Pypi: https://pypi.org/project/fastwsgi/
|
| Performance comparisons against other popular WSGI servers:
| https://github.com/jamesroberts/fastwsgi/blob/main/performan...
| vangelis wrote:
| FYI, you have a typo in the graph `Requests served in 60
| seconds`. server'd.
| [deleted]
| james_roberts wrote:
| Thanks, nice catch! I will update that.
| necovek wrote:
| With Python, benchmarks that matter are what's the maximum
| performance you can get out of a particular hardware in the
| most optimal configuration for the tool in use. (This was most
| obvious with the async framework benchmarks)
|
| Perhaps other WSGI frameworks are not achieving 100% CPU load
| and FastWCGI is, and you could easily run them with multiple
| worker processes to get the same CPU load and comparable
| performance? (this is just wild speculation)
|
| I don't know, but that's the kind of benchmark I'd like to see:
| eg. what's the maximum performance you can get out of a, say,
| 4-core CPU with each of them with whatever configuration
| stresses the CPU completely, and what are the other metrics you
| might be seeing (eg. asyncio will basically net you lower
| memory use, but not any better performance in RPS)?
|
| It'd also be good if the benchmark tool is not running on the
| same CPU though, as long as you've good a sufficiently fast
| interconnect.
| necovek wrote:
| Not to be taken badly, results you post are amazing and point
| at a greatly optimised request handling! But with these
| benchmarks you do not demonstrate the practical value over
| any competing tool (just that your worker threads can do more
| in the same time, which is more of the "good engineering"
| pat-on-the-back type of thing :).
| james_roberts wrote:
| Thanks for the feedback! Yeah, the benchmarks just
| highlight higher numbers in very simple tests. They should
| definitely be taken with a grain of salt. I can try add
| some more practical highlights.
| james_roberts wrote:
| Yeah I don't have an optimal benchmarking setup currently. I
| have a 16-core CPU that I run everything off (server +
| benchmarks = not ideal).
|
| I've been working on adding multiprocessing to FastWSGI (only
| works on Linux at the moment). The RPS almost scales linearly
| with the number of workers. At 4 processes it hits +260k RPS
| with decent CPU utilization.
|
| I can definitely add more details to the benchmarks. Thanks
| for the feedback!
| necovek wrote:
| It's more of a question how other tools need to be
| configured to get a similar CPU utilization, and what RPS
| would they hit in that case?
|
| I'd create a VM that you can load sufficiently well with
| FastWSGI, but other tools might need more worker threads or
| worker processes added to put the same load on that VM.
|
| Basically, what matters practically is what's the maximum
| you can pull out of this hardware (whatever the
| configuration is)? Those are then really comparable.
| nerpderp82 wrote:
| In real world performance it doesn't appear to be that much
| faster than Bjoern, which you also surmised that Flask is the
| bottleneck.
|
| Are there other Python WSGI frameworks that can take advantage
| of FastWSGI?
|
| Why is Flask as slow as it is?
|
| Since this is C, what security mitigations have you put into
| place?
| james_roberts wrote:
| In theory, any framework that follows the WSGI guidelines
| should be able to run on top of FastWSGI and take advantage
| of its speed.
|
| There are many frameworks out there. I do intend to test out
| some more. For now I've only tested the popular Flask
| framework and a simple bare bones WSGI app.
|
| Flask was never developed to be lightning fast. Even still, I
| am quite surprised at how slow it is now that I've seen what
| kind of numbers can be achieved. I haven't looked deep into
| it to see where the issues might be.
|
| As for security, that is a work in progress... I definitely
| wouldn't use FastWSGI in production in the projects current
| state. It's still early days in terms of development.
| barbazoo wrote:
| > provides users with an ultra-fast WSGI server that they can
| run their WSGI applications on (Flask, Django, uWSGI etc)
|
| I thought this was an equivalent to uWSGI, what's the benefit
| of running uWSGI on top of FastWSGI?
| leetrout wrote:
| Would love to see uwsgi added to the benchmarks. It used to be
| much faster than gunicorn.
___________________________________________________________________
(page generated 2021-12-15 23:00 UTC)