UWebsocket, the ultimate performance level!
Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
31–40 of 192 posts
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#32UWebsocket, the ultimate performance level!
<3 i will bring it to Ruby and Lua too!
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#33This is kind of cool, but it all makes sense if your app is a very simple CRUD that spends 99% of time just passing json around. I have this feeling that when you add some more logic there you’ll start noticing that you’re not in a compiled language any more. Your requests will get slower and your memory usage will explode.
Saying that Python is faster than Go with this as a proof looks like overreaching for Me. It only proves that wrapping C code in Python is fast. It’s an achievement, sure, but your app probably won’t be faster when you add thousands of Python lines between request and response.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#34I looked at the tests. There is nothing significant going on when creating response in http server for example. Just spit "hello world". So it appears to be a test of C++ uWebSockets and uSockets libraries vs for example native Go implementation. Do something serious in request handler using Python and then see what happens.
Actually uWebSockets and uSockets will perform better than this (2x at least in my local tests), I need to do a lot of copying, instancing and crossing Python GIL.
Yeah this test basically shows that Python backed by uWS is crazy fast, but is not an direct comparison to uWS to Go.
This test is just an troughput test, with is very useful to measure raw performance.
More tools like caching tools, a better database client etc is need to construct an complete scenario, and i'm working on it! (Maybe in 1 week or 2 weeks will be done)
https://github.com/TechEmpower/FrameworkBenchmarks
https://www.techempower.com/benchmarks/#section=test&runid=1...
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#35This is kind of cool, but it all makes sense if your app is a very simple CRUD that spends 99% of time just passing json around. I have this feeling that when you add some more logic there you’ll start noticing that you’re not in a compiled language any more. Your requests will get slower and your memory usage will explode. Saying that Python is faster than Go with this as a proof looks like overreaching for Me. It o…
i did not say that Python is faster than Go, i say that this Python Framework outperforms Golang Fiber framework in troughput.
I used https://github.com/TechEmpower/FrameworkBenchmarks and in the future i will write fortunes and other benchmarks with have more things going on!
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#36Others point out that calling it a Python framework might be disingenuous, but only if your goal is to compare programming languages. If you're a web developer, trying to pick a framework for websockets, you probably don't care that the Python framework is a libuv wrapper, while to Go framework is native. So well done, I guess? I am really happy to see library authors taking performance seriously! EDIT: This is assum…
> So well done, I guess? I am really happy to see library authors taking performance seriously!
> EDIT: This is assuming the benchmark is actually fair. I haven't looked at it, but it's not uncommon for benchmarks to be comparing apples and oranges.
What is the point of this negativity? Why are you implying that the benchmarks might not be fair because you "haven't looked at it"?
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#37Earlier quoted context omitted.
Would a framework like uvicorn/fastapi be able to achieve similar performance if it were backed by libuv (as opposed to e.g. asyncio)?
Pydantic is unreasonably slow for big datastructures, though. For simple performance tests with simple requests/response it's probably fast. But with lots of the data marshalling happening in python some things are really slow in real life use cases.
Author of typedload here.
Pydantic is indeed really slow (https://ltworf.github.io/typedload/performance.html)
typedload is faster and written in pure python (unlike pydantic).
I know they are rewriting it in rust… but I don't know what will come out of it. After all my pure python implementation already manages to beat pydantic's binary, and when unions are in use, also apischema's binary.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#38Others point out that calling it a Python framework might be disingenuous, but only if your goal is to compare programming languages. If you're a web developer, trying to pick a framework for websockets, you probably don't care that the Python framework is a libuv wrapper, while to Go framework is native. So well done, I guess? I am really happy to see library authors taking performance seriously! EDIT: This is assum…
[deleted]
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#39Fiber is built on FastHTTP. If you know Go top "frameworks" performance characteristics then you would know that you are actually comparing HTTP implementations - ala whether framework is based on FastHTTP or Go standard library HTTP implementation. Framework own % there is for the top 5 almost non-existent. I would assume this is same case where - what ever Socketify is based on (pythons transport layer), is compare…
[deleted]
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#40Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. Just as a piece of evidenc…
You are missing the forrest for the trees. When people refer to a language, most often they are using it as a synecdoche to refer to the whole language ecosystem and not just the the formal language definition. If you look at the Python ecosystem, it is most definitely interpreted.
Off topic, but thank you for introducing the word "synecdoche" to me.