In a nutshell: for a Web server or an Application server in a three-tier farm, you will need to have at least 12 GB of RAM, and 64-bit, 4 cores!
This is according to the official Microsoft’s documentation: http://technet.microsoft.com/en-us/library/cc262485(v=office.15).aspx
Just some notes on this topic:The 12 GB ensures that the system has enough memory for running all the services. But you should also consider the following recommendations:
- Make sure that you activate the minimal features and components on your server.- Make sure that you turn off all the services that you're not using or even, minimize the logging.- If you have additionally the SQL server co-located, make sure that you install only the required components on SQL Server.
It is better to implement everything with the minimal amount of RAM and then, optimize each layer.
Some notes also on the RAM and the Distributed Cache specifically:
When the Distributed Cache service runs in collocated mode, the physical memory of the server should be increased and all non-essential services stopped. We do not recommend that any of the following services or applications run on the same server as the Distributed Cache service:
Additionally: When SharePoint 2013 is initially set up and the Distributed Cache service is configured to run, it is set to use 10% of the server’s total (physical) memory. That means 1.2GB of memory for the 12GB. You can always change that ccording to the following guidelines:
When SharePoint Server 2013 is installed, it assigns the Distributed Cache service 10 percent of the total physical memory on the server. The Distributed Cache service uses half of that memory allocation for data storage (also known as cache size), and the other half ofthat memory allocation is used for memory management overhead. When the cached data grows, the Distributed Cache service uses the entire 10 percent of the allocated memory.
You should increase the memory allocation of the Distributed Cache service in these scenarios:
From the following article you get very useful information and what to avoid during the design operations (especially related to Search):
Redesign enterprise search topology for specific performance requirements in SharePoint 2013 http://technet.microsoft.com/en-us/library/dn727118(v=office.15).aspx
Don’t mix competing search components
Avoid mixing search components on a physical server or machine if the components will compete for the same resources. Here’s a table that illustrates the relative amount of resourcesthat each component needs...
For example, it might not be a good idea to put a crawl and analytics processing component on the same server because they both use a lot of network bandwidth. But, if the physical server or virtual machine has enough network capacity, the components won’t compete.
Which hardware requirements should I be aware of?
The next step is to plan the hardware you’ll need:
o Choose type of storage
o Search component IOPS requirements
o Search database IOPS requirements
Each search component and search database requires a minimum amount of hardware resources from the host server to perform well. But, the more hardware resources you have, the better the performance of your search architecture will be. So it’s a good idea to have more than theminimum amount of hardware resources. The resources each search component requires depends on the workload, mostly determined by the crawl rate, thequery rate, and the number of indexed items.
For example, when hosting virtual machines on Windows Server 2008 R2 Service Pack 1 (SP1), you can’t use more than four CPU cores per virtual machine. With Windows Server 2012 or newer, you use eight or more CPU cores per virtual machine. Then you can scale out with more CPU cores for eachvirtual machine instead of scaling up with more virtual machines. Set up servers or virtual machines that host the same search components, with the same hardware resources. Let’s use the index component as an example. When you host index partitions on virtual machines, the virtual machine with the weakest performance determines the performance of the overall search architecture.
The minimum storage that the analytics reporting database requires can vary. This is because the amount of storage depends on how users interact with SharePoint 2013. When users interact frequently, there usually are more events to store. Check the amount of storage your current search architecture uses for the analytics database, and assign atleast this amount for your redesigned topology.
So, in general, the planning and design operation is a matter of calculations BUT also, you need to check all the aspects of the design - in the manner that is mentioned for example, in the previous article above… and the following ones:
Planning worksheets for SharePoint 2013 http://technet.microsoft.com/en-us/library/cc262451(v=office.15).aspx
System requirements for SharePoint 2013 http://technet.microsoft.com/en-us/library/cc262749(v=office.15).aspx
Plan for SharePoint 2013 http://technet.microsoft.com/en-us/library/cc261834(v=office.15).aspx
Plan for performance and capacity management in SharePoint Server 2013 http://technet.microsoft.com/en-us/library/cc262971(v=office.15).aspx
Capacity management and sizing for SharePoint Server 2013 http://technet.microsoft.com/en-us/library/cc261700(v=office.15).aspx
Capacity planning for SharePoint Server 2013 http://technet.microsoft.com/en-us/library/ff758645(v=office.15).aspx