1๐
As Andrew Gorcester suggested, you can implement another process/daemon that will talk with your servers and get information. It will also push the information in the DB, which your django app will use to display.
This way you can separate out your implementation to retrieve data in separate module.
Moreover, you can implement the daemon as your own custom management command in django to make use of django benefits (same models, methods etc), refer Writing admin commands. You can run this command through cron or init scripts.
1๐
I think the best thing to do would be to use a separate process, for instance a twisted client that keeps a persistent connection live. Your django threads can check to see if the client process is live, and, if it is, it can communicate with that process via a socket or some other fast, local method. This is similar to e.g. a pooled database connection strategy that relies on a separate daemon like PgBouncer.
This is a fairly complex approach, but Iโm not aware of any alternative, i.e. a way to pass connection objects directly from one request to another. Even if it were possible to pass connection objects like that, you would have an issue with concurrent requests trying to use the same connection object. If you write a separate process with twisted you can set up a connection pooling system that manages this problem.
- [Answered ]-Difference between python-daemon and multiprocessing libraries
- [Answered ]-Error importing django-widget-tweaks on Google App Engine
- [Answered ]-Virtualenv wont work on
- [Answered ]-FieldError: Unknown field(s) (created_at, modified_at) specified for Account
- [Answered ]-Django Urls with a dot