51–60 of 67 posts
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 o…
Earlier quoted context omitted.
My point is that out of the gate I'd rather have 2011 tools running on 1999 hardware than 1999 software running on 2011 hardware. A 2011 dev team will run circles around a 1999 dev team because their tools are better and allow them to iterate much more quickly. By the time your startup overwhelms a Pentium 3 server you should have enough profit to by new stuff.
Good luck getting a PIII to serve Ruby on Rails content fast enough to keep people interested and cheap enough to still make a profit from advertising.
You could end up having 2011 technology on 2014 servers competing with 1999 tech on 2011 servers.
Earlier quoted context omitted.
Studies have shown that people convert better and view more pages if a site is faster [1]. And page load speed is a factor in your Google ranking [2]. [1] http://www.watchingwebsites.com/archives/proof-that-speeding... [2] http://googlewebmastercentral.blogspot.com/2010/04/using-sit...
That's all well and true but honestly, how many currently unprofitable sites would become monstrously profitable if they could increase their requests per second by a factor of 5? The study you link to shows a decrease of in rev of 5% by adding 2 seconds of load time vs. 50 ms. There are very few businesses whose costs are dominated by servers. Most spend more on a single developer than servers. Yes, Google, Twitter,…
But website speed is one of those things (among many others!) that has a measurable impact on your business. This isn't just a nerdy pissing contest.
Earlier quoted context omitted.
1) AMZN and GOOG have proven that pageload speed does in fact directly relate to profitability. 2) Regarding "The vast majority of sites don't need to scale beyond a single server," you could make the same point that the vast majority of sites are not profitable either. It's a total non sequitur in either case. 3) Your point that it "costs less" to develop in Ruby which can increase the profitability of your site is…
On your point #3. Actually, you are incorrect. Profit is revenue - all costs. Whether or not it counts as COGS is only relevant for gross margin, a metric which isn't the best to judge software companies. R&D is an expense, so it affects your profitability and your net margin. If your company spends $100 less, that's $100 more you have in the bank, $100 less that you need to sell people on. http://www.investopedia.co…
Lots of software companies have gross margin's north of 60% or even 80% (GOOG, afaik) which is unheard of in other industries.
If you focus your business on growing revenue and having a reasonable gross profit margin, you are focusing on the right knobs. If you are focusing on decreasing R&D as a means of maximizing net profit, you are focused on the wrong things.
and that's why we use cppcms, nginx & mongodb. thousands connections per second with templates, localization, setting timezones, db queries...
However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing:
Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, just because template substitution is so damn slow if you don't preload templates, and the obvious way to do it is calling :erb (you see this in all the Sinatra code around, in the examples, and so forth).
10 requests per second instead of the 1000 you get even with 'N' includes if you perform a faster substitution, or if you preload the templates, or using any other trick, is a huge difference.
I'm happy that I received so much feedbacks, thank you all! However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing: Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, j…
In case you want raw rendering speed, you don't choose PHP or Ruby or any other high-level language. You go for straight C/C++ instead -- that's what companies like Google do; that's what Adobe did for Photoshop.com, that's what Yahoo does too for various web services they provide.
We pick PHP, Ruby, Python or whatever because there's a point of diminishing returns. For our apps 10 extra requests per second do NOT matter.
But 1000 reqs per second do matter, but for a real world app, not for a dumb hello world that doesn't do anything -- and even that may be insufficient, as depending on your use-case you may need 100000 requests per second out of a single server.
AND performance on the web == page rendering time, not requests per second. It gets pretty damn hard to have 300ms page loads, and IMHO this is where template rendering could make a difference, but again, not that much.
I'm happy that I received so much feedbacks, thank you all! However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing: Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, j…
I don't get your article. You're yak shaving, bothering with meaningless issues. In case you want raw rendering speed, you don't choose PHP or Ruby or any other high-level language. You go for straight C/C++ instead -- that's what companies like Google do; that's what Adobe did for Photoshop.com, that's what Yahoo does too for various web services they provide. We pick PHP, Ruby, Python or whatever because there's a…
"you don't choose PHP or Ruby or any other high-level language".
Why? There is no technological limit, the template substitution should be fast, with minor coding effort it can be fast. It's just lame code. We are not speaking of algorithmic code.
Probably language speed is not involved at all, it is just as lame as the framework reloading the template at every page view. And even more lame than that given that even my test loading the template every time was faster.
Earlier quoted context omitted.
I don't get your article. You're yak shaving, bothering with meaningless issues. In case you want raw rendering speed, you don't choose PHP or Ruby or any other high-level language. You go for straight C/C++ instead -- that's what companies like Google do; that's what Adobe did for Photoshop.com, that's what Yahoo does too for various web services they provide. We pick PHP, Ruby, Python or whatever because there's a…
nonsensical post by definition, sorry. "you don't choose PHP or Ruby or any other high-level language". Why? There is no technological limit, the template substitution should be fast, with minor coding effort it can be fast. It's just lame code. We are not speaking of algorithmic code. Probably language speed is not involved at all, it is just as lame as the framework reloading the template at every page view. And ev…
Databases are much more interesting. You simply can't scale databases up trivially. A N times linear improvement in the code (due to, say, caching) means you don't have to throw N^2 servers (if that's how your database scales) at the problem.
Linear load reductions have superlinear cost reductions for things like databases. Linear load reductions have linear cost reductions for web servers. This is why people don't care so much.
Though yes, it would be nice to see Ruby templating a little bit faster.
Neither matter, what matters is profitability. It doesn't matter if you can serve 10,000 requests per second if the cost of that request exceeds what you're paid for it. For most sites ruby is profitable, the value add from ruby is decreased cycle time between releases which can increase the profitability of your site more than increasing the pages per second can. The vast majority of sites don't need to scale beyond…
1) AMZN and GOOG have proven that pageload speed does in fact directly relate to profitability. 2) Regarding "The vast majority of sites don't need to scale beyond a single server," you could make the same point that the vast majority of sites are not profitable either. It's a total non sequitur in either case. 3) Your point that it "costs less" to develop in Ruby which can increase the profitability of your site is…
AMZN and GOOG have proven that pageload speed does in fact
directly relate to profitability.
On the other side, client-side optimization does help your servers: imagine if you cut from 60HTTP requests to just 6—and did that with proper caching policy, so your servers won't be hammered on subsequent page loads just to answer "304 Not Modified".
Ever since I got interested in client-side optimization (a bit over two years now) I am amazed how neglected this aspect is. I may be biased, of course.