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

181–190 of 288 posts

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

#181

Post by vidarh »

Doxin wrote: post #173
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…

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 easy to make a rewrite better in all kinds of ways, including size), it was ~700 lines, far easier to read, and supported far more functionality, so I put it in production.

Was it slower? As usual that depends what you mean by "slower". It consumed 10x more CPU, but it also did much more work (e.g. supporting more flexible routing of messages etc.). The throughput, however was the same, and 10x more CPU means that maxing out the network connection took 10% of a single core instead of 1% of a single core.

For some types of tasks CPU is the most important thing, but for a lot of tasks you'll be IO limited. And for a lot of tasks that people think are CPU limited are really down to poor IO handling (causing excessive context switches e.g. through lots of small reads is a common one)

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

#182

Post by unnouinceput »

splintercell wrote: post #132
unnouinceput wrote: post #45

Earlier quoted context omitted.

why tho? In real life if you're in need of handling millions of users per second, I bet you're already part of FAANG, at which point you simply open offices in each country and deploy local servers.

Doesn't WhatsApp story contradict to what you're saying? They handled millions of users per second, weren't part of FAANG and this helped them get acquired by FAANG and a high valuation for being a very nimble team and architecture.

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.

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

#183

Post by vidarh »

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…

A lot of developers never get proficient on one stack. Much less more than one.

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

#184

Post by pdonis »

neurostimulant wrote: post #94
heelix wrote: post #77

Earlier quoted context omitted.

I'll find out myself. Just got handed a codebase that is a mix of Python/Gunicorn/node when this sprint started off. I've seen the word gunicorn in the repo... but still don't know what it does yet. First time for this old back end Java/C++/XQuery programmer, so how hard can it be? (On the plus side, seems my Jetbrain kit includes PyCharm, so I've even got an IDE!)

Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend. A python webserver is more optimal when used in multiprocess configuration (as opposed to multithreaded configuration, where python sorely suck at), and gunicorn will do that for you automatically, routing each http request to available worker process in the pool.

> Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend.

Or a pool of asynchronous "green threads" using any of a number of libraries (gevent is the one I'm most familiar with). The thing to avoid is mixing the two (multiple processes and green threads).

> A python webserver is more optimal when used in multiprocess configuration

For CPU bound worker tasks, yes, this is true. For I/O bound applications, not so much; asynchronous I/O can handle the same I/O load with much fewer resources (particularly as forking Python processes uses a lot more memory because so much of the memory in the Python interpreter is dynamic, so you don't get a lot of benefit from what in a compiled language would be shared read-only code that doesn't need to be copied for every fork).

> (as opposed to multithreaded configuration, where python sorely suck at)

Yes, the limitation of the GIL is one of Python's worst warts. (It looks like there are finally efforts to remove it, but it's taken a long, long time.)

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

#185

Post by Doxin »

Aeolun wrote: post #145
yowlingcat wrote: post #58

``` First of all, it does not take "that much machine" to serve a fair number of clients. 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. ``` Another day, another questionable premise for a blog post. No, @rachelbythebay, the question is not "if n…

> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.

> I think the point of this post is that most new programmers do not know things can be faster

Related to this: programmers who know an ORM or two but never learn SQL proper.

At my job I refactored a giant, slow, memory hungry reporting task into a single sql query. It used to take 10s of minutes to collate 1000s of datapoints. Now it takes 10s of miliseconds to collate a factor 10 more data. Never mind after I added some indexes to speed the thing up.

Knowing about the layer below the abstraction you're working at can be rather useful at times.

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

#186

Post by radiator »

WilliamEdward wrote: post #150
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…

I don't know why rachel doesn't ever post source code or simply say what architecture she's using. I'm left to assume it's just plain c++. I'll just stick to python thanks.

Posting the source code runs the risk of having something to defend oneself, instead of just having targets to criticize.

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

#187

Post by pdonis »

throwaway894345 wrote: post #155
pmoleri wrote: post #130

Earlier quoted context omitted.

> probably easier than using whatever async/await interface your language has Is it? I haven't used threads directly in a while, but I remember dealing with sinchronization issues. Problems that just don't exist in single threaded node with async await. I find the async Promise or Task to be a more useful abstraction than the thread. Although, you need threads or a task dispatcher with a pool of threads if you need t…

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.

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

#188

Post by vidarh »

kelnos wrote: post #170
mdszy wrote: post #80

Earlier quoted context omitted.

Twitter ran on Rails until 10 million users.

But how many instances did they have running that app, and at what cost? Did they have to build a ridiculous amount of caching in? And wasn't that the time period where they were incredibly unreliable to the point that their "fail whale" server error page became a running gag?

Twitters architecture was a bad joke. Many to many communication in a scalable manner has been a solved problem from decades: you federate. You assign users to buckets, you assign buckets to servers. You route messages like you'd route e-mail. Been there, done that. The federation does not need to be outwardly visible.

Twitters problem was a too centralized architecture not Rails.

And I say that as someone who at the time hated Rails and who still hates Rails. I find it bloated and over-complicated. It may even have led them to make bad architectural choices because of how it was structured.

But they still did make bad architectural choices, and they fixed those choices at the same time they moved off Rails.

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

#189

Post by pjc50 »

29athrowaway wrote: post #125
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…

1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.

C# doesn't require all that much typing if you're using Visual Studio, and even less if you have Resharper.

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

#190

Post by flukus »

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…

I've gone down this rabbit hole recently, I was using apache because it come with a lot of nice to haves beside http handling, like authorization, session and cookie modules, but I wanted to see if c and cgi were viable for modern web development and the results were fantastic. Response times of 1ms while hitting an sqlite database every. I didn't go much further with the performance testing but it could easily handle more than most of the enterprise crap I build ever needs.

C and CGI are a great simple combo. When you get down to it 99% of web development is shuffling data from sql to html and vice versa. It's so stupidly simple that the main code doesn't even hit the rough edges of c, there are almost no allocations for isntance so no memory management to worry about, everything that could possible leak memory or cause security issues is in a handful of utility functions.

No MVC, no DTO's, no view models, no service layers, no templating, no client side javascript, just reading from and sql connection and printf'ing html to stdout. Without all the useless complications I ended up with far less code than the typical equivalent in a high level language with a framework. I'm now fairly convinced that most of the projects I've worked on would have been better off this way.

Post reply on HN