在前篇介紹了 CPU 和 JVM 的分配技巧，了解到 Puppet Server 和 JRuby 有著密切的關係，除此之外還有其他手段可以更進階的了解 Puppet Server 的 Loading and Performance。
如果單台 Puppet Server 可容納的 JRuby 已經到達極限則你必須考慮 Scaling 你的 Puppet Server。（Scaling Puppet Server with compile masters）
從 JRuby 看最基本面就是兩個要點，JRuby 的 Wait 和 Borrow 的時間，也就是 JRuby 越閒越好 (( 廢話
- Average JRuby Wait Time: This refers to the amount of time Puppet Server has to wait for an available JRuby to become available, and increases when each JRuby is held for a longer period of time, which reduces the overall number of free JRubies and forces new requests to wait longer for available resources.
- Average JRuby Borrow Time: This refers to the amount of time that Puppet Server “holds” a JRuby as a resource for a request, and increases because of other factors on the server.
要查看 JRuby 的 Wait 和 Borrow Time，可以從 API Monitor 下手，而官方建議可以使用像 Grafana 來畫 metrics「Monitoring Puppet Server metrics」，實際 Grafana for Puppet 的實作另外再寫 XDD ..
另外如果有使用 PuppetDB 的話也會影響效能，主要是跟 puppetdb_query 有比較大的關係，但一般比較少自己下 puppetdb_query，除非你要自己獲取一些資料或是 dashboard。
記憶體洩漏的問題
這個比較多是發生在自行針對 API 二次開發，像 dashboard 之類的，因為操作不當造成的記憶體洩漏讓 JVM 花費更多的時間進行垃圾回收，如果你的案例已經造成記憶體洩漏的問題，並且無法找到問題，可以利用 max-requests-per-instance 這個參數來做 JRuby flushing，但是因為需要額外的動作，所以整體 Puppet 效能會降低一些，但可以減少記憶體洩漏。