socketify.py

When I see that: https://github.com/cirospaciari/socketify.py/blob/main/bench... It's kind of hopeless, Python still needs to fork per core to get any performance? So if you have 8 cores you're actually running 8 processes, so 8 DB pool etc ...

The “src/“ directory[0] contains compiled .so files. Is this even open source? [0] https://github.com/cirospaciari/socketify.py/tree/main/src/s...

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 (triv

Yeah i have a lot of things to do, to minimize this types of things. But Caching Tools that never cross GIL will boost a lot of performance in real life scenarios too. See https://github.com/cirospaciari/socketify.py/issues/60 I plan to create an native Redis cache and memcache too.