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

231–240 of 288 posts

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

#231

Post by pjmlp »

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…

Yes any managed language that has support out of the box for AOT or JIT compilers.

Go, any JVM language, any .NET language, OCaml, Haskel, D, JavaScript/TypeScript

As alternative you can try to use PyPy instead of CPython.

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

#232

Post by pjmlp »

EdwardDiego wrote: post #144
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…

> is there a better stack Apparently, it's C, or ...assembly? According to the comment above yours. Because developer time is apparently cheaper than CPU cycles. Weird.

Any language with AOT/JIT tooling will do.

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

#233

Post by disgruntledphd2 »

kenhwang wrote: post #203
EdwardDiego wrote: post #144

Earlier quoted context omitted.

> is there a better stack Apparently, it's C, or ...assembly? According to the comment above yours. Because developer time is apparently cheaper than CPU cycles. Weird.

Every time I read one her posts, I think, wow she must either work for literally dirt cheap or her code is expected to run on several thousand machines. Most projects just don't reach the scale or steadystate where developer time is cheaper than machine time. It's fun trying to squeeze the last drop of blood from stone, but it rarely makes economical sense.

To be fair, I believe she spent the guts of a decade at Google and Facebook as a Production Engineer, so this isn't really that surprising.

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

#234

Post by throwaway894345 »

pdonis wrote: post #187
throwaway894345 wrote: post #155

Earlier quoted context omitted.

If you’re just handling requests there isn’t much for shared state, so you don’t have to worry about synchronization.

> If you’re just handling requests there isn’t much for shared state No, but if your single listener/server thread is managing epoll for all your file descriptors, you do have to have a way of synchronizing the worker threads with it, so they know when and when not to read from/write to their fd's. I assume Rachel is using some kind of semaphore or other threading synchronization mechanism for this.

Right, there is some shared state, but it’s very minimal.

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

#235

Post by rb12345 »

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…

I think the argument of the article is to pick the right language in the beginning so you save both developer time and runtime and don't have to rewrite in a better language later. For example, Python is a lot slower than threaded C, but quicker in terms of developer time and is memory-safe. If you pick one of the newer JVM languages though, you can get far closer to C than Python in performance once the JVM is running and still keep most of the expressiveness.

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

#236

Post by turtlebits »

rumanator wrote: post #169
turtlebits wrote: post #60

Earlier quoted context omitted.

I disagree. I tried to learn F# a few months ago and the experience was horrible. I followed the tutorial using the aspnet CLI tool and got nothing but errors. I Google’d for a while until I gave up.

> I tried to learn F# a few months ago and the experience was horrible. Switching to a programmig language based on an entirely different programming paradigm is not comparable to switching to a language based on the exact same programming paradigm to develop the exact same application using the exact same design patterns.

I’m completely comfortable with the language coming from Elixir. The problem was the tooling/docs didn’t match the experience.

This was from the official site and many of the commands threw errors.

I think it was a case of incomplete Mac support, which should have been called out.

IIRC I posted on HN about it and got an apology for the state of tooling

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

#237

Post by epicide »

chris_wot wrote: post #168
WilliamEdward wrote: post #159

Earlier quoted context omitted.

In what way is this helpful to newcomers at all? It uses a ton of heavy jargon and no example code.

It’s not aimed at introductory programmers. It’s aimed at more experienced programmers to suggest to them that they can show new programmers what’s possible.

The author never really expresses the intent of the writing, so the reader is left to assume it is meant for them -- experienced programmer or no.

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

#238

Post by kragen »

jefurii wrote: post #149
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…

> I feel like with modern technologies like ... we ought to be able to do a lot of things that we couldn't even imagine doing in 2005... As a self-taught programmer I would say that what all these less efficient bit easier to learn technologies have done is enable people like me who evidently are not geniuses like yourself to write software. Should programming always be an ivory tower thing?

I'm not a genius. I started programming in BASIC. I haven't had a lot of schooling: I haven't had a computer science class since I was 12, and I didn't finish high school. I just didn't stop learning.

Adding unnecessary complexity doesn't always make things easier to learn.

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

#239

Post by kragen »

highfrequency wrote: post #90
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…

> single-threaded nonvectorized C wastes on the order of 97% of your computer's computational power Can you elaborate on what this means exactly? For example, is there some reasonable C code that runs 33 times slower than some other ideal code? In what sense are we wasting 97% of our computer's computational power?

8 cores times 4 SIMD lanes is a 32× speedup; that's where "97%" comes from, as explained in the note I linked to.

It's pretty variable: some things we haven't figured out how to speed up with SIMD, sometimes we have a GPU, sometimes we can get 8 or 16 SIMD lanes out of SSE3 or AVX128 or 32 of them out of AVX256, sometimes you only have four cores, sometimes make -j is enough parallelism to win you back the 8× factor from the cores (though not SIMD and GPGPU). But I think 97% is a good ballpark estimate in general.

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

#240

Post by unnouinceput »

ClikeX wrote: post #207
unnouinceput wrote: post #182

Earlier quoted context omitted.

how that contradicted me? I see this as exactly opposite, as in they became part of FAANG exactly because they managed to handle those users. And let's be real, they handled millions users/second after becoming Facebook. Like it or not FB is no.1 social network.

They got aquired in 2014. They hit 400M users in 2013. By then it was already THE messaging app for several European countries. I know amount of users doesn't equal users/second. But we shouldn't pretend like they weren't able to handle high traffic before Facebook aquired them.

400M in 2013 globally and millions per second does not equal. A simple math says 4x10^8 / 24 / 60 / 60 = ~4.7k users / second. Kind of 3 orders of magnitude lower. Even if you say most users are not spread evenly over those 24 meridians due to Earth being mostly water it will still not get to those millions per second.
Post reply on HN