Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

github.com

Post reply on HN
Print view View original

41–50 of 192 posts

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#42

Post by FpUser »

cirospaciari wrote: post #34
FpUser wrote: post #30

I 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 clie…

>"Python backed by uWS is crazy fast, but is not an direct comparison to uWS to Go."

Correction. It shows that uWS is crazy fast. Sure if python us used as a thin glue between something like "select username from user" and uWS or send file over uWS then the result is fast. Do something meaningful in Python itself an it will be slow.

This is not to diminish your work. Python is mostly glue anyways so in average the end result should be quite ok

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#43

Post by Ensorceled »

kasey_junk wrote: post #2

This is a python wrapper around libuv not a pure python solution (not that it’s bad but it explains the click bait title).

I don't really understand this criticism nor why it's "clickbait". I have 12 "unpure" python packages in production. If my app ever needs WSGI, I'll have 13.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#44

Post by znpy »

I'm reading some arguments and counter-arguments in this thread, and in my opinion it kinda boils down to what point of view you're having.

If you look at it as a framework that minimises the networking overhead, then fine, it's an interesting piece of software.

If on the other hand you look at it like a "fast" web framework then things start to change and the discussion gets a bit more complicated.

So for example, you look at the source code of the applications being benchmarked (example: https://github.com/cirospaciari/socketify.py/blob/main/bench...) and you immediately see it's simply returning the string "hello world"). Which means that it's almost 100% of the time running in the fast path / best case.

My guess is that as soon as you start doing any kind of computation in the request handler in normal non-super-optimized python (trival example: validating some headers and/or checking some signatures as you would do with jwt tokens for example) then the python-vs-golang gap will start to go back to favour golang.

And then again, it boils down to what you're doing: anything io-intensive might benefit from the unetworking/uwebsocket beneath, anything cpu-intensive will benefit from the golang compiler producing native executable code.

Nice work anyways.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#46

Post by matsemann »

Ensorceled wrote: post #36
t8sr wrote: post #12

Others 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"?

I actually read their comment as positive, with a small caveat about the benchmarks. It's pretty common to see benchmarks here, where the load is very artificial and hence doesn't translate to real world usage, for instance. So I think it's an okay disclaimer.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#47

Post by cirospaciari »

znpy wrote: post #44

I'm reading some arguments and counter-arguments in this thread, and in my opinion it kinda boils down to what point of view you're having. If you look at it as a framework that minimises the networking overhead, then fine, it's an interesting piece of software. If on the other hand you look at it like a "fast" web framework then things start to change and the discussion gets a bit more complicated. So for example, y…

Actually the benchmark is on https://github.com/TechEmpower/FrameworkBenchmarks with is basically this with more headers, but you are right, is not enought, i used TechEmPower because is very popular. I have some issues (new features comming) open to create an better JWT token support, database and much more, i will post these in the future!

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#48

Post by zelphirkalt »

goatlover wrote: post #29
okaleniuk wrote: post #13

Good 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…

For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.

This is false. Making a new implementation is a practical purpose. Any new implementation will have to work with the spec, instead of idiosyncracies of other implementations. Ergo there are practical purposes which go by how the language is defined in its specification.

Some languages have more of a proper spec than others, of course. If we look at for example Scheme dialects, then they often change their implementation for better conformance with the various rnrs standards. New Scheme dialects often early on try to conform very much to the standard to avoid issues later on.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#50

Post by JustSomeNobody »

okaleniuk wrote: post #13

Good 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…

> ... I'm fighting with within my company for a long time...

I bet that's fun.

> There is no such thing as an "interpreted language"...

In the common vernacular, yes, there are.

Post reply on HN