I have some experience with MongoDB and jqPlot, for instance... I will be happy to help to create an extension to unlink this super awesome/needed library from a particular service
It has to be modular and interchangeable Anyone interested? On Sunday, June 8, 2014 2:28:19 PM UTC+2, Graham Dumpleton wrote: > > When I recently announced version 4.1.0 of mod_wsgi here on the mailing > list, I said I would try and blog about what was new in it, but I have been > having too much fun working on even more new things. > > The latest new thing comes in the mod_wsgi version 4.2.0 release. > > This feature is something I have wanted to do for many years, even back > before I started working with New Relic, but my general burnt out state of > mind around mod_wsgi meant nothing ever happened and mod_wsgi instead > stagnated. > > Anyway, I am beyond that now and finally getting on to doing it. At least > now I have access to an easy to use backend to visualise all this data I am > collecting, something which would have been non trivial back those many > years ago. > > So what mod_wsgi version 4.2.0 introduces is the first phase of a > mechanism to more closely monitor the performance of Apache and mod_wsgi > itself. This is specifically intended to help address the issue of how best > to tune the Apache and mod_wsgi processes/threads settings. > > Right now what I have done only covers Apache as a whole. This in itself > is extremely revealing, but I will be adding more detail around mod_wsgi in > the next phase. > > So you can understand what what the result of this new capability is, I > present the three dashboards of information that can currently be viewed > about what your Apache instance is doing. > > This first dashboard is an overview dashboard. The main things you can > obviously see here are throughput and response times for all requests > hitting Apache. This includes any requests for static files and isn't just > for requests handled by mod_wsgi. > > For response times, it isn't just limited to average response time as > shown here either. One can drill down to more information about requests. > > In particular, one can see percentiles for requests. So not only average > response time, but also 95th and 99th percentiles. Add to that you can see > the amount of data being transferred by Apache. > > The dashboard I most like though is that which looks at what the Apache > workers are up to, as well as the process they operate in and the server > utilisation as a whole. > > The workers in this case are the Apache threads in the Apache child > processes which are initially accepting requests. In the case of mod_wsgi > embedded mode, these are the same threads which would then in turn handle > the request after it is handed off to be processed by mod_wsgi within the > same process. If using daemon mode, they are the same threads that would > then proxy the request through to the appropriate mod_wsgi daemon process > group. > > What the workers are doing at this level can be useful in helping to tune > the Apache MPM settings and can also give guidance on setting up mod_wsgi > daemon process groups as well. In the case of the mod_wsgi daemon process > groups, the whole process would be aided somewhat though if you also > happened to be using the New Relic Python agent for monitoring your actual > web application. In the second phase of work on this new feature though, I > will be surfacing more about what mod_wsgi itself is up to which should > provide everything one needs to tune even the mod_wsgi daemon process > groups, without needing too much extra. > > As to the charts above, this is actually for a Python web application > running in mod_wsgi daemon mode with an Apache instance using prefork MPM. > If you ever watched my PyCon US talk from last year, you may remember me > talking about the evils of process churn and how the Apache prefork MPM > child processes are managed is detrimental to a Python web application > running in embedded mode. At the time I illustrated that with charts > derived from a simulation. This process churn chart above is from a real > live Apache instance and it backs up what I showed through simulation would > have been occurring. Although this Python web application was running in > daemon mode and so wasn't overly affected by that due to how Apache was > configured, if your Python web application was running in embedded mode > under mod_wsgi, that process churn could be quite detrimental to your > performance. > > So lots of pretty pictures and statistics. > > Now you may well have noticed the little New Relic logos on those charts. > This is because this feature just happens to be using the New Relic > Platform product (http://newrelic.com/platform) to capture the data and > visualise it. > > Before you run away and think that this is all useless to you then, as New > Relic is a paid product, I want to make it very clear that that is not the > case. > > All of the above charts and the ability to monitor your Apache/mod_wsgi > instance using New Relic Platform comes for free. > > This is because the feature of New Relic I am using here is available on > all free Lite accounts in New Relic. Thus you do not need to pay a cent. > You do not even need to use the New Relic Python agent to monitor your > actual Python web application, although since the Python agent web > application monitoring also provides a wealth of information even on the > free Lite accounts, you would be a bit silly not too. Same for the free New > Relic server monitoring, why wouldn't you use it. > > Sure I am biased because I also wrote the Python agent for New Relic and > work there, but believe me when I say I wouldn't work on something like > this if it wasn't going to be useful to mod_wsgi users. It was the main > reason I wanted to go work for New Relic in the first place, it has > unfortunately just taken me so long to bring my ideas about monitoring > Apache and mod_wsgi itself to reality. :-) > > Now if you had already experimented with mod_wsgi-express from version > 4.1.0, and if you had already tried the New Relic integration provided with > it, then this new plugin will be automatically enabled and the new > dashboards will start appearing in the New Relic UI. All you need to do is > upgrade mod_wsgi to version 4.2.0 or later from PyPi, ensuring that in > doing that it also automatically installs the new mod_wsgi-metrics package. > > If you are using New Relic already but using a manually installed version > of mod_wsgi and aren't installing it from PyPi, then you will need to add > some additional configuration to your Apache configuration files. The > details of this can be found with the mod_wsgi-metrics package on PyPi at: > > https://pypi.python.org/pypi/mod_wsgi-metrics > > So, upgrade to mod_wsgi 4.2.0 or later, which you can get from github or > PyPi: > > https://pypi.python.org/pypi/mod_wsgi > https://github.com/GrahamDumpleton/mod_wsgi/releases > > Then install the mod_wsgi-metrics Python package and follow those > instructions on the mod_wsgi-metrics PyPi page. > > Hopefully I will get some feedback and at least a few examples from where > people have used it that I can analyse in order to continue my quest for > building up some general rules around Apache and mod_wsgi tuning. :-) > > Graham > > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
