Comments on: On scaling, performance, and realism

By: Siyaxoxa.com » Blog Archive » Todays links

Siyaxoxa.com » Blog Archive » Todays links — Thu, 26 Apr 2007 07:53:18 +0000

[...] Ruby and Rails scaling and performance [...]

By: KwangErn Liew

KwangErn Liew — Tue, 24 Apr 2007 14:18:05 +0000

Sure, caching is very important. But can you truly cache dynamic pages? If so, doesn't it depend on the architecture of the application itself?

That said, scaling starts from the application design itself.

It's all in the architects. It's less so in programming languages. But choosing the right language and framework to develop the right application can make a big difference in development time which in turn affect scalability/performance to a certain extent.

Nothing is perfect, but how close you obtain perfection is what makes the difference between one or the other.

By: Guy Naor

Guy Naor — Fri, 20 Apr 2007 14:04:40 +0000

I totally agree that caching is somehow forgotten by many developer. I can't count the number of times I had to explain it and how to do it. Many people just refuse to get it. And more than that, you need to know what to cache. For that you do need statistics, or measurments.

As for performance perception, thisis also very true. I have an application that showed a 10x improvement in user percieved performance, and went from unbearable to fast in your last scale, just from compressing and packing JS and CSS files, and loading them from multiple servers.

Guy

By: Kyle

Kyle — Thu, 19 Apr 2007 19:03:20 +0000

DrStankus: That was quite intended. I’ve never heard someone categorize something as nothing to report. It’s a null value that belongs in the set, but does not count towards the number of options ;)

By: Kim

Kim — Thu, 19 Apr 2007 13:37:10 +0000

Caching should be one of the first things you think about when you're launching a site like Twitter.

MySpace learned this the hard way...

By: DrStankus

DrStankus — Thu, 19 Apr 2007 13:35:19 +0000

"In my experience, people generally categorize performance as one of three options:

Fast Moderate (nothing to report) Slow Unbearable "

The number of options you state seems to not scale well...

;-)

By: Standard Deviations » Say What?

Standard Deviations » Say What? — Thu, 19 Apr 2007 08:05:29 +0000

[...] to this warspire post about the Twitter-Rails-Scaling broo-ha-ha here since the warspire site throws a 500 error when I [...]

By: Siegfried

Siegfried — Wed, 18 Apr 2007 15:17:55 +0000

When it comes to measuring the performance it is always easy to do some statistics. But what I have found over the long time, that I am doing programming is: if it is fast, think about the logic behind and most often you find another way to get things done.

For example, do you need a database or just a fast lookup table. Do you need immediate response or is it enough, that the user thinks it is immediate. Can you do the hard work in the background or is it nessessary to do everything once the data is entered and the same goes on and on.

By: james

james — Wed, 18 Apr 2007 07:16:22 +0000

just use common sense. if you’ve developed in another language before, then you can tell immediately that your Rails app runs slower. you don’t have to do a benchmark.

By: Kyle

Kyle — Tue, 17 Apr 2007 22:43:05 +0000

Ilya:

I really dislike the stereotype that "Ruby is slow, but Rails saves time in development." It's a bad viewpoint leftover from the "scaffolding era" of Rails.

My point is that even if you are controlling those variables, many times those are the very variables that ultimately affect end-user performance. Such minor variations I'm referring to are things like processor speed, installed memory, and number of application servers.

In the real world, each server is different. What does it matter if a Ruby app is 25% slower than a Python app in idealized conditions if the Ruby app is running on a machine with double the cores and double the clockspeed as the Python app's server?

Throwing around statistics based on static conditions is of little to no use since the end-result is based on dynamic conditions and subjective opinions.

As long as it is possible and reasonable to make your application serve pages in an acceptable time (subjective), then the rest is irrelevant.

Does it matter if your car has more torque if the wheels are spinning? Races are won on pavement, not on dynos.