Opcache optimization in production about trellis HOT 11 CLOSED

Working on it

from trellis.

Considering the conversation we had the other day about memcache and having it enabled or disabled based on a boolean, do we want to do the same thing here, or just enable it always in php.ini?

from trellis.

Things like this should be in a template driven by variables with good defaults. Which brings up the question of how to use different values based on environment. Came across this: https://groups.google.com/forum/#!msg/Ansible-project/7Lnf5uuCWCY/-JWECvkiyxMJ

 - include_vars: "defaults/{{ item }}.yml"
   with_first_found:
     - "{{ environment }}.yml"
     - main.yml

Not entirely sure if we should be using the defaults or vars folder. Regardless, we need a better way of determining "environment" than just checking group_names since there's multiple in there.

from trellis.

I'm stopping for the night. You can follow along here: https://github.com/FightTheCurrent/bedrock-ansible/tree/feature/opcache

I went ahead and put the default variables in roles/php-55/defaults/main.yml and overrode a few development ones in group_vars/development

from trellis.

I think checking for environment based on the group isn't that bad of an idea, though it can get hairy if there are a lot of groups. At this point though, there being only 3, so I don't see it as being that much of a problem. It's simple, it works, and it's easily understandable. Gets a 👍 in my book

For shiggles and some good reading, could read up on variable precedence

from trellis.

I took a look at your branch and it's good. My only concern with keeping all these variables in group_vars is it could quickly get huge. I don't really know if that's a downside?

from trellis.

I'm not sure either. The variables currently present are the differences between the production and development php.ini found here. The defaults are set to production values, that way there's no need to duplicate for staging and production.

The only other way I could think of doing it would be to use var_files and relegate it to a particular file, but I think that adds unnecessary complexity. I think this is a simple way of utilizing the groups we've defined. Perhaps we roll with this till we can come up with a better solution?

from trellis.

#16 is making me think more about this though... how much of php.ini are we wanting to customize? I can definitely see your point that group_vars/development has the ability to get huge if we're not careful. Though, I doubt a lot of people will be messing with these values anyway. Do we decide "for the people" what values should be easily customizable and have some place hidden in the recesses of the playbook where they can further customize everything? I'm starting to think var_files might be suitable in this situation like you mentioned earlier.

from trellis.

Or perhaps we have some sort of middle ground... we set what we think to be suitable defaults for all environments and then allow group_vars/{{ environment }} for fine-tuning. Here's what I'm thinking:

• roles/php-55/defaults/main.yml - Have all defaults be set to production values,
• vars/php-development.yml include development-environment overrides when: 'development' in group_names',
• and finally group_vars/{{ environment }} for fine tuning

If we follow this model, do we follow it for other systems as well? Nginx and the like? I know for values such as max file size and timeouts we'll need to store those in a common location as well. Perhaps vars/common.yml?

from trellis.

I'm thinking the common values won't really change across environments so there doesn't have to be any sort of condition as to when it's loaded.

from trellis.

Closed via #44

from trellis.