Hi guys
I'm trying to size up a server for an install of open atrium, where I'm expecting to be serving an intranet of 3000 total users across the globe, with around 150 concurrent users at a time, and I'd like to see compare what I think I'd need, with what you would suggest for running a site like this.
Given we have an existing site (which doesn't run on drupal, but a mish mash of existing php apps glued together), with around 600 users, and about 20-30 concurrent users on average, I'm making a rough guestimate, that if we assume the larger base of users will be as engaged, we'd end needing an app server that host around 120-150 users at any given moment.
I'm making an pessimistic assumption of needing around 50mb for each authenticated user for Open Atrium (it uses quite a few modules, so I'm looking to this post on 2bits, about drupal memory consumption), if I have 150 users to account for, my rough assumptions would be something along the lines of needing 7.5 Gb of memory on the app server avoid constant swapping.
The site wiil be based on Open Atrium (which uses D6, without pressflow), and use APC Cache module for PHP, and Memcache on the back, with a separate MySQL server handling the queries.
Given that nearly all users will be authenticated, I wasn't thinking of spending too much time looking into Varnish (Cache Control from Exove looks interesting, but I haven't had time to investigate it properly yet, so I'm discounting it for these calculations for now)
Given these kinds of usage stats, how would you go about sizing up a MySQL server for this? Are there any rules of thumb you'd apply like you would when sizing up an app server you would recommend bearing in mind here (i.e. allocated x mb of ram per user, or x users per core on a server?
Thanks,
Comments
I agree with your assessments
I agree with your assessments for Varnish. And 8GB sounds like a good place to start on the web head. I've not done an Open Atrium install of this size, but I have done other sites with comparable authenticated traffic. One important thing to know is that bare metal will perform an order of magnitude better than a VPS with "equivalent" specs. The reason being that VPSes usually have virtualized storage, or otherwise networked storage. This is a big problem for a MySQL server that will be doing a lot of work.
4 cores, 8GB should probably be able to handle the load. However what is more important than choosing CPU/RAM count, is tuning the MySQL configuration (the default will perform terribly), and seeking out slow queries and fixing them.
For this size site you might also want to be considering redundancy: having a load balancer (better yet redundant load balancers) in front of two or more web-heads, backed by a MySQL master with hot-swap slave. Though admittedly that's a lot more work to setup unless you have server deployment systems already in place.
As for Pressflow there's nothing stopping you from swapping out Drupal Core for Pressflow, even with an Open Atrium install.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Since you are in the planning
Since you are in the planning stage, having a look at MongoDB might be worthwhile. There are some DrupalCon presentations and a number of blog posts out there. I was impressed with the numbers Moshe brought in http://cyrve.com/mongodb/ even though it was for D7 and OA is probably going to remain D6 for a while. In any case, MongoDB is worth a look.
I agree completely with Dalin on using bare metal for the MySQL servers. Similarly, and you probably already have it on your radar, http://www.mysqlperformanceblog.com/ is a great resource.
You might want to have a look at using Nginx for SSL termination/Load balancing.
I'd still install Varnish
I'd still install Varnish unless you are using a CDN, because it will cache all assets like generated JS files and images and take the load off Apache, which will help.
If you are planning from the start, you could also plan to at least deliver some pages and blocks with ESI includes for Varnish to have a greater effect.
Also looking at Percona to use as a drop in replacement for MySQL could be worthwhile.
Best Wishes,
Fabian
When i was deciding which
When i was deciding which mysql to install system-wide for my business, I ended up going with the percona server due to their support offerings. That said, there are just as many valid reasons to run ourdelta/mariadb. Take the time to experiment and find out what works best for you.
Useful pointers, thanks
hi guys,
Thanks for all the pointers!
@fabianx - I'd be interested in hearing more about using varnish ESI's for authenticated traffic - other than varnish itself and the cache control, are there any other places you'd recommend looking to read up on this?
@dalin - You mentioned using more than one web head, for high availability (and as a possible side effect, performance). I'd normally go about this by mounting a volume as NFS across the two boxes, but I've heard interesting things about using rsync or unison as well. Have you head any experience with them, and would you recommend a couple of smaller boxes instead of one single large box like this?
Well you don't want to share
Well you don't want to share your codebase with NFS - it would be a performance issue to have all those files scanned for every HTTP request. You generally want to use a local filesystem for the codebase and use rsync (or Drush) to deploy code. You do however need to share the files directory somehow, most commonly via NFS.
Yes we normally do 2core, 4Gig boxes for webheads.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Hi @dalin On the NFS front I
Hi @dalin
On the NFS front I was referring to rsync as an alternative to NFS for syncing the file directories across a number of machines - we generally tend to use capistrano for deploying drupal apps where I work.
[Unison] also provides syncing across multiple machines, in a fashion similar to having rsync running between the two boxes here.
The downside is that it's designed to work for pairs of machines, rather than larger clusters - still might be handy tool nonetheless.
I've heard people talk about
I've heard people talk about trying rsync for the files directory but I don't see how it could work. When Drupal creates an aggregated CSS/JS file it needs to be available to all webheads instantaneously.
For our high-traffic sites we are usually using a CDN + Varnish and that removes almost all HTTP requests to the files directory. Throw in Imageinfo Cache module and then Drupal is no longer directly accessing files much anymore either so there is almost no load on NFS.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
More Info
http://drupal.org/project/imageinfo_cache
As for the CSS/JS aggregates & rsync delays, the Advanced CSS/JS Aggregation module might be the answer for that, once you have "Asynchronous Mode" working (check status page).
The last piece of the puzzle is file uploads and making sure they are available. The load balancer would have to take into account the session cookie. Also means something like imageinfo_cache's pre-generation could fail if the worker doesn't have the image; that would only happen if you set the IP, it sends all requests to the same server (it wouldn't work for us, we have a box just for cron and image generation so we point imageinfo_cache to that IP). Getting around this issue could be dealt with in this thread http://drupal.org/node/1138098. Another way around it would be the files proxy module, but that would be pretty a pretty inefficient way of doing it.
In short I think with the right setup a rsync files dir on Drupal might just work now.