Sounds like you want retrieving statistics from uWSGI's stats
server.
http://uwsgi-docs.readthedocs.io/en/latest/StatsServer.html
Hi Ádler,
Thank you for your reply.
Can you please review this code before I commit?
"""uWSGIController API Version 0.8.3
Middleware for storing uWSGI statistics into the environ object.
"""
import sys
import os
import logging
import demjson
import urllib
logger = logging.getLogger(__name__)
from notmm.controllers.wsgi import WSGIController
__all__ = ('uWSGIController',)
class uWSGIController(WSGIController):
def __init__(self, wsgi_app, stats_url='http://localhost:9001'):
self.wsgi_app = wsgi_app
self.stats_url = stats_url
super(uWSGIController, self).__init__() # hack
def init_request(self, request):
logger.debug('In uWSGIController.init_request...')
request.environ['uwsgi.requests'] =
self.connections(self.stats_url)
self._request = request
self._environ = request.environ
return self._request
def connections(self, url):
"""Return the amount of live connections (requests) for
all workers"""
fp = urllib.urlopen(url)
json = demjson.decode(fp.read())
connections = 0
for worker in json['workers']:
connections += worker['requests']
fp.close()
return connections
Best regards,
Etienne
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c6d79973-28b8-5236-a64e-4c24ed3c30a7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Dear Adler,
Thanks again for sharing your code with us.
Do you think it would be possible to use asyncio to defer the
computation of the active connections from the view or middleware
?
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c7a78364-e980-4144-ac1e-d0601a1de51c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hello once more time, Etienne!
There's a GitHub gist from two years ago on making a Django application use asyncio. A consequence of bringing such data through middlewares is that you will trigger a HTTP request against localhost and compute such data for every request on every single page loaded even if you don't use them anywhere (example: redirects defined by application logic that doesn't check server usage).
Solutions I can quickly imagine:
1) If you need such data in one or few views and don't want the
slowdown created by the middleware on every page load, consider
removing such middleware and moving its code into the view(s).
2) If you need such data to be displayed in every loaded page in browser, but you can do multiple requests to build a page, consider removing the middleware and creating a view that outputs the stats data as JSON, XML or pre-rendered HTML fragment and modifying your base template to contain a script that loads (and renders, if necessary) such information from a XMLHttpRequest, Ajax or something equivalent in client side.
3) If every view needs such information to make different decisions in your business logic according server load, plus code smells aren't allowed in your code base, nothing can be done except have patience and wait the request be completed.
4) If you are in the same situation as in the 3rd topic except
that code smells are allowed in your code base and that you don't
need the most up-to-date stats data, consider adopting an ugly
solution (which I don't recommend) that consists in defining a
class which inherits from threading.Thread, where its overridden
run method is an infinite loop that queries uWSGI periodically and
caches the result in an object attribute, being instanced in
middleware's __init__
method and having its threading.Thread::start() method called
there, while the body of the middleware retrieves the cached data.
One of the reasons that I consider this solution to be ugly is
because if your uWSGI ini file defines 512 workers, then you will
have 512 processes polling uWSGI's stats (which may generate some
constant CPU load even while the server is "idle").
Sincerely,
Adler