Does the speed of a programming language matter for web applications?

Question

I see a lot of benchmarks between PHP, Python, Ruby, etc all over the Internet. Ruby has gotten a lot of flak for being super slow, which leads to developers refusing to use it for web development for "performance reasons". But does the performance of the interpreter really matter for web applications? Isn't the bottleneck located in the database 99% of the time anyway? So why is everyone freaking out?

Note: I realize that in some edge cases, such as certain mathematical/scientific web applications, performance matters a lot, but I'm not talking about those; I'm talking about your average social networks, Stack Overflows, etc.

Answer 1

I don't think your question is very well-thought out.

First you assert that most web apps don't require fantastic performance on the application-side of things, which is probably true for a lot of them. Then you give some examples of web applications that do require good performance, and wave them away saying that people just write them in C++ or Java instead!

Well, don't you think they might prefer to write them in Ruby or Python? Perhaps that's why people are interested in measuring Ruby and Python's performance!

EDIT: OK, so you're interested in very run-of-the-mill web apps. So then you and I can both see that there are two possibilities:

• Performance actually is important, which is why they are concerned about Ruby and Python and PHP's performance.

• Performance is not important, so they are mistaken, and they are either ignorant of that fact or making an excuse.

Answer 2

Does performance matter? Eventually, sure.

But your website will have to get so large that you're into the millions of hits per month range before it will even be an issue for you outside of traditional optimization (eg proper indexing in your database).

I don't think the Ruby distaste is so much to do with performance (although there have been issues with this). It's more that it's unproven, has a reputation for instability and forced a very rigid framework on you (yes I know you can use Ruby without Rails, etc). I'm not a Ruby fan for the same reason I'm not a fan of the heavyweight PHP frameworks like CakePHP or Symfony: I find these frameworks overly invasive and so heavyweight that you're not doing PHP anymore. Compare this to lighter weight framewrks like CodeIgniter, which have a much better return on investment (imho).

Answer 3

Does performance matter for web applications?

Yes! Even more so than for desktop applications!

With a desktop application, if you need it you can use nearly all of the considerable resources available to your users' computer. With a web app, one computer has to potentially handle running your app for a lot of simultaneous users. If you can't get it to do that easily, you're in real trouble.

Answer 4

It can matter a lot, depending on the context. Most websites are run on shared hosting servers where that stuff adds up. With a few hundred web applications running on the same box you're going to have CPU and memory bottlenecks.

Answer 5

That should not be the focus of your question. Instead you should focus on how the content can be delivered to the end user in the most efficient means possible. If a web application is well written I think any major server-side language is a good choice.

Answer 6

What should keep you shivering scared in the corner is that multiple studies done by amazon.com and google.com have found that a < 1 second decrease in page load time had a significant ( for them ) impact on their conversion rates and therefore profit.

Therefore performance matters a lot, even for small sites. The question is how much will it matter. Losing .1% of sales doesn't really matter when your doing 100 uniques a day, but when your doing 10 million then all of a sudden that .1% costs you a lot of money.

Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006). When the home page of Google Maps was reduced from 100KB to 70-80KB, traffic went up 10% in the first week, and an additional 25% in the following three weeks (Farber 2006). Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007). Experiments at Microsoft on Live Search showed that when search results pages were slowed by 1 second: (Kohavi 2007)

* Queries per user declined by 1.0%, and
* Ad clicks per user declined by 1.5%

After slowing the search results page by 2 seconds:

* Queries per user declined by 2.5%, and
* Ad clicks per user declined by 4.4%

http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Answer 7

Most sites will release first-version code as soon as the site is functional. If they are at all successful, pretty soon there are multi-second pages, and they need to attend to either hardware or software, and you're I guess suggesting an implicit distinction between page code and database software.

Are you wondering if we should not bother with the page code and assume any non-hardware scaling issues are in the database? That's not my experience; although it's usually the database that gets released soonest because like horseshoes, too often close is good enough (as long as the answer is what you expected.)

But I've seen a lot more page code that tried to do what databases are designed to do (e.g. with arrays) than vice versa (e.g. cursors), with equally detrimental consequences on speed and scalability. And optimizing a database query is in my experince less work than fixing PHP code.

I think most speed problems are not the language (or the dbms itself) but rather the quality of the design and the code. So I would think good developers would be more concerned with whether or not a language facilitates good design and good code, not how fast it runs.

Answer 8

There's a couple of different arguments here: because the code is running on your server, and if your code is inefficient, then it's going to overload and degrade the experience for everybody.

The other side of the coin is that you need to be successful for it to matter, as Ted Dziuba so eloquently and profanely said. "Slow" languages tend to be much faster to develop in and more expressive than compiled languages, so they allow a team to get a site up and running more quickly.

Answer 9

In my experience, once you really start getting busy then it's at the database where you can make the most DIFFERENCE.

But i would also add one other consideration, and that's how 'big' your page size is in terms of images, JS and HTTP requests. You could have a very slow site because your blazing fast database and app code created a monster of a web page with bloated JS and images. :)

Answer 10

jfar starts you down the right path. As far as how impactful your language is on this, profiling will likely show that your language is not your bottle neck.

• Avoid per-request compilation like old-scool cgi. Most modern web frameworks need to be resident between requests.
• If it doesn't change much, generate it and serve static.
• Compress. Enable gzip if you can, and strip whitespace and comments. White space is for dev and debug.
• Figure out the prevailing db use case, query or insert, and tune for the right one.
• Cache / render what you can.
• Try benchmarking different app servers if you're ops people will let you change / upgrade.

Any one else have some generic web tuning hints or links to other SO questions?

http://stackoverflow.com/questions/780601/is-there-a-good-book-on-web-application-performance-tuning

Answer 11

You're right. Most of the time the bottleneck will be independent of your server-side language. Of course 90% of all statistics are made up on the fly, but I'd say 9 times out of 10 the bottleneck is either going to be in bandwidth/transfer speeds or database operations.

Assuming you make good use of each language, there are limited cases where the performance of PHP vs Python vs Ruby vs .NET vs whatever will ever be noticed by the user. When things like XML parsing, and compression are done on a very large scale then you may start to notice, but otherwise I'd just stick to what you're most proficient with.

Often times some of the greatest improvements in website speed can come from gzip compression and careful use of caching/content expiration. And both of those things can be configured in Apache or IIS. I wrote about that topic here: http://swortham.blogspot.com/2007/10/three-ways-to-improve-your-websites.html