On 29 August 2011 14:51, rcoup <[email protected]> wrote: > On Aug 29, 4:30 pm, Graham Dumpleton <[email protected]> > wrote: >> No, there isn't currently a way. > > No worries - was worth asking :) > >> It is possible that it may get added in some way as a side effect of >> instrumentation I intend adding to generate metrics about mod_wsgi >> configuration, number of processes/threads and number of concurrent >> requests for use by New Relic Python agent though. > > In the general case, it'd be ideal if the various daemon/mod-wsgi > config options (the easy/useful ones anyway - processes, threads, > daemon-mode, etc) were available via the mod_wsgi module. In the > meantime I'll just have to be careful where I enable it :)
Daemon mode can be determined by seeing if module version of mod_wsgi.process_group is not an empty string. What to do about processes/thread has always been a bit of a conundrum. Adding them would be mod_wsgi specific as WSGI standard doesn't provide a way of indicating that outside of context of the request. Multiprocess is also a bit of a funny one. What if you have multiple machines where each has a single daemon mode process. If you allow default single daemon mode process to be created wsgi.multiprocess is False. In some circumstances that may be fine as there is only one process on that machine. You might in other cases want to know it is multiprocess even though other processes are on other machines. It wasn't perhaps the best decision, but if you say 'processes=1' to WSGIDaemonProcess, you still get one process, but the fact you used the 'processes' option, even if 1, rather than letting it default to a single process, is enough to trigger wsgi.multiprocess to be True. Other things that can make this all complex for me at least in trying to collect metrics across all processes, are cases like delegating different parts of the URL namespace for one application to different daemon process groups, where one may be single threaded and the other multithreaded, or similarly single process and multiprocess. This in particular gets messy when you want to try and generate a measure of how many of the total number of threads across the whole application are in use at any one time. You almost can't provide it as an absolute count, but instead provide it as a percentage used from that process. Then you average the percentage out across the sum of processes. User would separately need to know what actual maximum number of concurrent requests that could be handled are and apply percentage to that themselves. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
