8 ms·

Poor Man's Scalability

174 points by greenshirt 15y ago

CoffeeDregs 15y ago
Thanks to the author for taking time to write up his experience. That said, this is really basic stuff. How in the world could a home/index page have so many queries that it took 9 seconds? Oh, no indices... Then how could you have built a DB-backed web app and not considered indexing? A better title for the post might be "Scaling Mistakes I Made While Building Our Website and How I Fixed Them".
- eric-hu 15y ago
  I'm very very reluctant to call those mistakes. From the author: > I didn't get too upset here; I expected us to do poorly. After all, we'd spent all of our development time in actually building something people want, not on scaling up for thousands of imaginary users. Perhaps it would be relevant to the conversation if the author could chime in with how many projects or ideas they went through that failed. Perhaps they had to do consulting on the side for income. Premature optimization is a mistake. It's time wasted on delivering minimal value to you or anyone else.
  - eropple 15y ago
    Indices on a database aren't "premature optimization". They're part of understanding your data model, how it will be requested, and--more in a SQL database than a MonogDB database, but still--constraints on the data stored in your database. Claiming basic development practices to be "premature optimization" is a fantastic way to paint yourself into a corner because of stupid decisions in your haste to "get it out the door." Your MVP isn't V if it still takes a second to render your homepage to users, because they'll leave. (Site responsiveness is a huge factor in bounce rate, even for sites that people actually want to look at.)
    - troels 15y ago
      Indexes can most certainly be premature optimisation. There's a cost associated with an index.
      - driverdan 15y ago
        The cost increases significantly by doing it later on. Indexing when you have little data is easy. Indexing on a live site with millions of rows and lots of users can be much harder.
        aptwebapps 15y ago
        Taking it to that extreme is not a valid argument. There's a lot of room between not doing it first and only doing on a live site with millions of rows and lots of users.
      - sjwright 15y ago
        That might be true for some esoteric indexes, but if we're talking about indexing customer_id on the invoices table, it's not premature -- it's freaking inevitable.
        eropple 15y ago
        Yes--and these are the overwhelmingly most common case for a query in most applications. From reading the blog post, it seems like the blog author was either doing pretty frighteningly complex stuff just to render his homepage or he didn't think ahead enough to add fairly standard queryable indices to his collections. Neither strikes me as terribly smart, and the latter strikes me as writing it right the first time, not "avoiding premature optimizations."
    - swombat 15y ago
      I consider Indices to be premature optimisation. Moreover, they're very low level, potentially dangerous premature optimisation. Imho, they should be the very last trick you use to optimise. First, you try and figure out if you can reduce the number of repeated queries. Then you try and figure out if you can get rid of chunks of code that spawn lots of queries altogether, by tweaking the algorithm to do things differently, without needing that data. Then, finally, once you've used every trick to make it all faster, then you apply indices to speed up that handful of remaining queries. If you apply indices first, then you won't spot the other potential optimisations, and when your indices stop covering up for your poor coding it will be much later, and much harder to fix.
  - CoffeeDregs 15y ago
    >Premature optimization is a mistake. Wholly agreed and I often say the same thing. But I do not consider basic indexing on a database to be "premature optimization". I do consider it to be a a mistake since you almost certainly find performance issues (unless the table is small enough that indexing is a mistake), then you'll have to track down the cause of the issues (commonly called "a bug") and then will have to add indexes.
- codypo 15y ago
  Oops, I think I didn't express myself very clearly. When I was sending 20 requests a sec in a load test, the average response time for all the requests was 9 seconds. In a normal case, the page was loading in a fraction of that. Also, we didn't lack all indexes, just a couple of important ones. We've been iterating quickly on the site and we weren't analyzing the performance as our queries were refactored.
  - phadrus 15y ago
    Please stop blogging and start reading about how to construct an application properly.
    - _vn5r 15y ago
      +1
bmelton 15y ago
With the rise of cloud services, and their relative inability to serve naked domains, there are a couple of easy fixes for this. The first is to create a vhost in your webserver that serves an index.htm page on your NON-www url. The contents of that page would simply redirect users to the www.yourdomain url. If that seems like too much work, an even easier fix (truncated for brevity) is to do something like this: var url = window.location.href; if(url.indexOf("http://www") != 0) { window.location.replace("http://www.yourdomain/"); } You'd obviously want to capture the remainder of the querystring and add it in, but that's the general idea.
- dchest 15y ago
  Why not plain old HTTP 301/302 redirect?
  - StavrosK 15y ago
    Please, please use a redirect. The GP's suggestion is not something you want to do. Even better, just use http://wwwizer.com/ http://wwwizer.com/ (look for the free redirect service banner on top).
- jibs 15y ago
  ooh, this looks really problematic on multiple levels (why wait for JS etc). A simple solution, which I've used--and I think the OPs situation is similar--is to just have an additional A-record pointed to the ELB, this should work unless the OP is doing something really fancy. No need for route-53, even go-daddy will let you do this. However, route-53 gives you much better TTL, so if you ever need to re-route..
  - ceejayoz 15y ago
    ELBs change IP if they have to scale up. You really shouldn't point an A record at one.
    - jibs 15y ago
troels 15y ago
It's fairly basic stuff this, but important none the less. Kudos for recommending Yslow (or PageSpeed) - it's indeed brilliant. You didn't mention much about http caching, which I think is probably as important as the other things you mentioned; Not only does it improve performance for the user, but it also reduces load on your server and it enables you to put up an edge side cache for extra performance. As for the problems mentioned with the load balancer - You could have simply provisioned a new instance and installed your own load balancer. There's dedicated packages like haproxy, but you could also just put up nginx or lighthttpd. This machine can later double as your edge cache (Squid). Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does.
- dasil003 15y ago
  > Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does. Agreed. This will have an extremely negative impact on your user engagement. Now if this is measuring end user response time rather than server-side page generation it might not be quite so bad, but generally I think most common pages should target < 150ms.
  - lowglow 15y ago
    So what would you both consider "the next steps" in page speed optimizations?
    - troels 15y ago
      Make sure that http cacheability is good (send proper http headers, e-tag and expires; serve assets from cookie-less sub-domain). But if the page renders in 1.5 secs, I would try to address that also. That's highly specific to the application and its technical platform, so I couldn't really say how to approach that - But break out a profiler and go for the big chunks for a start.
    - dasil003 15y ago
      Impossible to say without looking at the profiled request. One thing I can say it's I would look at any page-level / HTTP caching until page generation is at least under 300ms for the most common requests.
eytan 15y ago
Your story closely resembles the challenges we had scaling sommelierwine.ca before a media event at our latest launch location. I knew that our site would receive an increase in traffic, and the increase would only be temporary. As a rails site hosted on Heroku, this gave us the ability to scale our site using the gambit of widgets that Heroku offers; but, we didn’t want to spend the money and cheat ourselves from the satisfaction of scaling our site. Using New Relic (a gem available on Heroku) I identified our first performance bottleneck - database queries. Certain queries were taking over 30 seconds to complete! These database queries all involved a table of BLOBs (on the order of 20MB) that needed to be searched and sorted. I tried adding indexes but that only marginally reduced the query time. The solution we found included moving the BLOBs to their own table while keeping an index to them in a table of their attributes [1]. Doing this, we were able to reduce query times down to less than a 100ms. The remaining bottlenecks we found using YSlow has helped us reduce the overhead in loading pages substantially. Even though we were able to weather the storm of visitors to our site, we did leave some tasks for the next one including implementing caching, background processing, and remote file storage. All in time. Does anyone have other wallet-friendly Rails/Heroku scaling stories share? [1] This is database 101 stuff - a class I never took.
- grk 15y ago
  For the new cedar stack, make sure you serve static assets from some sort of CDN, as each static file served ties up one of your dynos. With Rails 3.1, setting up cloudfront takes about 5 minutes and it's relatively cheap.
- jacques_chester 15y ago
  > [1] This is database 101 stuff - a class I never took. Yes, yes, a thousand times yes. The best and most important way to improve database performance is to have a sensible schema. Query planners can do magic with stuff that's sensibly normalised and with things that are sensibly denormalised. Where they choke is on schemata where everything is just squished into a bunch of tables with fields holding internal datastructures.
jibs 15y ago
Because i'm in a particularly pedantic mood: I don't think ELB (Amazon's load balancing) is free, which is a little misleading. In fact: * $0.025 per Elastic Load Balancer-hour (or partial hour) * $0.008 per GB of data processed by an Elastic Load Balancer Source: http://aws.amazon.com/ec2/pricing/ http://aws.amazon.com/ec2/pricing/ Obviously these are problems loads of people face / hope to face, so it would have been nice to get some more 'meat' in this post. Edit: formatting
- StavrosK 15y ago
  Neither is a second EC2 instance, or were they running that already? Was it just not running a web server?
MichaelApproved 15y ago
This seems like basic stuff. I'm more interested in the story about how you got this to the top of the front page. Edit: Less obnoxious.
- codypo 15y ago
  Blackmail. I have pics of pg and Steve Ballmer sharing an ice cream cone, and I'll make them public unless I get the proper upvotes. I actually don't know what happened here either. I was at a kid's birthday party, and I look on Twitter to see one of my cofounders had submitted this and that it was shooting up the front page.
  - MichaelApproved 15y ago
    My tone was meant to imply there was some funny business going on but more in jest than reality. Clearly people are finding this article helpful. Nice job.
- tjr 15y ago
  Basic stuff is valuable to people who need to learn the basics. Not everyone on HN is an experienced programmer, much less an experienced web programmer.
  - MichaelApproved 15y ago
    If you're a good enough programmer to know how to build the site, it's likely you know about profiling. Im surprised there are enough people who find themselves in this middle spot (can build complicated site but are still unaware of this info) to push the article up to the top page. Having said that, nothing I submitted ever made it close to the top of HN. Maybe my understanding of the community is off.
  - gerrys0 15y ago
    Thank you. As I was scanning the comments on this post, I was a bit surprised by the all the "This post was too basic. You are clearly an amateur and wasting my time" comments. Well, to those authors, not everyone on HN is an l337 hax0r such as yourselves. Yes, the author still has some work to do. Maybe if he spent another couple weeks just on this, he could get response times down. Maybe he should use a reverse proxy or maybe he shouldn't. As with most problems of this type, the answer is, it depends. To a young programmer with a few years experience who may be working on his/her first high traffice website, I thought the blog post was fantastically written. It was clear, concise, explained well the low-hanging fruit of optimization, explained the difference between performance and throughput, and decisions-making/tradeoffs made when preparing for a traffic spike. Well done.
RobPfeifer 15y ago
Cody, just one note on your website - I couldn't tell at all what Famigo offers without clicking on something. Instead of having "Famigo helps families find and manage mobile games and apps" in a hover-over pop-up, have a similar tagline somewhere people can see easily.
- codypo 15y ago
  Thanks for pointing this out. We JUST pushed a change this week where we removed a huge banner saying "We help families find and manage blahblahblah" and replaced it with a few other things. Maybe we need to revert that!
driverdan 15y ago
No CDN? Adding CloudFront is really simple and the costs are insignificant.
- pbreit 15y ago
  CloudFlare is easier. And free.
  - ceejayoz 15y ago
    Paying for CloudFront doesn't leave me wondering what their revenue model is and how it might affect how they serve my content.
ww520 15y ago
Nice writeup and valuable experience. Just curious why no extra money was spent? Spinning up more EC2 instances costs money, right?
bobzimuta 15y ago
The next step after ensuring you're doing the basics (cdn, minimizing data over the wire, etc) for us was to throw the entire site behind varnish. Set a "don't cache" cookie if users login, add a comment, etc. so that their changes are visible immediately. We took a slow site running on hardware, put it on EC2 (slower hardware obviously), and with varnish are saving about 60% cost of hosting, and decreased page load time on some of the popular pages by upwards of 50%, all for minimal engineering effort.
captain-asshat 15y ago
Cross posting my reply from another site: > We were now rendering our site index in 1.5 seconds or less, compared to 3 seconds before. This is the real WTF. What kind of queries take three seconds to run, that is ridiculous. Even with indexes 1.5 seconds is insane. Deciding against premature optimisation isn't permission to throw away good, efficient design. It's clear from the rest of the article that these guys really have no idea what they're doing. Quoting the results of all their optimisations: > In the end, we did not go down. The last round of load tests with httperf showed us handling 200 GETs a second indefinitely, with an average response time of about 1.2 seconds. We served thousands of requests without even a hiccup, and we did it without spending any money. This is really poor performance, and it shows in the site when you change page or select a different category/filter. I'm guessing that they also chose a nosql solution for the wrong reasons, as it seems everything there could be done much faster/better by using an ACID compliant database.
resnamen 15y ago
"Moving the Javascript to the bottom" - wouldn't the best thing to do would be to invoke the JS from onLoad? And put the code in a separate minified JS file, so it can be cached?
- bzbarsky 15y ago
  Yes, but moving the actual script tag that loads that minified JS file to the bottom of the HTML can help in some situations. Less so now that most UAs have decent speculative parsers, but it used to be that seeing the script tag would block any resources below it from being requested until the script was done loading. And being cached won't help for first-time visitors to the site, of course.

174 points by greenshirt 15y ago

Thanks to the author for taking time to write up his experience. That said, this is really basic stuff. How in the world could a home/index page have so many queries that it took 9 seconds? Oh, no indices... Then how could you have built a DB-backed web app and not considered indexing? A better title for the post might be "Scaling Mistakes I Made While Building Our Website and How I Fixed Them".

eric-hu 15y ago
I'm very very reluctant to call those mistakes. From the author: > I didn't get too upset here; I expected us to do poorly. After all, we'd spent all of our development time in actually building something people want, not on scaling up for thousands of imaginary users. Perhaps it would be relevant to the conversation if the author could chime in with how many projects or ideas they went through that failed. Perhaps they had to do consulting on the side for income. Premature optimization is a mistake. It's time wasted on delivering minimal value to you or anyone else.
- eropple 15y ago
  Indices on a database aren't "premature optimization". They're part of understanding your data model, how it will be requested, and--more in a SQL database than a MonogDB database, but still--constraints on the data stored in your database. Claiming basic development practices to be "premature optimization" is a fantastic way to paint yourself into a corner because of stupid decisions in your haste to "get it out the door." Your MVP isn't V if it still takes a second to render your homepage to users, because they'll leave. (Site responsiveness is a huge factor in bounce rate, even for sites that people actually want to look at.)
  - troels 15y ago
    Indexes can most certainly be premature optimisation. There's a cost associated with an index.
    - driverdan 15y ago
      The cost increases significantly by doing it later on. Indexing when you have little data is easy. Indexing on a live site with millions of rows and lots of users can be much harder.
      - aptwebapps 15y ago
        Taking it to that extreme is not a valid argument. There's a lot of room between not doing it first and only doing on a live site with millions of rows and lots of users.
    - sjwright 15y ago
      That might be true for some esoteric indexes, but if we're talking about indexing customer_id on the invoices table, it's not premature -- it's freaking inevitable.
      - eropple 15y ago
        Yes--and these are the overwhelmingly most common case for a query in most applications. From reading the blog post, it seems like the blog author was either doing pretty frighteningly complex stuff just to render his homepage or he didn't think ahead enough to add fairly standard queryable indices to his collections. Neither strikes me as terribly smart, and the latter strikes me as writing it right the first time, not "avoiding premature optimizations."
  - swombat 15y ago
    I consider Indices to be premature optimisation. Moreover, they're very low level, potentially dangerous premature optimisation. Imho, they should be the very last trick you use to optimise. First, you try and figure out if you can reduce the number of repeated queries. Then you try and figure out if you can get rid of chunks of code that spawn lots of queries altogether, by tweaking the algorithm to do things differently, without needing that data. Then, finally, once you've used every trick to make it all faster, then you apply indices to speed up that handful of remaining queries. If you apply indices first, then you won't spot the other potential optimisations, and when your indices stop covering up for your poor coding it will be much later, and much harder to fix.
- CoffeeDregs 15y ago
  >Premature optimization is a mistake. Wholly agreed and I often say the same thing. But I do not consider basic indexing on a database to be "premature optimization". I do consider it to be a a mistake since you almost certainly find performance issues (unless the table is small enough that indexing is a mistake), then you'll have to track down the cause of the issues (commonly called "a bug") and then will have to add indexes.
codypo 15y ago
Oops, I think I didn't express myself very clearly. When I was sending 20 requests a sec in a load test, the average response time for all the requests was 9 seconds. In a normal case, the page was loading in a fraction of that. Also, we didn't lack all indexes, just a couple of important ones. We've been iterating quickly on the site and we weren't analyzing the performance as our queries were refactored.
- phadrus 15y ago
  Please stop blogging and start reading about how to construct an application properly.
  - _vn5r 15y ago
    +1

bmelton 15y ago

With the rise of cloud services, and their relative inability to serve naked domains, there are a couple of easy fixes for this. The first is to create a vhost in your webserver that serves an index.htm page on your NON-www url. The contents of that page would simply redirect users to the www.yourdomain url. If that seems like too much work, an even easier fix (truncated for brevity) is to do something like this: var url = window.location.href; if(url.indexOf("http://www") != 0) { window.location.replace("http://www.yourdomain/"); } You'd obviously want to capture the remainder of the querystring and add it in, but that's the general idea.

dchest 15y ago
Why not plain old HTTP 301/302 redirect?
- StavrosK 15y ago
  Please, please use a redirect. The GP's suggestion is not something you want to do. Even better, just use http://wwwizer.com/ http://wwwizer.com/ (look for the free redirect service banner on top).
jibs 15y ago
ooh, this looks really problematic on multiple levels (why wait for JS etc). A simple solution, which I've used--and I think the OPs situation is similar--is to just have an additional A-record pointed to the ELB, this should work unless the OP is doing something really fancy. No need for route-53, even go-daddy will let you do this. However, route-53 gives you much better TTL, so if you ever need to re-route..
- ceejayoz 15y ago
  ELBs change IP if they have to scale up. You really shouldn't point an A record at one.
  - jibs 15y ago

troels 15y ago

It's fairly basic stuff this, but important none the less. Kudos for recommending Yslow (or PageSpeed) - it's indeed brilliant. You didn't mention much about http caching, which I think is probably as important as the other things you mentioned; Not only does it improve performance for the user, but it also reduces load on your server and it enables you to put up an edge side cache for extra performance. As for the problems mentioned with the load balancer - You could have simply provisioned a new instance and installed your own load balancer. There's dedicated packages like haproxy, but you could also just put up nginx or lighthttpd. This machine can later double as your edge cache (Squid). Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does.

dasil003 15y ago
> Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does. Agreed. This will have an extremely negative impact on your user engagement. Now if this is measuring end user response time rather than server-side page generation it might not be quite so bad, but generally I think most common pages should target < 150ms.
- lowglow 15y ago
  So what would you both consider "the next steps" in page speed optimizations?
  - troels 15y ago
    Make sure that http cacheability is good (send proper http headers, e-tag and expires; serve assets from cookie-less sub-domain). But if the page renders in 1.5 secs, I would try to address that also. That's highly specific to the application and its technical platform, so I couldn't really say how to approach that - But break out a profiler and go for the big chunks for a start.
  - dasil003 15y ago
    Impossible to say without looking at the profiled request. One thing I can say it's I would look at any page-level / HTTP caching until page generation is at least under 300ms for the most common requests.

eytan 15y ago

Your story closely resembles the challenges we had scaling sommelierwine.ca before a media event at our latest launch location. I knew that our site would receive an increase in traffic, and the increase would only be temporary. As a rails site hosted on Heroku, this gave us the ability to scale our site using the gambit of widgets that Heroku offers; but, we didn’t want to spend the money and cheat ourselves from the satisfaction of scaling our site. Using New Relic (a gem available on Heroku) I identified our first performance bottleneck - database queries. Certain queries were taking over 30 seconds to complete! These database queries all involved a table of BLOBs (on the order of 20MB) that needed to be searched and sorted. I tried adding indexes but that only marginally reduced the query time. The solution we found included moving the BLOBs to their own table while keeping an index to them in a table of their attributes [1]. Doing this, we were able to reduce query times down to less than a 100ms. The remaining bottlenecks we found using YSlow has helped us reduce the overhead in loading pages substantially. Even though we were able to weather the storm of visitors to our site, we did leave some tasks for the next one including implementing caching, background processing, and remote file storage. All in time. Does anyone have other wallet-friendly Rails/Heroku scaling stories share? [1] This is database 101 stuff - a class I never took.

grk 15y ago
For the new cedar stack, make sure you serve static assets from some sort of CDN, as each static file served ties up one of your dynos. With Rails 3.1, setting up cloudfront takes about 5 minutes and it's relatively cheap.
jacques_chester 15y ago
> [1] This is database 101 stuff - a class I never took. Yes, yes, a thousand times yes. The best and most important way to improve database performance is to have a sensible schema. Query planners can do magic with stuff that's sensibly normalised and with things that are sensibly denormalised. Where they choke is on schemata where everything is just squished into a bunch of tables with fields holding internal datastructures.

jibs 15y ago

Because i'm in a particularly pedantic mood: I don't think ELB (Amazon's load balancing) is free, which is a little misleading. In fact: * $0.025 per Elastic Load Balancer-hour (or partial hour) * $0.008 per GB of data processed by an Elastic Load Balancer Source: http://aws.amazon.com/ec2/pricing/ http://aws.amazon.com/ec2/pricing/ Obviously these are problems loads of people face / hope to face, so it would have been nice to get some more 'meat' in this post. Edit: formatting

StavrosK 15y ago
Neither is a second EC2 instance, or were they running that already? Was it just not running a web server?

MichaelApproved 15y ago

This seems like basic stuff. I'm more interested in the story about how you got this to the top of the front page. Edit: Less obnoxious.

codypo 15y ago
Blackmail. I have pics of pg and Steve Ballmer sharing an ice cream cone, and I'll make them public unless I get the proper upvotes. I actually don't know what happened here either. I was at a kid's birthday party, and I look on Twitter to see one of my cofounders had submitted this and that it was shooting up the front page.
- MichaelApproved 15y ago
  My tone was meant to imply there was some funny business going on but more in jest than reality. Clearly people are finding this article helpful. Nice job.
tjr 15y ago
Basic stuff is valuable to people who need to learn the basics. Not everyone on HN is an experienced programmer, much less an experienced web programmer.
- MichaelApproved 15y ago
  If you're a good enough programmer to know how to build the site, it's likely you know about profiling. Im surprised there are enough people who find themselves in this middle spot (can build complicated site but are still unaware of this info) to push the article up to the top page. Having said that, nothing I submitted ever made it close to the top of HN. Maybe my understanding of the community is off.
- gerrys0 15y ago
  Thank you. As I was scanning the comments on this post, I was a bit surprised by the all the "This post was too basic. You are clearly an amateur and wasting my time" comments. Well, to those authors, not everyone on HN is an l337 hax0r such as yourselves. Yes, the author still has some work to do. Maybe if he spent another couple weeks just on this, he could get response times down. Maybe he should use a reverse proxy or maybe he shouldn't. As with most problems of this type, the answer is, it depends. To a young programmer with a few years experience who may be working on his/her first high traffice website, I thought the blog post was fantastically written. It was clear, concise, explained well the low-hanging fruit of optimization, explained the difference between performance and throughput, and decisions-making/tradeoffs made when preparing for a traffic spike. Well done.

RobPfeifer 15y ago

Cody, just one note on your website - I couldn't tell at all what Famigo offers without clicking on something. Instead of having "Famigo helps families find and manage mobile games and apps" in a hover-over pop-up, have a similar tagline somewhere people can see easily.

codypo 15y ago
Thanks for pointing this out. We JUST pushed a change this week where we removed a huge banner saying "We help families find and manage blahblahblah" and replaced it with a few other things. Maybe we need to revert that!

driverdan 15y ago

No CDN? Adding CloudFront is really simple and the costs are insignificant.

pbreit 15y ago
CloudFlare is easier. And free.
- ceejayoz 15y ago
  Paying for CloudFront doesn't leave me wondering what their revenue model is and how it might affect how they serve my content.

ww520 15y ago

Nice writeup and valuable experience. Just curious why no extra money was spent? Spinning up more EC2 instances costs money, right?

bobzimuta 15y ago

The next step after ensuring you're doing the basics (cdn, minimizing data over the wire, etc) for us was to throw the entire site behind varnish. Set a "don't cache" cookie if users login, add a comment, etc. so that their changes are visible immediately. We took a slow site running on hardware, put it on EC2 (slower hardware obviously), and with varnish are saving about 60% cost of hosting, and decreased page load time on some of the popular pages by upwards of 50%, all for minimal engineering effort.

captain-asshat 15y ago

Cross posting my reply from another site: > We were now rendering our site index in 1.5 seconds or less, compared to 3 seconds before. This is the real WTF. What kind of queries take three seconds to run, that is ridiculous. Even with indexes 1.5 seconds is insane. Deciding against premature optimisation isn't permission to throw away good, efficient design. It's clear from the rest of the article that these guys really have no idea what they're doing. Quoting the results of all their optimisations: > In the end, we did not go down. The last round of load tests with httperf showed us handling 200 GETs a second indefinitely, with an average response time of about 1.2 seconds. We served thousands of requests without even a hiccup, and we did it without spending any money. This is really poor performance, and it shows in the site when you change page or select a different category/filter. I'm guessing that they also chose a nosql solution for the wrong reasons, as it seems everything there could be done much faster/better by using an ACID compliant database.

resnamen 15y ago

"Moving the Javascript to the bottom" - wouldn't the best thing to do would be to invoke the JS from onLoad? And put the code in a separate minified JS file, so it can be cached?

bzbarsky 15y ago
Yes, but moving the actual script tag that loads that minified JS file to the bottom of the HTML can help in some situations. Less so now that most UAs have decent speculative parsers, but it used to be that seeing the script tag would block any resources below it from being requested until the script was done loading. And being cached won't help for first-time visitors to the site, of course.