drupal vm memcached mixing up 2 different sites

The page bin is the one that has the worst hits/misses ratio. The filter bin is for the 'cache_filter' table. The following bin is 'page', and it is used for the 'cache_page' table. This one is for the default bin, which is used for the 'cache_menu' and 'cache' tables. Here are some statistics for each bin, after running for three weeks. 'cache_inc' => './sites/all/modules/memcache/memcache.inc', Everything else shares a 'default' cache, which includes the menu cache and variables. You see that the page cache and filter cache each have their own bin, running on a separate instance of memcache. Then we need to change Drupal's settings.php to match that. usr/local/bin/memcached -d -u root -m 128 -p 11213 usr/local/bin/memcached -d -u root -m 320 -p 11212 Start) /usr/local/bin/memcached -d -u root -m 64 -p 11211 This would go into /usr/local/bin/memcache.sh: To do this, we first setup a start script for memcache that would start each bin with the correct size.

This article is a followup on how to configure memcache for Drupal, and how multiple bins help with performance.Įach bin in memcached correspond to one or more cache table in Drupal. composer create-project drupal/recommended-project:8.9.In a recent article, we explained how to build memcached from source and PHP memcache using PECL on Ubuntu Gutsy 7.10. The good thing about this setup is that it creates a minimal setup in your codebase and can be added to your project git repo without any problems.īy the way, if you want to install Drupal 8 using the above method then the only thing you need to change is the initial version of the recommended-project setup. You can also log into box using 'vagrant ssh', which will take you directly to the Drupal codebase and allow you to run Drush commands on the site.įrom start to finish I can go from nothing to a fully installed Drupal site in around 10-15 minutes, although that depends on what speed your internet connection is. From here you can visit you Drupal site and start getting Drupal installed properly. Once complete you can visit (or whatever URL you have added into your Vagrant file) and see the DrupalVM dashboard. With all that set up you can now run 'vagrant up' and DrupalVM will provision your machine for you. Note: The inclusion of the specific version of Xdebug here is to get around an issue I had with PHPStorm not liking the newer version. # - xhprof # use `tideways` if you're installing PHP 7+ # Turn off all automatic installer features. # Allow easy configuration of the machine resources. # the config file need to be contained within this path.ĮNV = '#/web' # The absolute path to the root directory of the project. Note that in later versions of Vagrant this file is called Vagrantfile (without the capital F). Instead of a full copy of the DrupalVM VagrantFile we instead create a small proxy file that sets up the configuration directories and then loads in the VagrantFile from the DrupalVM directory.Ĭopy the following into your VagrantFile. The first thing we need to add to the project is a VagrantFile, which will allow Vagrant to function. This doesn't do a lot on it's own, so before we provision the machine we need to add some configuration files. composer require -dev geerlingguy/drupal-vm We do this as a 'dev' dependency as we don't need to be running DrupalVM in production. With that setup the next step is to require DrupalVM. Adding Drush at this point is usually a good idea.

After this step you can require any other Drupal based modules or projects that you want. For more information on what is in the recommended composer file see my previous blog post on the subject. This will create your composer file and install the Drupal codebase along with a few other dependencies. composer create-project drupal/recommended-project drupal_vm_setup

I normally run the Drupal recommended composer setup file so that I have a up to date Drupal codebase, so let's do that here.

Start out with a Drupal site in a composer setup. I thought I would go through the steps involved in adding DrupalVM to your codebase as it's pretty simple and will get you up and running with a Drupal site in about 10 minutes. This is especially useful if something like Solr is involved as setting that up is a pain. When starting a new site project I normally add DrupalVM to the codebase so that I can get the site up and running quickly. I normally run it with Vagrant, but you can run it with Docker if you like. More than that, I find I have very few problems with running it. I like working with DrupalVM and I've worked with Ansible based Vagrant setups for years and so I'm very familiar with it's setup.

Drupal vm memcached mixing up 2 different sites