10 ms·
9 million hits/day with 120 megs RAM
- silverbax88 15y agoI agree that this should be the standard, not an exception.
- g-garron 15y agoI've been once on /., two times on Digg and all times my server crashed. I've improved it a lot since then, using different techniques. But never been hit by one of those again :( New self hosted blogs can't get the load of peak times, because new bloggers start a WordPress blog, install on it a lot of plugins and never think about performance. I think most of us have made that mistake some time.
- jellicle 15y agoSure. But it's not a mistake; it's a correct choice given current expectations. What I don't understand is why the various CMS's don't offer automatic on-the-fly reconfiguration. It's 2011. We should be able to have the best of both worlds: --when load is light, your blog software hits the database 42 times with every page loaded, no problem -- when site load shifts from 1 page per hour to ten pages per second, the CMS should automatically, with no user intervention, say "oh shit" (perhaps audibly in the server room) and then automatically generate a static front page, and static article pages for whatever pages are being linked to, turn off the bells, turn off the whistles, email and tweet at the server administrator, etc. The CMS should cheerfully weather a storm all by itself. And when the load dies down, the static page should revert to a dynamic, 42-queries-on-the-database page, again without any intervention from the server administrator. Does this exist anywhere, out of the box?
- silverbax88 15y agoI don't know, but I do know that my architectural approach is to get any web app I write to only hit the database ONCE per page view. Ten calls is a lot for me. I've seen some that hit the DB 100 times on each view and I was able to reduce all 100 down to a single call.
- kalleboo 15y agoLess queries isn't always better. Sometimes a couple small fast (easily optimized by the DB server) queries are faster than a join (which could block several tables at once instead of just one).
- silverbax88 15y agoThis is true; you have to decide when that is. Of course, multiple queries across tables can be placed into a view and queried at once.
- pestaa 15y agoI heard one specific Joomla site used 800 queries to render the front page. A dev needs natural talent to reach that point, I guess.
- arghnoname 15y agoI worked on a site once that loaded at an okay rate for the live site, but the staging server would take about 15 minutes (seriously) to load once every other hour or so. I thought this was strange, same code and all, so I looked into it. There was a loop on the page that instantiated objects with an id, the number of ids dependent on the results of a previous query. What did that object instantiation do under the hood? It performed a query to fetch state. I calculated that 5000 queries were being run, and it only cropped up every once and a while (and seemingly 'never' on the live site) because queries were automatically cached for a set amount of time. I was new on the project, and in what is probably poor form, went around the whole office, letting my horror be fully known. People just shrugged though. edit: I forgot to add, modifying it to only perform one query was trivial.
- mike-cardwell 15y agoI was slashdotted at the beginning of the year. Spent quite a bit of time at #1 for https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Pri... I managed to have it up and running again in about half an hour by converting some content which didn't need to be dynamically generated for every request, into static content. Once things calmed down, I spent some time optimising it further and making lots of content static, which didn't need to be dynamically generated for every request. I'm glad I did, because I hit the #2 spot on Slashdot for most of a day this very weekend because of this article: https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sop... My lowly Linode VPS didn't even break a sweat this time.
- senthilnayagam 15y agodiscovered blitz.io will keep me and my servers busy this weekend
- tudorizer 15y agoKinda expensive :(
- jbhelms 15y agoI use http://loadimpact.com/ http://loadimpact.com/ The free version can give you an idea of how your server will handle a small spike, and the other versions are per day so if you only need to test once or so a week as you finish a sprint then it wouldn't be a horrible cost.
- icebraining 15y agoIt's odd that they let you just test any website without proving its yours (by e.g. putting special file in the root or something). Can't unauthorized testing be considered a DoS attack?
- kowsik 15y agoI can only speak for http://blitz.io http://blitz.io. We generate an account-specific UUID which becomes a URL that you need to make available on your app (adding a route in ruby/node.js or uploading a txt file). Before each load test we check that your UUID is available on the app. Even if your UUID is leaked, this is not a problem, since it's unique to your account. Unless of course, your Google/Facebook account gets compromised. We currently, do not support password logins. It's either OAuth/FB Connect or SSO through our partners.
- senko 15y agoI had a weekend hack project like blitz/loadimpact, was thinking of charging by the test (ie you pay what you use, which makes more sense than charging per calendar time). Plan was to offer quick tests (ala loadimpact), whole-site test (you give it the url to start, and it'd hit the linked pages with some probability as well) and custom scenarios (a list of urls to hit in order, rinse, repeat), and API to trigger tests automatically (for integration in routine integration/regression testing). Got the backend working, never finished the frontend/UI. If anyone reading this is interested, let me know in reply - might put up a quick working demo page for it.
- j_col 15y agoVery impressive, it's amazing how the "LAMP" stack continues to evolve.
- jacques_chester 15y agoThe key points: 1. Use caching. 2. Use Nginx. 3. Use PHP-FPM.
- ashconnor 15y agoWhy use FPM over Fast-CGI? I know Rasmus uses FPM and I would like to know the benefits.
- jacques_chester 15y agoFPM stands for "FastCGI Process Manager". I hope that answers your question.
- easp 15y agoI think people are too quick to throw out Apache + mod_php. It remains the defacto deployment environment for most open source PHP apps, which means that it is the best understood and best supported. For example, if you deploy using Apache, you don't have to worry about converting .htaccess rules that wordpress and some caching plugins create into an Nginx equivalent. People bitch a lot about the memory consumption of apache, but it's often overstated. They add up the resident set for each individual apache process and come up with a huge number, missing the fact that a significant amount is actually shared between processes. Apache's memory consumption problems have more to do with how it handles clients. Each client ties up a worker process for the entire duration of a request, or beyond if keepalives are enabled (as they should be). That means that the memory overhead of the PHP interpreter is locked up doing nothing after the page is generated while it's being fed to the client. Even worse, that overhead is incurred while transmitting a static file. I use nginx as a reverse proxy to Apache. It lets me deploy PHP apps easily and efficiently. Apache returns the dynamic and static requests as quickly as it can and moves on to the next request. Nginx buffers the result from apache and efficiently manages returning the data to all the clients. I used to have Nginx serve the static files directly, which is more efficient, but added complexity to my config. I chose simplicity. A PHP opcode cache, like APC, is also a big win, because it cuts the overhead of parsing and loading the PHP source files. I'm not convinced of the value of other caching for most uses. CPU time usually isn't the scarce resource, RAM is. The DB and filesystem cache are already trying to keep needed data in RAM. Adding more caching layers generally means more copies of the same data in different forms, which means less of the underlying data fits in RAM.
- waffle_ss 15y agoWonder how much faster it would be if PHP was taken out of the mix (looks like he's just just serving static pages anyway).
- j_col 15y agoBut he is using the APC cache, which is part of PHP, so I'm not sure he could pull that off? PHP-FPM is the fastest way he could be using that interpreter anyhow, as it maintains a persistent bank of PHP instances in-memory, with nginx acting as a proxy to it via a Unix socket.
- icebraining 15y agoYou wouldn't need APC if you weren't running PHP...
- waffle_ss 15y agoYes, obviously I meant just serving static pages. You don't need to run every page through PHP in order to have comments, dude. (I didn't mean completely remove PHP, just not make everything run through it)
- AlexC04 15y agoWhat would you replace PHP with? Are you suggesting static files ?
- heyimfromreddit 15y agoVarnish in front of the web server would do.
- g-garron 15y agoYou are right, it would need less hardware for the same work. Two days ago I wrote this: http://garron.me/linux/perfect-blogging-platform.html http://garron.me/linux/perfect-blogging-platform.html But the way his comments work, they way he has implemented the infinite scroll it's great and I'm no expert, but I think that is not possible with static pages.
- dan_manges 15y agoSome interesting techniques in here (e.g. Faking Dynamic Features Using Inline Caching), but otherwise it seems easy to scale to this level when the majority of page content can be cached.
- dan_manges 15y agoIt's not apparent if the 9 million+ daily hits number is taking into account that peak hours will be higher than off hours. It would take 100 reqs/sec if the traffic is even throughout the day, but 375 reqs/sec if 15% of the day's traffic is in the peak hour.
- onemoreact 15y agoYea, I see several diffrent numbers being tossed about but: This caching (I’m using APC right now) got my page load times down to about 170 microseconds for most pages, and 400 microseconds 400 microseconds ~= 2,500hits/sec; 170 microseconds ~= 5,880hits/sec; Both of which seem reasonable for a simple PHP site using a single core CPU @ 1+Ghz.
- mfjordvald 15y agoCross posting this from a comment I made on reddit: This is something I've actually worked extensively on solving and it's not quite as easy as this article claims it to be. In fact, there are quite a few too many draw backs to this method to any site that isn't largely static or updated very rarely. * Whenever anything is updated the entire cache is invalidated and each item needs to be fetched again. This means you'll have some page loads being slow and others being fast. If you have a very dynamic website you will hardly ever even see a cached version. * You can't cache things forever, primarily because when anything is updated the entire version namespace is invalidated. This means that if you have a site that isn't updated at all in a long time then the cache is still invalidated by the TTL and has to be updated. Of course, if you decide to cache forever and the version namespace is incremented then... * You never know when your cache is full. Since the method of updating the cache isn't to invalidate keys but rather to just fill it with new keys, you will have a lot of stale data. This data will eventually have to get evicted from the cache. This means you don't reliably know when you need to upgrade your cache memory. All that said. Version namespacing your cache is better than not caching at all and it's usually also better than having a lot of stale data as active keys. If you want to do proper cache invalidation in case you have a highly dynamic site then it's still possible, but it requires a lot more work, there's a reason for this famous quote: http://martinfowler.com/bliki/TwoHardThings.html http://martinfowler.com/bliki/TwoHardThings.html
- luigionline 15y agohow about just using a CDN service. There is no need to play around anymore.
- antihero 15y agoThat's about 100requests/sec, which isn't particularly amazing.
- joshmlewis 15y agoI would flip shit to get that many views. I'm sure I'm not the only one.
- pestaa 15y agoOn average that means 1.2 Mb memory available/request, which isn't particularly boring either.
- michael_dorfman 15y agoI guess my age is catching up with me-- my gut reaction on seeing the headline was: 120MB? That's a lot of RAM-- who has that? Oh, wait...
- Luyt 15y agoIndeed! I read it as: 9 million hits/day with 120 gigs RAM Especially because of the scalability discussion around it. Only later in the article it dawned on me that he is using a cheap cloud instance.
- harrisreynolds 15y agoLOL... me too... I was thinking... who couldn't hit 9M hits a day with 120 gigs of RAM... just load everything in memory and walk away! 120 MB is certainly more impressive.
- api 15y agoThis underscores how ridiculously overspecced modern servers are due to the bloat of a lot of modern software.
- jacques_chester 15y agoVirtual machines change the economics of hosting for the host. A given VM has a lower administrative overhead per customer than shared hosting does. This will eventually drive out shared hosting, IMO -- except for single-application purposes.
- lsc 15y ago"for the host" is key, really. the customer has to do a lot more work on a VPS than on a shared host, so I think shared hosting isn't going away. Now, I agree with you that the shared hosting market will continue to move more towards constraining the user to a particular language within that shared hosting environment, as that allows the host to provide better service, but this has been true for a while. For the last 10+ years, if a shared-hosting provider allowed you to run an arbitrary binary, it only allowed you to do so as a second-class citizen, behind several layers of setuid wrappers and other (usually slow) security. Back in the day, if you wanted to run at reasonable speed on a shared host, you'd write in php, and use the supplied MySQL database, which conceptually isn't that different from what many of the language specific cloud providers do today. The interesting thing is that this means shared hosting, usually with a well-supported but language constrained environment, is actually becoming the premium hosting option. VPSs, formerly the high-end option, are now the cheap stuff. Which makes sense; as a provider, sure, the VPS costs me more ram, but I can get an 8GiB reg. ecc ddr3 ram module for under a hundred bucks now. Ram is cheap. what costs me money is the support, and it is a lot easier to rent out unsupported VPSs than it is to rent out unsupported shared hosting. If anything, with this new 'premium' image and advances in billing customs, I think we are seen a renascence in 'premium' shared hosting services.
- jacques_chester 15y agoI predicted the 'doom' of conventional shared hosting in 2008[1], but I didn't foresee the rise of PaaS offerings like Heroku. Interesting times. [1] http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed-and-i-have-the-graphs-to-prove-it/ http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed...
- noelwelsh 15y agoI'd like to know how much the Joyent Smartmachine contributed to this. They make some bold claims on their website, and really do seem like a great alternative to EC2 (disk IO that doesn't suck!) if they deliver. Anyone have any experience?
- winsbe01 15y agolove it. gives me faith that the archaic machines i have serving can still hold their own!
- krmmalik 15y agoQuick Question. Would using Nginx as a front-end to Node improve performance in the same way it has done for serving PHP?
- jjm 15y agoPutting any proxy cache in front of your app will help. You can 'simulate' static caching of dynamic content. You will have to take a look at your headers however as most caches obey upstream caching headers to spec tightly.
- jroes 15y agoBlogs really don't need a PHP, Rails, or anything backend. It's static content. Here's how I think blogging should work: 1. Visit a web app where you create your blog post, add pictures, use your rich text editor, that sort of thing. 2. Click the "Publish" button, which generates static HTML and runs any other processing like tag generation or pngcrush. 3. Your static HTML gets pushed out to some server that does the hosting for you. It could even be one of those really cheap shared hosting providers. If you really want comments, let someone like Disqus or Intense Debate handle it. Pretty much any dynamic feature you need can be outsourced.
- sehugg 15y agoVignette StoryServer (http://philip.greenspun.com/wtr/vignette-old http://philip.greenspun.com/wtr/vignette-old) .. if you see commas in a .html URL, thank them for it. And TCL as a scripting language, whoo-hoo :)
- jacques_chester 15y agoThat's pretty much how MovableType used to work. Fun fact: it was terrible. Most bloggers I know hated it. Wordpress is a bucket of poop too, but it has the quality that when you press 'publish', the site is updated in seconds, not minutes. (I believe MT has changed since then).
- flyosity 15y agoI've been using MT since 2003 and never thought it was terrible. Publishing times (full-site publishing) was always slow but publishing an entry only took a few seconds. The new Melody project forked MT and updated the UI, it looks great now.
- byoung2 15y agoI used MovableType when rebuilding steves-digicams.com (not by choice), and it really slowed to a crawl when we did a full publish (30,000+ articles). Luckily we only had to do that a few times when setting up the site. I don't see the advantage of static files being worth the hassle of publishing when you can achieve the same or better results using a caching proxy like Varnish. We used Varnish in front of Apache on ultimatecoupons.com (all dynamic, built in the Symfony PHP framework), and once cached, pages load in 15ms (first byte in browser).
- wingo 15y agoVery nicely done. Using JS to give personalized experiences seems to be the way to go. I suppose you could generate a JSON list of id,date pairs to reduce page bloat, if it matters. [Edit: This is 100 qps. It's a lot for a blog, but is not an unreasonable load by any means.]
- RyanKearney 15y agoI'm not too sure I'd go with a load testing company that can't even keep their own website up. http://blitz.io/ http://blitz.io/ > Internal Server Error
- deleted 15y ago[deleted]
- mkr-hn 15y agoIt's always exactly the time when you need your service to be up the most that it goes down. What matters is how they respond to it.
- gtklocker 15y agoHe could just say "tl;dr\n<machine specs>\n<I use static pages>".
- ez77 15y agoNaive question: suppose that you serve a low-throughput site, say with a total of 3MB of data (probably text files). What's the simplest way to ensure that those 3MB of content (very little compared to 120MB) live always in RAM? By this I mean not giving the server a choice =).
- sbierwagen 15y agohttps://secure.wikimedia.org/wikipedia/en/wiki/RAM_disk https://secure.wikimedia.org/wikipedia/en/wiki/RAM_disk
- amalcon 15y agoPoint the server at a ramdisk, and set up a cron job to sync it from the regular disk?
- deleted 15y ago[deleted]
- kahawe 15y agoI have to say I haven't tried that myself nor have I looked at the prices so my question is: All the fun of having your own server aside, why wouldn't I rather just run a site like that on something like amazon ec2 and stop worrying about hits and load even if it is just a personal blog?
- schiptsov 15y agoThere was some post about a happy Win/IIS/CF guy - he definitely should read this.. ^_^
- g-garron 15y agoAs a lot of you have said: Static content is the key to success. You can name it: - Movable type - Drupal + boost - Wordpress + SuperCache - Jekyll or other static website generators Better if Nginx is serving those static files, LAMP can be behind creating the static files. I used that way with Drupal+boost for a lot of time and worked.
- njharman 15y agohits/day and megs ram are orthogonal.
- TylerE 15y agoOne thing to point out, based on my experience, is that you need about 10x or more peak throughput to handle a given average throughput. Spikes kill you.
- michael_h 15y agoBy inlining the comments, he's reducing cpu time by...transferring extra data across the network?
- todsul 15y agoThe difference between Apache and Nginx is that out of the box, Nginx is built for speed. Both are capable of thousands of requests per second, but Nginx arguably does it better with its event-based architecture (opposed to Apache being process based). The config syntax is also refreshingly simple, so converting .htaccess rules couldn't be easier. We were recently paying a small fortune for hosting one of our websites. It was bumping up against memory limits even after a serious code rework and aggressive caching. Instead of upgrading we decided to test a new config using Nginx. Now we run three sites, one fairly popular, on a 512Mb Linode with Nginx, APC, FPM, Varnish and a CDN, and it can take an amazing amount of load. Varnish needs memory, but without Varnish we could run this setup on a box a fraction of the size. This plan costs $19/month! I still can't believe we're paying so little. Instead of focussing just on the server though, and like the TumbleDry article somewhat suggests, HTTP cache is probably the best place to start in terms of performance. Varnish, CDNs, etc all rely on intelligent HTTP caching. And if you do it right, you don't need to worry (too often) about cache invalidation. What I'm really looking forward to is making use of ESI in Symfony2 and Varnish. That will mean setting different cache headers for portions of pages, which will further reduce the need to manually invalidate cache. For now though, I'm loving Nginx + FPM + APC.
- ez77 15y agoFor static, high-traffic, small-size content, doesn't it make sense to load a minimal OS entirely to RAM and serve it from there? Has anybody tried this? (I guess this rules out VPSes...) Note: This is a variation of a previous comment I made, but a variation nonetheless. Sorry to belabor the point.
- drv 15y agoThe title says "120 megs of RAM", but I wonder if that's at all comparable to a real machine with 120 MB. I imagine that the "120 MB" VM is running on a beefy host with tens (or hundreds) of gigabytes of RAM shared between the guest VMs and also used for disk cache. It seems likely that accessing a guest's virtual disk would actually hit the host's disk cache a lot of the time (especially when that guest has been busy recently); that would improve the speed of disk access for that VM enough that it could make up for the lack of memory for disk cache within the guest. This is purely speculation, but I would be interested to see if there is any actual research to back it up. I suppose if the guest in this instance is not swapping very often, then this is fairly irrelevant, but the article didn't mention anything about swap.