Comment by peterwwillis | Hacker News Reader

Comment by peterwwillis | Hacker News Reader

How does this shit make it to the front page?

First and foremost, everyone needs caching. It's what makes computers fast. That RAM you have? Cache. The memory in your CPU? Cache. The memory in your hard drive? Cache.

Your filesystem has a cache. Your browser has a cache. Your DNS resolver has a cache. Your web server's reverse proxy [should] have a cache. Your database [should] have a cache. Every place that you can conceivably shove in another cache, it can't hurt. Say it with me now: Cache Rules Everything Around Me.

First you should learn how web servers work, why we use them, and how to configure them. The reason your Apache instance was running slow is probably because you never tuned it. Granted, five years ago its asynchronous capabilities were probably haggard and rustic. It's gotten a lot more robust in recent years, but that's beside the article's point. Nginx is an apple, CloudFront is an orange.

Next you should learn what CDNs are for. Mainly it's to handle lots of traffic reliably and provide a global presence for your resources, as well as shielding your infrastructure from potential problems. Lower network latency is just a happy side effect.

> How does this shit make it to the front page?

Obviously the title was a little ridiculous, but I up-voted it, because it's a novel idea. If you're planning to have almost all of your static assets hosted from the CDN (which is pretty reasonable for almost everyone) then why bother with a super high-throughput low-latency web server if the only purpose is to occasionally refill the CDN? If you end up thrashing the CDN and constantly going back to refill it, you're going to have bigger problems.

From what I can tell, the rest of your comment is just super aggressive and doesn't really go anywhere. I will tell you that I have extensive experience with every piece you've mentioned here, and none of that really has any effect on the author's thesis (again, no need to optimize serving static content from your host if a CDN is going to do the legwork).

In general though, when someone works at Mozilla, I tend to give them the benefit of the doubt regarding their knowledge of elementary computing principles.

I think it still worth it. You can't have 100% availability. Even AWS sometimes fails. It's then just a matter of changing DNS record and have your server(s) handle the load in some kind of degraded mode.

Peripheral but somewhat relevant, at work, we don't upload photos immediately to S3. We have to pre-process them but as soon as they are ready, we show them to the customer serving then locally. And only then upload them to S3.

I treat a CDN as a cache, great to have but I wouldn't exclusively rely on it. For whatever reason, you might need to degrade or show results asap, you can't do that if the CDN is the primary source.

The problem is this isn't a novel idea. Replacing a fast webserver with somebody else's fast webserver is half of the reason most people choose CDN's (the other reason usually being bandwidth). Just using someone else's fast webserver does not obsolete a different fast webserver.

It's totally acceptable that you might not have the infrastructure to serve all of your static content from your measely web servers and 100mbit connection. CDNs are a great choice here. But this has nothing to do with what web server you use, nor does it mean you should process every request dynamically just because right now you have the resources for it using a CDN.

Even with a CDN and an extremely efficient static content layer, you still have to hand out dynamic content to your users individually which a CDN generally will not help with. At a high enough number of requests you will run out of resources (RAM, CPU, Disk, Network, etc). At this point it's handy to have the fastest things you can so scaling doesn't become one huge clusterfuck. Then whoever re-implements Nginx to help handle requests will write a blog post about how Nginx makes CDNs obsolete.

My point before (and now) is: Caching matters, and having a fast frontend web server matters, and CDNs matter, and none of this is directly related: we're talking apples and oranges.

As an aside, CloudFlare seems to use a novel little fast web server:

  psypete@pinhead ~/ :) wget -S -O /dev/null http://4chan.org/ 2>&1 | grep -e "^[[:space:]]\+Server:"
    Server: cloudflare-nginx
    Server: cloudflare-nginx

But if the CDN is serving your static assets, your origin webserver only has to generate them once[1] to populate the CDN. It almost doesn't matter how long this takes. And this works well enough that you don't need to bother setting up an Nginx or Apache instance at all. And furthermore, you don't have to copy your static files anywhere -- just use your framework's built-in webserver for everything!

This greatly simplifies your production deployments and in my books that's a huge win.

[1] well... that fudges it a bit, since each POP needs to make its own fetch, and the assets can theoretically drop out of the CDN's cache; so the truth is actually "a handful of times" instead of "once".

I wonder if anyone actually use the framework's built-in webserver for everything! Sounds Great and i wonder what happens in practice. Anyone know of any real world usage on this?

Sounds great except all the framework with built-in webserver advice _against_ using them on production server, at very least for security reason.

How you use a CDN is site-specific. Some people still need to serve hundreds of thousands of requests via a caching frontend layer separate from their CDN origin. It's silly to assume you will never need a fast web server, because unless you aren't serving dynamic content, you will be serving content yourself and the rate will be consistent with the number of users, among other things.

Using a CDN does not actually simplify production deployment, it complicates it. It's an extra layer of complexity, and one you don't know very much about since it isn't your gear. You need an API hook (or a web interface) to invalidate old content when you publish new content. You need a contact with whom you can figure out why a tenth of your users can't route to the CDN all of a sudden, but can route to you. You need to get all your headers right so you don't accidentally push an invalidate to all content and kill your slow-ass origin with new traffic.

Finally, as someone else mentioned, using a framework webserver for production is A Bad Idea(TM). Only one of the reasons why is poor performance. Several others are security, compatibility, cache control, access control, privilege separation, stability, high-availability, virtual hosting, and about a billion other features that webservers have been designed to handle for decades that you will need to reinvent the wheel for with your application framework, which was never intended to be a webserver.

The reason your framework has a webserver is it's the simplest way to get the dynamic content from the app server to the frontend proxy. For example, AJP is such a huge pain in the ass that most Tomcat admins I know use http to communicate between app server and frontend (and it's more compatible). But would they use Tomcat as their production server? Not if they wanted to stay sane.

Reply on news.ycombinator.com