RAM: Memory is one of the most important factor that determines how smoothly your cluster will operate. Membase is well suited for applications that want most of its active dataset in memory. This data that is actively used at any given point in time is called the Working Set. It is very important that you allocate enough memory for the entire Working Set to live in memory. When there is not enough memory left for the new data that is written, some values are ejected from memory and will only exist on disk. Accessing values from disk is much slower than accessing data in memory. As a result, if ejected data is accessed frequently, performance of the cluster suffers. Use the formula provided in the next section to verify your configuration, to optimize performance and avoid this situation.

Number of Nodes: Once you know how much memory you will need for the cluster the next decision you will make is whether to have few large nodes or several small nodes:

Moxi: A client side moxi or a smart client is always preferred over a server side moxi but for development environments or for faster, easier deployments you can use server side moxis. The downside of a server side moxi is that there can be an additional hop if the server that receives the client request does not have data requested. Read more about clients here. Read more about different Deployment Strategies here.

Number of cores - Membase is relatively more memory or I/O bound than is CPU bound. However, Membase is more efficient on machines that have at least two cores.

Storage type - You may choose either SSDs (solid state drives) or spinning disks to store data. SSDs are faster than rotating media, but currently have a higher cost. Membase needs less memory if a cluster uses SSDs as the I/O queue buffer is smaller in case of SSDs.

WAN Deployments - Membase is not intended to be used in WAN configurations. Membase requires that the latency should be very low between server nodes and between servers nodes and Membase clients.

If you are hosting in the cloud, please read here

Restricted access to Moxi ports - Make sure that all the ports that Moxi uses are accessible only by trusted machines (including the other nodes in the cluster).

Restricted access to web console (port 8091) - The web console is password protected. However, it is recommended that you restrict access to port 8091, as a abuser could do potentially harmful operations (like remove a node) from the web console.

Node to Node communication on ports - All nodes in the cluster should be able to communicate with each other on 11210 and 8091.

Swap configuration - Swap should be configured on the membase server, to avoid the operating system killing membase server if the system RAM is exhausted. Having swap provides more options on how to manage such a situation.

Idle connection timeouts - Some firewall or proxy software will drop TCP connections which are idle for a certain amount of time (e.g., 20 minutes). If the software does not allow changing that timeout, send a command from the client periodically to keep the connection alive.