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

Web Applications Should Be Compiled

ediblepet.net

Post reply on HN
Print view View original

161–170 of 177 posts

Re: Web Applications Should Be Compiled

#161

Post by ubernostrum »

timr wrote: post #157
ubernostrum wrote: post #121

Earlier quoted context omitted.

"There's no reason that it can't be handling other requests while waiting for a DB response or a pipe." Concurrent request processing most likely belongs in the server, not in the application. "Scaling Rails is a nightmare." For someone who complains of "well-trodden ground" in others' arguments, you certainly seem to have a deeply-rooted belief in the myth that particular languages and/or frameworks "scale" or "don'…

Is it a still just a belief in a myth if you've experienced it first-hand?

OK, so show me a language or framework which has a button you push, or something similar, to scale without any hassle.

Re: Web Applications Should Be Compiled

#162

Post by silentbicycle »

fauigerzigerk wrote: post #149
silentbicycle wrote: post #83

Earlier quoted context omitted.

One problem is that if you work with other people in c++, the 40 to 60 percent they use won't necessarily overlap with yours.

If you work with other people, the odds of their C++ code being utterly broken, inefficient and dangerous is 99% ;-)

Hey, I was showing restraint. ;)

Re: Web Applications Should Be Compiled

#163

Post by timr »

ubernostrum wrote: post #161
timr wrote: post #157

Earlier quoted context omitted.

Is it a still just a belief in a myth if you've experienced it first-hand?

OK, so show me a language or framework which has a button you push, or something similar, to scale without any hassle.

The lack of a push-button solution for all scaling problems does not mean that Rails doesn't suck at scaling.

Re: Web Applications Should Be Compiled

#165

Post by timr »

tptacek wrote: post #160
timr wrote: post #159

Earlier quoted context omitted.

No. Obviously, any individual request/response is I/O bound. But the server doesn't have to be I/O bound.

The top line in a gprof profile of an evented C web server had better be select() (or equivalent) or read() (or equivalent). So I don't follow you here.

Yes, the average server thread is going to spend far more time blocked on I/O than not. But the server should be able to handle more than one request simultaneously.

(Or you can use an event model; the point is, if your server is spending all of its CPU time blocked while under load, then something is wrong.)

Re: Web Applications Should Be Compiled

#166

Post by tptacek »

timr wrote: post #165
tptacek wrote: post #160

Earlier quoted context omitted.

The top line in a gprof profile of an evented C web server had better be select() (or equivalent) or read() (or equivalent). So I don't follow you here.

Yes, the average server thread is going to spend far more time blocked on I/O than not. But the server should be able to handle more than one request simultaneously. (Or you can use an event model; the point is, if your server is spending all of its CPU time blocked while under load, then something is wrong.)

Now you're not following me, timr. An evented server can handle 10,000 connections simultaneously. Run it under load, profile it. Select is at the top of the profile. The program spends all its time in the kernel, waiting on I/O.

That evented server is also faster than the threaded version of same.

What's the compute task you think a program is bottlenecking on in an application that does nothing but shovel data out of a database into a socket based on a btree key?

Re: Web Applications Should Be Compiled

#167

Post by ubernostrum »

timr wrote: post #163
ubernostrum wrote: post #161

Earlier quoted context omitted.

OK, so show me a language or framework which has a button you push, or something similar, to scale without any hassle.

The lack of a push-button solution for all scaling problems does not mean that Rails doesn't suck at scaling.

So how do you figure that it sucks? And don't say "Ruby is too slow" or I really will write you off as reciting tired old myths.

Re: Web Applications Should Be Compiled

#169

Post by eli »

trjordan wrote: post #4

Ranting aside, this seems like a valid complaint. Scaling and performance seem to be reasonably important in web applications, so why not write them in C? If the only complaint is the lack of good tools, why not build those tools? Disclaimer: I don't actually work on web apps, and therefore have no experience with these things.

But the DMBS is written in C (or similar). And that's usually where the heavy lifting takes place.

Re: Web Applications Should Be Compiled

#170

Post by zepolen »

swombat wrote: post #69
zepolen wrote: post #28

Earlier quoted context omitted.

Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible. Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.

Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Not really. Sending and receiving data to/from the browser becomes the bottleneck. If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser. There…

App servers don't handle the spoon feeding of clients, front end webservers do, at least in any sane architecture.
Post reply on HN