PageRenderTime 27ms CodeModel.GetById 25ms RepoModel.GetById 0ms app.codeStats 0ms

/docs/processes.txt

https://bitbucket.org/ianb/silverlining/
Plain Text | 39 lines | 29 code | 10 blank | 0 comment | 0 complexity | 0480a73a50f53140a554386d5bbffcb9 MD5 | raw file
Possible License(s): GPL-2.0
  1. Processes
  2. ---------
  3. .. warning::
  4. I'm pretty sure my understanding of the process model is actually
  5. incorrect, and this document isn't correct.
  6. This document explains the process model of Silver Lining.
  7. Silver Lining runs under `mod_wsgi
  8. <http://code.google.com/p/modwsgi/>`_, but mod_wsgi itself is
  9. configurable, and Silver Lining configures it a specific way. The
  10. result works like this:
  11. * Each application instance runs in its own processes. So if you
  12. upload multiple applications (that are all live simultaneously) then
  13. those will never be in the same process. This is necessary because
  14. there's no way besides separate processes to keep paths and
  15. libraries straight.
  16. * An application gets 5 concurrent processes. That is, there is a
  17. pool of 5 processes that wait for a request to come in.
  18. * There are no threads, each process is single-threaded.
  19. * Processes live for a limited number of requests (200 requests).
  20. After that the process is killed and another started in its place.
  21. This avoids some possible memory leaks or other problems associated
  22. with long-running processes.
  23. * All processes run as the user ``www-data``.
  24. * "Internal" requests are run in their own short-lived processes.
  25. This includes requests like the ``update_fetch`` request. They
  26. otherwise run very similarly to normal requests (as ``www-data``,
  27. similar environment, etc). However, because it is not actually
  28. under mod_wsgi, it is very possible that there will be differences
  29. in the environ.