Antirez why did you title the HN post as "almost the same thing". They ARE the same thing. You are 200% correct. Lets turn it around: Is there an example where speed and scalability are different? Maybe the level of concurrency which behaves differently because performance can drop suddenly when you max out, but really that's just another type of speed. Even in an async environment like node.js you may handle a lot of connections but if there's no speed they hang around for too long waiting for something to return so we're back to speed === scalability in all environments.
Lets turn it around: Is there an example where speed and scalability are different?
Well, actually there are a lot of such examples. For instance consider the idea of caching data in shared memory. This is very fast. But the second you've done it with something that has to remain consistent across requests, you can't have 2 webservers any more. You're fast, but can't scale. (Don't laugh, I know of a number of websites that made this mistake at some point in their history. http://www.kuro5hin.org/ and http://slashdot.org/ are two good examples.)
Concurrency and locking issues provide lots more examples. Having fewer locks over large things is much faster than having lots of little locks. But you get less concurrency. For a toy website, MySQL with MyISAM is fine - lock whole tables. Row level locking as done in Oracle, PostgreSQL or MySQL with INNODB is much slower, but it scales.
I know that you think that this is "just another type of speed", but it really isn't. If a critical lock somewhere deep in a database is operating at 95% of maximum capacity, there is basically no visible effect on performance from the lock contention. At 101% of capacity, your database falls over. The characteristic failure mode isn't that you get slower as the request rate increases. It is that you max out your capacity and then crash if you try to go faster. I've been there, and it isn't fun.
Now with all of this said, there is a large, obvious, connection between speed and scalability. Suppose that you are comparing 2 languages, one of which runs twice as fast as the other. You can scale the slow one - just run twice as many boxes. But now you need twice as many database connections. Holding those connections open consumes resources, so you need a bigger database. And so on.
Therefore the faster environment can frequently push off the point at which you start encountering other scalability issues. But speed and scalability are not at all the same thing.
I can give you an example where speed and scalability are different.
Step 1: Create two WordPress blogs served by two Apache servers — one with KeepAlive on and one with it off
Step 2: Benchmark the speeds — you'll see that the KeepAlive one is faster
Step 3: Get a link to each blog on Daring Fireball
Step 4: Notice which server is still accessible (hint: not the faster one)
The server with KeepAlive will fulfill requests faster up to a certain number of people within a certain time span, but past that number it will simply start turning people away while the other server keeps delivering pages a little bit more slowly because Apache's KeepAlive trades capacity for speed.
At any rate, in a real production environment, there are measures you can take to make sure your site is both scalable and fast. Toy examples of poor configurations aren't very informative IMO.
Speed at scale and scalability are the same thing, but speed and scalability most certainly aren't. A server that performs really well on a single request, but slows down as requests are added would be considered 'fast', but not 'fast at scale'.
Yes, there are plenty of instances in which this is the case, and most notably, this is a very common affliction with databases. Also, even in scenarios where you can add more web servers to an application stack, you can't necessarily add more database instances, so you scale those UP instead of OUT.
In summary, the statements made in the article are true, but yours aren't really. In the case of web servers, yeah, they're almost the same thing. In the case of other things, they're generally not.
