Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-1697

Manual configuration of per-environment pools for isolation



    • Epic
    • Status: Closed
    • Normal
    • Resolution: Won't Do
    • None
    • None
    • None
    • None
    • Isolate 1 environment per JRuby
    • Froyo
    • Done
    • Needs Assessment


      This "sub-epic" is an offshoot from one of the comments on SERVER-94, from here: https://tickets.puppetlabs.com/browse/SERVER-94?focusedCommentId=329083&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-329083. Text below is copied pretty liberally from that comment:

      This "sub-epic" would expand our JRuby pooling to allow a user to configure a pooling "strategy". The default strategy would, for some period of time, continue to be the current "single-pool" strategy under which the same JRuby instance can be exercised by multiple environments.

      This "sub-epic" would introduce a new manual/explicit pooling "strategy". In this approach, the user would be responsible for setting up their configuration to list what the most common (and performance-sensitive) environments were, and tell us how many JRubies to keep around dedicated to those environments. Then, there'd be a sort of 'overflow' pool for uncommonly used environments. The user could also configure the size of this pool. Whenever we got an agent request from an environment that isn't on the 'dedicated' list, we'd use this overflow pool, which we'll flush instances out of using an LRU strategy. We can keep a couple of JRubies warm to make the process of cycling things in and out of this overflow pool faster.

      The config might look something like this (credit to nanliu as this was his idea, probably like 3 years ago now):

          {pooling-strategy: configured-environments
           dedicated-environments: {
              production: {pool-size: 4}
              test: {pool-size: 4}
              staging: {pool-size: 4}
           overflow-pool-size: 4
           pre-warmed-pool-size: 2

      The upside of this approach is that the implementation should be fairly simple and easy to debug, and the configurability should be sufficient for tuning for most users needs. The downside is that it will require some knowledge and configuration on the part of the user. But, since it should be faster to get out the door, and should serve as a valuable stepping stone towards any other strategies we want to implement.


        Issue Links



              Unassigned Unassigned
              jeremy.barlow Jeremy Barlow
              6 Vote for this issue
              16 Start watching this issue



                Zendesk Support