I need to plan requirements for multiple instances of CiviCRM as a Drupal module.
My goal is to "more or less" know how many sites would I be able to put in a single application server (with dedicated database server) with 4 cores CPU and 16 GB memory.
It's tempting to discard this question as being too vague to give an accurate answer to, but capacity planning is a real and difficult challenge.
Is CiviCRM resource intensive? That depends what you compare it with - compared to a static site, yes.
A CiviCRM site with a few users occasionally looking up a contact needs far fewer resources than one with hundreds of users using it all day long for complex reports.
Are your multiple sites likely to have similar workloads? Will the sites be used concurrently? What virtualisation/containerisation are you using? What memory requirements are there besides Civi? What other resources might be contended - like network bandwidth or storage?
You could look at the specs offered by the various CiviCRM hosting providers and see what configurations they have arrived at based on their experience of hosting a large number of mixed sites. If you search this site you will find a few recommendations of 2GB for a VPS.
There are some critical limits, eg if the php memory limit is too low then processes abort, but mostly things "go slow" rather than fail if you try to put "too much" on a server so determining how many sites you can put on your box involves understanding acceptable performance.
In practice, you probably just need to try it and see. Monitor your resource utilisation and perceived performance and see what effect adding another site has.
Alternatively, use a hosting provider and pay them to figure it out :-)
@Aidan is right - there is no one number for how many sites - not even a 'more or less' number :-)
Some of our projects are on one dedicated server that hosts a couple dozen of them; they are all Drupal (and most with CiviCRM).
Another project though -> it has its own two dedicated servers: one for web and one for the database/mysql!
Are you specs 16 GB RAM and 4 CPU cores for a VPS or the specs of a co-located bare metal server?
Expect about 20 to 30% performance degradation if you go with a VPS, and if you have a choice in VPS virtualization technology, opt for KVM (e.g. Linode) over XEN (AWS), you'll get faster disk I/O for usually less cost and the same stability.
Are you planning on creating a VMs (e.g. KVMs) for each of the sites or putting all sites on the same bare metal server?
See the first question, if you're already using a VPS, it's not recommended to run a Virtualization stack inside an already virtualized VPS, but if you're getting a bare metal server, I would highly recommend using a virtualization layer to ease the management, e.g. you might want to reboot only one site, but keep all others online, that's impossible to do if you put them all without virtualization on the same bare metal server. Similar issues hold true if you needed some special PHP version or hold back one site that falls behind e.g. still uses Drupal 6 while the rest of them are already on Drupal 7 as the CMS.
What do mean by dedicated database server, are you using an external service like Amazon RDS as a dedicated database backend, or do you plan to host the database on an entirely separate server while the webserver is the machine for which you've provided the specs, or do you plan to virtualize the database server as dedicated VM inside the bare metal host?
A good rule of thumb is for a fairly average CiviCRM database of about 40k records with 5 staff members needing backend access, a 2GB RAM allocation is quite sufficient per site which can include both the webserver and database server inside the same VM if the disk has fast I/O (e.g. SSD drive.) When virtualizing the database server as a separate dedicated database VM, think about allocating at least 1 GB per about 50k records for each instance of CiviCRM, and about 1.5 GB as the base minimum for each web front-end VM.
