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

Old box, dumb code, few thousand connections, no big deal

rachelbythebay.com

Post reply on HN
Print view View original

221–230 of 288 posts

Re: Old box, dumb code, few thousand connections, no big deal

#221

Post by xorcist »

ivalm wrote: post #22

What WSGI do people recommend for python? I've been using gunicorn but this made me think of alternatives. Quick google search found this benchmark [0], is it really that bjoern is much quicker? It seems all other WSGI are ~ equivalent. [0] - https://www.appdynamics.com/blog/engineering/a-performance-a...

Always uwsgi. It's the hidden gem of web serving. It's even useful for other things than Python, and has the operational features you would expect (such as graceful restarts). The more exotic features are a bit less tested however, and it shows.

Re: Old box, dumb code, few thousand connections, no big deal

#222

Post by tetha »

rumanator wrote: post #46
bjt wrote: post #44

Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…

Writing code is one thing though.

Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. In general, you need to integrate the new language into the existing ecosystem. The latter may even be impossible depending on the stack and solution chosen. Just look up those weird Java only caching servers.

All of that is possible, sure. Due to company acquisitions and specialized teams in some areas, we're kinda running the full bingo card of languages.

But there's little denying: We overall spent less time handling language runtimes and language-specific monitoring back when we were java+mysql and that's it.

Re: Old box, dumb code, few thousand connections, no big deal

#223

Post by bluedino »

robrtsql wrote: post #135

> Ever since I wrote about the whole Python/Gunicorn/Gevent mess a couple of months back, people have been asking me "if not that, then what". It got me thinking about alternatives, and finally I just started writing code. I actually want to know: then what? As a web developer who usually reaches for Django or Flask with Gunicorn because I just don't know any better, is there a better stack that doesn't face these pr…

Have you hit a wall in performance yet?

Re: Old box, dumb code, few thousand connections, no big deal

#224

Post by pjmlp »

stev_stev wrote: post #55
rumanator wrote: post #46

Earlier quoted context omitted.

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…

This is where my head always goes as someone who does mostly Asp.Net Core. Why is it always between something like C++ or something like Python? Nowadays with middleware and endpoint routing, asp.net core can be almost as simple as flask (even if that’s not idiomatic or what the docs show you).

Same here, for me it has been mostly about .NET, Java or anything else with JIT/AOT compilers out of the box, after my AOLServer like experience.

Back then we already had Zope and it wasn't blazing fast.

Re: Old box, dumb code, few thousand connections, no big deal

#225

Post by pjmlp »

29athrowaway wrote: post #172
rumanator wrote: post #171

Earlier quoted context omitted.

> 1) .NET APIs change very frequently. ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. ASP.NET Core 3.1 was released a few months ago and there is no end of support in sight. Moreover, the changes between 2.1 and 3.1 were not that many. I've migrated a whole ASP.NET Core 2.1 web service to 3.1 in less than 1 hour. > 2) C# is a very verbose language, that requires a lot of typing. Nonsense…

Compare C# with Kotlin or Scala and you'll find that involves a lot of redundant, boilerplate code.

I wonder when was the last time you used C# then.

Re: Old box, dumb code, few thousand connections, no big deal

#226

Post by kuschku »

EdwardDiego wrote: post #201
kuschku wrote: post #200

Earlier quoted context omitted.

As we've seen in the cloud costs thread, going from python on AWS to Rust on dedicated hardware can push your bills from 30'000$/month down to 300$/month, which more than pays for the dev salaries (especially if you're not paying the excessive and unnecessary salaries of the bay area)

How many hours would you expect that rewrite to take when done by Python developers learning Rust as they do it? And what's the opportunity cost of the new features they can't create because they're rewriting existing apps? If you're arguing that Python has more runtime overhead than Rust, I don't disagree. But there's a reason people invented higher level languages than C. Rust is a far nicer systems language than C…

The reason I’m mentioning Rust is because you can still build your fun part of your application in python, and easily use the FFI to build any performance-critical part in Rust, C or C++.

That said, with Rust or C++ you can – depending on the situation – be clearly as effective, or even more effective than with Python, and you gain an enormous performance benefit (which in turn saves you money, which in turn means you can hire even more developers)

Re: Old box, dumb code, few thousand connections, no big deal

#227

Post by pjmlp »

nexuist wrote: post #93
bsder wrote: post #82

Earlier quoted context omitted.

You ... are not ... Instagram. Okay. Get over it. Python is fine. Threads are fine. Go is fine. Clojure is fine. Java is fine. PHP is ... okay I won't go that far. :) You fix the problem when the cost required to fix the problem is finally less than the opportunity cost of fixing something else.

PHP is fine too. Check out https://laravel.com/ and tell me that doesn't look like a joy to work with.

And it has JIT support out of the box, while PyPy still needs to fight for adoption.

Re: Old box, dumb code, few thousand connections, no big deal

#228

Post by pjmlp »

vidarh wrote: post #181
Doxin wrote: post #173

Earlier quoted context omitted.

Not to mention that python is plenty fast compared to the time it takes to write stuff to the network. Of course heavyweight frameworks like django don't help the equation, but writing fast network code in python isn't exactly hard either.

This is something a lot of people don't get with most higher level languages. My first commercial use of Ruby was in 2005. Not web facing, but messaging middleware. As in a pub-sub type passing of messages between various endpoints. We had a C version. It was about 7k lines to support the bare minimum we needed. As an experiment to teach myself Ruby I wrote a Ruby implementation. With the usual caveats (it's often ea…

And other people don't get it is possible to have high level languages and almost C like performance.

You don't need to give up on JIT and AOT compilation to use high level languages, and this is where current tooling for Ruby and Python ends up losing.

Re: Old box, dumb code, few thousand connections, no big deal

#229

Post by pjmlp »

mdszy wrote: post #80
bjt wrote: post #44

Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…

Twitter ran on Rails until 10 million users.

Until they had to switch to a mix of Java, Scala and C++.

Had they started with them and there wouldn't exist blue wales.

Re: Old box, dumb code, few thousand connections, no big deal

#230

Post by pjmlp »

kragen wrote: post #50

Rachel presumably wrote her server in a reasonable language like C++ (though I don't see a link to her source), but when I wrote httpdito⁰ ¹ ² I wrote it in assembly, and it can handle 2048 concurrent connections on similarly outdated hardware despite spawning an OS process per connection, more than one concurrent connection per byte of executable†. (It could handle more, but I had to set a limit somewhere.) It just…

Despite all my rants here about C, on my travel netbook I switched to XFCE as I could not stand the performance impact of all JavaScript and Python based extensions on GNOME.
Post reply on HN