HN Explorer

28 comments

[ 2.6 ms ] story [ 68.3 ms ] thread
thesuavefactor
Won't the fact that it's written in Python make it too slow for high traffic sites or APIs?
rcarmo
Zato (https://zato.io/en/docs/3.2/index.html) is Python based and used in production at many places.
anonzzzies
But is it performant? People use and do many things that are awful in production, so that's not really an objective plus. Also; not that many systems need that much optimised performance, so it might be ok to be slow if there are many nice features that are more important.
k4k4
I'll write some JMeter test (or even simpler way) to check how efficient it is. And return with this information.
anonzzzies
Only asked if it was performant based on what the parent said about Python. But cool.
k4k4
Results using Powershell with setup: Windows 11 / I7-13700F / 16GB RAM / Z790 chipset With usage of this script: https://gist.github.com/Veinar/bd8abc12ed3ce3367980da5a335f7...

Used rules that are example within repository.

Results: https://pastebin.com/61Fyy2Pe ( too long to past it here... sorry )

Request Time: The average request time in all tests is about the same, ranging from 0.006 to 0.007 seconds. Max request time does increase with more requests; it peaks for the most substantial test of 100,000 requests at 0.136 seconds, which does show that some requests take much longer.

Requests per Second: The number of requests per second is highest in the smaller tests, around 143 RPS for the 10 requests, whereas for 100,000 requests it goes down to about 122 RPS. A probable conclusion in this case could be that while increasing the number of requests, some little slowdown starts to develop in the system.

Percentiles: The median, which usually stands at approximately 0.0035 seconds, essentially means half of the requests are done in under that time. The far higher values of the 90th and 99th percentiles just prove that while most of the requests may be fast, the others take considerably longer.

In general, it performs quite well under a reasonable load but biffs a bit if the number of requests is increased.

I can test OKD/k8s on Thursday at the earliest.

dsuch
Hi, I'm the technical founder of Zato Source.

In real-world, business and enterprise situations, which is where Zato is used, about 99% of latency comes from the backend systems that your API integration platform integrates.

These are all the databases, CRMs, IoT, cloud and other software or hardware components that you'll be integrating.

Whether you use Python or not, they're always going to be the culprits.

That it's very convenient to integrate complex systems in Python is what does matter though.

Consider that a network of hospitals, an airport, or a telecommunications operator will have at least 50-500 different sorts of systems to integrate, and to do it properly you need to have a team of at least 6-10 people working for several years.

Looking at it from that perspective, taking the whole enterprise into account, Python is the only choice.

It's easy to find people with backend experience who will be eager to work on API-heavy projects, new people leaving universities know primarily Python, and the kinds of complex business logic that is needed to handle such scenarios are best expressed in a very high-level language.

Here's a few articles for you to explore this subject further:

https://zato.io/articles/index.html

jitl
Asking about performance, “production”, fast/slow/okay, etc is all relative and whole depends on what volume of traffic you get in production and your latency demands; without including a few ballpark numbers the conversation is pointless.

A lot of people on HN say things like “for 99% of production apps Postgres is perfect”, but I consider Postgres a bit lackluster because above that scale it’s more annoying to manage than “worse” dbs like MySQL. The difference in our takes is because my “production” needs look very different from their “production” needs.

(I personally wouldn’t put an interpreted GC language in the request pathway for my production app; we sometimes use Cloudflare functions which are JS, but a very heavily optimized JS runtime and even that is a bit concerning)

anonzzzies
I agree with you, and also about the Postgres part. And that was my point: if it's performant enough or not depends on the use case; it's just here on HN everyone thinks they 'will make it' (something something facebook/google etc scale) while they won't. So then anything works fine, because you have got no traffic or data at any significant volume.
k4k4
To be honest, I don't want to make a career out of it and I didn't plan it for this project, I just needed a tool like this, so I wrote it because I was tired of configuring Apache :) I thought it might be useful to someone else, so I published it here. Thanks, I just had to say it
dsuch
Python is fast and it's a good choice as a career language for sure.

Now that the GIL will be removed and adding a JIT is an inevitable step as well, we're looking into replacing everything written in Java with Python in the perspective of the next 10-20 years, depending on how soon people retire in a specific geographic region around the world.

The generation of people who, between 1995-2010, rewrote everything from C++ and COBOL into Java is now in their late 40s and 50s, so it's safe to assume there will be plenty of work for Python people until the next generation begins to mature around 2035-2040.

Now, whether it makes sense today to rewrite in Python something like a proxy, which is not a very complex type of software in itself?

If, starting today, you'd like to build within a year a proxy for something like StackOverflow, it's better to leave it for lower-level languages, like Go and Rust. These are replacements for C and C++, rather than Java, so they would likely be a better choice.

That said, my real message is, don't stick to writing such simple software for too long anyway.

If it's for educational purposes, to learn how all the various protocols work, or how to design server-side software, or to learn how to build an online community, that's a different story.

But you have this high level language in Python that lets you easily accomplish things that the lower-level languages just aren't best suited for, so once you wrote your first proxy and it can handle a few hundred or thousand requests/s, pick a high-level goal and work towards that instead! :-)

jitl
> Python is fast

Compared to compiled languages and JIT languages CPython is not fast, and removing the GIL does not improve the single thread performance of the language, right now it causes a 1-2% performance regression of single thread. Something like request validation seems like it wouldn’t benefit from more threads much; or if you need N threads to validate a request in 1ms in Python, it’s likely you could validate the same request in 1 thread in 1ms with another language.

dsuch
Your analysis is very much correct, and that's why it doesn't make much sense today to rewrite reverse proxies in Python if your goal is raw performance.

Whether it's going to be a worthy goal in the future, I'm not quite sure. I consider this class of software an already well-researched subject in a congested space, and I'd just move on to something more interesting, to a greener field.

k4k4
I mostly agree with you, I learned java at university but dropped it because python (mostly scripts) are very useful for DevOps / SysAdmin work. I definitely agree that writing proxies in Python is not the best idea, but it is the language I know best. And yes, it's not a high-level goal, but as I replied to someone earlier in this comments section. I don't want to make a career out of this, I just wrote a tool that was needed in my organisation and brought it here because I thought it might be useful to someone. Thank you for the extended comment.

P.S: Yes I am looking for some high-level project to participate in or just help with the knowledge I have.

tluyben2
I feel your pain. I have been making things like this in Go;

https://github.com/tluyben/go-proxy

https://github.com/tluyben/redis-sentinel-proxy

just to make them easier to instrument for my experiments. The first one I made because after trying all tutorials on haproxy/nginx to make proxying work without the target domain being resolvable (so no dns entry until it's up), I got annoyed (nothing worked while everything only and gpt said it should work) and just did it like this. Also it makes it very easy to throw in my own, complex as I want rules and logging and telemetry (to whatever I want) at any level.

The second I needed to test an existing, not able to change (they have an old version running they cannot update at the moment, don't ask) software against a redis sentinel setup.

The main thing is that I am more and going towards having the program language as config instead of greenspun's tenth rule where everyone builds some annoying and limited 'almost (usually esoteric) programming language' as config language over time. I want that hard lifting to be done in my native language (Lisp, Go, Rust) and have the config be for ip addresses and ports only.

andrewstuart
Similar but not quite the same is "forward auth" which is supported in Caddy, Nginx and Traefik Proxy and others as well.

With "forward auth", when the server receives a request it first sends the key information about the request to a separate HTTP server - if the response is a 200 then the proxy server continues processing the request, any other response rejects the request.

You can do all sorts of authorization and authentication and some validation (the request body is not typically sent to the forward auth server).

I wrote Checkpoint401 which is a forward auth server desgined specifically for doing the job of handling forward auth requests from proxy servers. Its written in TypeScript/Deno - all you do is write short authorization functions. https://github.com/crowdwave/checkpoint401

One of the good things about forward auth is that it is not a proxy so it is not sitting as a barrier in between client and server shoveling data back and forth - forward auth focuses only on examining the inbound request - this makes things more simple.

Forward auth does not have all the validation and filtering which Dracan seems to have but they solve some similar problems.

jitl
I would expect my web application framework to handle all of these tasks, except perhaps header filtering. If it didn’t I’d rather fix that problem in the web application itself instead of adding a complicating layer of infrastructure that I now need to include in integration tests and release process.

I see some merit to moving the size limits etc out of the application to reduce CPU waste there on overly large requests, but either way I’m still burning some CPUs on it.

Is the use-case for this mostly about sticking some validation in front of a system who’s code you can’t or don’t want to modify for some reason, like in front of Wordpress?

k4k4
Yes, I agree that applications themselves should handle requests that are not correct for them. I in my experience (maybe not so great :)) have encountered several times products even of large corporations that goofed up with problematic requests and/or payloads in that request. But yes I agree with you,it is adding an extra layer and complexity to the deployment, but sometimes it is a very convenient tool - for example as I mentioned before if you don't want to use off-the-shelf products like apache or nginx. Which should do the job and sift out the bad from the good.
jitl
I wasn't trying to be dismissive, I really am curious to hear more about those use-cases, it's interesting because its not something I've experienced or know much about
k4k4
We had a problem with a solution from a large international supplier. While doing an external audit (pentesting), we came across vulnerabilities and the possibility of ‘breaking’ the system as a whole (apart from the fact that natively the system did not support service-mesh, which was required by the client...). So, to mitigate the open vulnerabilities and add service-mesh (sort of), we used Apache (httpd), but writing the configuration and figuring out how to patch it well was driving me crazy. That's why this solution was created, if I'm honest it took me a week to write it, which is about the time I had to solve the problem described earlier. I got the green light from my superiors for something of my own and that's how this project came about. Plus the fact that I wanted to see how rusty my Python was :)
besprim17
Big enterprise solution and custom not well tested solution, it smells like possibility of failure. But fingers crossed ;)
k4k4
That's why i can focus on making it even better :)
stephenr
a quick perusal of the listed features makes me think HAProxy would be a better solution for this.
k4k4
Ok, HAProxy is a potential solution, but according to the description I posted, the idea behind this project is to reduce the writing of configuration files. Instead of writing an elaborate conf, just provide two JSONs to achieve the same thing. And yes I am aware of the fact that solutions like Apache, HaProxy and NginX are more popular and preferred for large solutions. I do not want to create yet another miracle product in well researched matter. But I am grateful for the feedback :)
stephenr
Ah yes, how silly of me. Writing two config files in fucking JSON of all things is absolutely better than writing one config file.
k4k4
Firstly, you don't have to be rude. I won't fall for this bait. Secondly, if you are tied to writing one configuration file, I understand, after all you have a free choice. For me, the separation of logic is a positive aspect, because I don't have to think and search for entries about the specific server I'm proxying to. JSONs used here are overcomplicated I see. And the difficulty of mounting configuration files from ConfigMap with one file or two is practically the same - yet with this software you store two files in ConfigMap. I understood from your post that you are a HAProxy fanatic and I won't bother you in any way.
besprim17
Didn't you read the description? This is written by an amateur probably as the first major open source project. It is intended to be an alternative to (the configuration of) known and used solutions. The fact that the author came up with two jsons.... just accept it?