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

171–177 of 177 posts

Re: Web Applications Should Be Compiled

#171

Post by ryah »

warfangle wrote: post #89
ryah wrote: post #17

Web site performance problems usually don't have much to do with the raw executing speed of the language they're written in. The problems derive from poor understanding of how to handle concurrent connections. If your app is written in C, but is accessed through a CGI interface - starting a process for each request - then it's going to be slow. Similarly if you write a web server which makes blocking connections to a…

And then there's situations like porting a Rails app to Lift and seeing a huge improvement in performance without touching the database / storage IO: http://lambda-the-ultimate.org/node/2147 Granted, it's not from the most unbiased source, so take it with a grain ;)

That has to do a lot with Ruby's awful thread implementation. You could possibly port the app again to Ruby EventMachine and see even better performance.

The point is - for 99% of people it's not the language, it's the I/O

Re: Web Applications Should Be Compiled

#172

Post by gdee »

sarvesh wrote: post #72

Isn't that's what CGI is for? If you want a full blown web application framework in C is going to be a lot of work. String manipulation, parsing HTML with standard C libraries is not going to be easy. Java, C# and Python have pretty decent frameworks to do this I don't see the point of writing one using C.

Why does the server side (whatever might live there) have to parse HTML?

Re: Web Applications Should Be Compiled

#174

Post by kingkongrevenge »

axod wrote: post #53
jerryji wrote: post #51

Earlier quoted context omitted.

But as your web application database grows more complex and larger, how do you intend to make them keep up with the 2k req/sec load?

Why would anything need to go to db? :/ Going to db should always be a last, final resort. People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture. In the case of Mibbit, db access is only done for writes, lazily, in the background. The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolou…

Curious if you considered using something like csql or gigabase for a main memory DB? Sounds like you wrote some custom in memory db yourself.

Re: Web Applications Should Be Compiled

#175

Post by timr »

ubernostrum wrote: post #167
timr wrote: post #163

Earlier quoted context omitted.

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.

Write me off if you like, but here's a short list (just off the top of my head) that we've encountered while trying to scale Rails:

Rails has terrible support for database replication (we've had to roll our own). Its caching architecture is laughably bad, and the implementation was/is buggy (again, we rolled our own), and there's next to no support for the kind of robust page cache expiration mechanisms that are necessary to run a large, dynamic site (Observers are only a start). Rails is a memory hog, takes too long to start, has poor translation and locale support, and simply passing a request through ActionController adds huge overhead that cannot be escaped.

And even though you don't want to hear it, Ruby is slow -- even after working around all of the above, we still had to implement a fast page caching layer just to work around the general, all-purpose slowness of Ruby.

But like I said, write me off if you want.

Re: Web Applications Should Be Compiled

#176

Post by timr »

tptacek wrote: post #166
timr wrote: post #165

Earlier quoted context omitted.

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…

You're overgeneralizing. Where your server spends its time depends entirely on the profile of your app. If your pages render (on average) in less time than they wait for I/O, then your server will spend most of its time blocked on I/O.

I suspect that you're thinking of something like a lightweight proxy server, that waits for incoming requests, then quickly hands them off to an app server that does most of the work. That's trivial. If you just profile just the webserver process, then yes, you would expect that most of its time would be spent in wait. But while the proxy server is blocked on I/O, the app server is doing a ton of other things for any non-trivial page rendering.

Re: Web Applications Should Be Compiled

#177

Post by ubernostrum »

timr wrote: post #175
ubernostrum wrote: post #167

Earlier quoted context omitted.

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.

Write me off if you like, but here's a short list (just off the top of my head) that we've encountered while trying to scale Rails: Rails has terrible support for database replication (we've had to roll our own). Its caching architecture is laughably bad, and the implementation was/is buggy (again, we rolled our own), and there's next to no support for the kind of robust page cache expiration mechanisms that are nece…

Seems like you're picking things which are difficult to deal with no matter the language/framework your application code is written with -- DB replication, cache invalidation, etc.
Post reply on HN