Configureable WSGI params

Author: stevie-

manifests/init.pp

@@ -358,6 +358,15 @@
 #   Trigges the creation of metricaccess.log which logs access to Whisper
 #   and RRD data files
 #   Default is 'False' (String)
+# [*wsgi_processes*]
+#   WSGI process count.
+#   Default is 5
+# [*wsgi_threads*]
+#   WSGI process threads.
+#   Default is 5
+# [*wsgi_inactivity-timeout*]
+#   WSGI inactivity-timeout in seconds.
+#   Default is 120
 #
 # === Examples
 #
@@ -520,6 +529,9 @@
   $gr_log_cache_performance              = 'False',
   $gr_log_rendering_performance          = 'False',
   $gr_log_metric_access                  = 'False',
+  $wsgi_processes                        =  5,
+  $wsgi_threads                          =  5,
+  $wsgi_inactivity_timeout               =  120,
 ) inherits graphite::params {
   # Validation of input variables.
   # TODO - validate all the things

templates/etc/apache2/sites-available/graphite.conf.erb

@@ -26,7 +26,7 @@ WSGISocketPrefix <%= scope.lookupvar('graphite::params::apache_wsgi_socket_prefi
 
 	# I've found that an equal number of processes & threads tends
 	# to show the best performance for Graphite (ymmv).
-	WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
+	WSGIDaemonProcess graphite processes=<%= scope.lookupvar('graphite::wsgi_processes') -%> threads=<%= scope.lookupvar('graphite::wsgi_threads') -%> display-name='%{GROUP}' inactivity-timeout=<%= scope.lookupvar('graphite::wsgi_inactivity_timeout') %>
 	WSGIProcessGroup graphite
 	WSGIApplicationGroup %{GLOBAL}
 	WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}