Hello,
Me again. I tried setting up a fairly complex site a few months back and it was a bit of a disaster speed-wise. Some of the problems being that I was probably on crap hosting (started off with shared then VPS). I eventually gave up and moved my experiment to Wordpress and a new host, where I still had loading issues, so was forced to learn more about server configs. I moved to Nginx, and tried caching and the likes and it turned out excellently.
So now I want to give Drupal another shot, because it's still the best option for what I want to do. But I want to get it right from the get-go this time.
I want to create a site that will be able to eventually manage literally thousands of records (with images) and probably the same amount of users. So far, from test runs on my local server, it seems that I'm going to end up using about 70 modules. It'll run on Nginx and be hosted on Digital Ocean as well.
I'm not sure however, what the server specs should be. I mean I don't expect to hit a high number of nodes or users for a while, but I don't want to be caught flailing.
- Is it good to start with 2GB RaM (and 2 CPUS)? Should I start higher?
- What configs for NGINX, MySQL would you recommend? I've seen quite a few and I'm not sure which way to turn.
Would appreciate your thoughts, thanks.
edited the module number, seemed a bit high
Comments
100+ modules seems excessive.
Probably your best bet is to bring that right down by looking to see what you can do with a few well selected modules rather than a bunch of task specific ones.
How familiar are you with using fields, Views, Rules etc? Cutting down modules you don't truly need is probably your first (and most significant) point of improvement.
With some more info on what exactly the site does I may be able to add further suggestions.
Well, now that I'm thinking
Well, now that I'm thinking about it, it's probably not that much, I don't remember installing that much. I was just trying to think of a worst case scenario. I was going off the number on my modules page which is wrong (turns out I've only manually installed 34 + the default core modules of which I'm not using all of them).
I'm pretty familiar with Views and to a lesser extent, Rules. I'm setting up something of a public database of connected items. Think of basically, something like IMDB's structure. 1 item composed of several people with their own pages, and with Views, you can view items that have listed the people on their page. That's the basic structure. There are other things like discussions and user profiles, but the bulk of the work is on those item pages. I already have this at a basic level with just Views, Entity Reference and Field Collections.
So yeah, you're right I probably won't end up needing 100 modules. But still, worst case scenario.
Okay,
So the next step will be to make sure after you set everything up that caching is turned on wherever possible.
There's a lot of info on how to optimise caching for authenticated users and anon. users (easier). Having as much as possible cached means your server doesn't need to 'think' whenever it delivers a page.
You could also look at using a CDN to deliver the images, JS and CSS (I use rackspace cloudfiles) and there's a module to integrate that into your site easily enough.
2Gb ram should be plenty by the sounds of things. It doesn't sound to me like you're doing a lot of heavy processing so I'd expect bottlenecks to be inefficient views and not having anything cached.
If you want to get serious about caching, look into something like Varnish or Boost depending on your context.
Just to add...
You could use a cloud based server (again, I'd suggest rackspace) in which case you can easily scale your 'server' vertically giving it more ram, CPU etc as needed until you find your sweet spot.
Thanks for the feedback. I've
Thanks for the feedback.
I've worked with Cloudflare before, and I'm definitely thinking of revisiting that for this site. It did wonders for my other heavy WP install.
I also tried Boost in my first Drupal experiment, though it was STILL kind of slow. I've seen it in a few places that you don't really need Varnish when using nginx? This is all new territory for me, but it seems like everyone has an opinion and I may have to just engage in some trial and error yet again.
But let me get a server running. If 2gb seems fine then I can nail that down and look at possible nginx configs to work with.
You'll probably end up using
You'll probably end up using 100-200 modules for a complex site. From what you describe you'll probably want to ensure that things are well cached. Both from an entire page level, down to individual blocks/views/panes/entities. And the tricky part with caching is figuring out when to do cache invalidation. Varnish (or Boost depending on your skill level / server access) + block caching + entity cache will probably be enough for a good start.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
A few points
Keep the stack as simple as possible. You don't need Varnish to cache
anything. Nginx has a cache also. The downside is that it requires you
to know how to configure it.
If your caching-fu is not that high, try microcaching, since it will save
you having to deal with cache invalidation.
For a site with moderate traffic use the TCP socket option for php-fpm.
Choosing which governor to use: dynamic or static depends on the traffic
pattern. Constant high traffic -> static; irregular high traffic -> dynamic.
If you have long running processes (which every mildly complex drupal site
has) you'll need to tweak the listening queue length at OS level.
If you want to cache static files with Nginx, you'll need to front the Nginx
vhost that proxies to FCGI with a reverse proxy. This is more complex, but
it will offer you the possibility of load balancing and/or a simple
failover depending how you architect it.
Use opcode caching af course.
Tweak the queries as much as possible to speed it up.
As for the Nginx config to use. Go to the Nginx group and inquire there.
I have an answer for that, but is biased ;)
I was confused by no 9 till I
I was confused by no 9 till I saw your username. I just came across your configs last night. I'm a front-end person that's been learning all this stuff myself (6 months ago I didn't even KNOW how to use a cloud server, not to talk of what nginx was, and now I actually understand most of the things you mentioned here and on git, so progress!) and it's pretty intimidating haha. But I'm determined to learn.
For instance this is the first time I'm hearing the word governor used in this context. I have no idea what that is.
The other stuff though, I'm more familiar with, and seeing your stuff on Github, I'm curious, would you recommend those settings for just about any Drupal site, or just the complex ones?
Also, I don't think I'm ready for physical stuff at all. It would probably be best to leave that to an actual professional :)
the governor is the strategy used by fpm to manage the
workers it supervises.
I recommend to anyone using Drupal. Here's a few reasons:
It's the fastest one out there AFAIK. No rewrites, no superfluous internal redirects.
It's reasonably secure: controlled PHP execution. Kicking Apache's bad habits away.
Microcaching built in. No need for Varnish. Use a simpler, faster, more scalable
alternative (no threading).
HTTP method blocking.
etc. See the features elaborated on the README.
For a site with moderate
As opposed to a local Unix socket? Why is that?
I was under the impression that Unix sockets would always be faster since they don't have to hit the network stack and/or hardware.
The Boise Drupal Guy!
yeah it goes against logic
after all is a local thing, so the network layer is absent. But my experience so far
has been that the TCP sockets are more reliable under heavy traffic. I think it's mostly
an historical accident. The development of the UDS sockets backend has never been
a priority. After all is the TCP sockets thing that allows for cool things like farming the PHP processing to some dedicated machine(s), for example.
Ah yes
for having ultimate control over the system, choose a physical machine.
Nothing beats bare metal in raw performance and control levels.
WP caching
@Ony,
Wordpress:
Been working w/ WP for months now, and WP caching is 'OK.'
Drupal appears to have a much finer control over caching at all levels, especially for a
.
Drupal, with the right types of caching for the system, works well for many sites.
Drupal caching list of how-to(s): https://drupal.org/node/326504
Site Complexity:
In terms of a "fairly complex site," the WP plug-in Advanced Custom Fields, http://wordpress.org/plugins/advanced-custom-fields/, has all kinds of fields a site-builder may need.
However, Drupal has much tighter integration of fields as Drupal fields are literately baked into core.
If someone is doing a 'complex' web site, prob. go with Drupal over WP, or if you are doing something insanely complex, may want to look at a system like Django.
Cheers,
Drupal StackExchange
Yeah, no, there's no
Yeah, no, there's no question, Drupal works better, which is why I'm going back to it. I've already gotten the site to do what I want at a basic level, something that would require much more work on WP.
What I'm looking at now is the best server setup for the drupal site. Thanks for the link, I'll take a look.