Since you are on Windows there would be only one process. So long as you aren't defining multiple VirtualHost definitions with separate WSGIScriptAlias for each, then all requests for the Django app should be in same interpreter context and data is common. So not a problem with requests being handled across multiple processes and thus different interpreter contexts, or use of multiple sub interpreters in one process.
The only way this might not be the case when have single process and interpreter context is if data you are accessing was for some reason stored in thread local storage within the process. That is, each request handler thread has its own copy of the data. * https://docs.python.org/3/library/threading.html#thread-local-data Usually one would know if your application is using thread local storage any why you were doing it that way. Also, what you would get in this case would be random based on which thread was used for a request and one client would not reliably always see same result. All I can suggest right now is set: LogLevel debug and validate that for requests from each client that mod_wsgi is actually handling the request and that the request isn't being intercepted by a caching proxy or caching mechanism of Apache itself. Also look at access log of Apache as well. There is nothing in mod_wsgi that does caching. Other alternative is whether Django caching is interfering with things. More intrusive to set up, but you could use a WSGI middleware to capture both request and response and see data at that point. * https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#tracking-request-and-response Graham > On 5 Dec 2023, at 7:54 pm, 王省三 <[email protected]> wrote: > > My project is on Windows, and the relevant configuration in httpd.conf is as > follows: > LoadFile "C:\Program Files\myproject\Python\python37.dll" > LoadModule wsgi_module "C:\Program > Files\myproject\Python\lib\site-packages\mod_wsgi\server\mod_wsgi.cp37-win32.pyd" > WSGIPythonHome "C:\Program Files\myproject\Python" > WSGIScriptAlias / "C:/Program Files/myproject/myapp/wsgi.py" > WSGIPythonPath "C:/Program Files/myproject/myapp" > > <Directory "C:/Program Files/myproject/myapp"> > <Files wsgi.py> > Require all granted > </Files> > </Directory> > > Alias /static "C:/Program Files/myproject/myapp/staticfiles" > <Directory "C:/Program Files/myproject/myapp/staticfiles"> > AllowOverride None > Options None > Require all granted > </Directory> > > <IfModule mod_headers.c> > <Location "/"> > Header unset ETag > Header set Cache-Control "max-age=0, no-cache, no-store, > must-revalidate" > Header set Pragma "no-cache" > Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT" > </Location> > </IfModule> > > <IfModule mpm_winnt_module> > ThreadsPerChild 25 > MaxConnectionsPerChild 0 > </IfModule> > Graham Dumpleton 在 2023年12月5日 星期二下午1:39:18 [UTC+8] 的信中寫道： >> There may not be only a single object because of how you have configured >> Apache/mod_wsgi. >> >> Read: >> >> * >> https://modwsgi.readthedocs.io/en/master/user-guides/processes-and-threading.html >> >> Then post your configuration so can see whether you are using embedded mode >> or daemon mode of mod_wsgi, and if the latter how you have the daemon >> process group configured, plus whether you are correctly delegating requests >> to even be run in daemon node processes. >> >> Graham >> >> >>> On 5 Dec 2023, at 4:33 pm, 王省三 <[email protected] <>> wrote: >>> >> >>> Dear mod_wsgi community, >>> >>> I hope this message finds you well. I am encountering an issue in my >>> project setup, which involves ApacheServer, mod_wsgi, and Django. >>> Specifically, when accessing the project from both the company's internal >>> network and external network, it appears that different global objects are >>> being obtained, seemingly from different memory locations. This discrepancy >>> in global objects results in an increasing time difference between internal >>> and external networks. >>> >>> In theory, there should only be one global object, and when using runserver >>> or employing Nginx or Waitress as reverse proxies, this issue does not >>> occur. Despite disabling cache-related settings in ApacheServer, the >>> problem persists. >>> >>> I would like to inquire whether mod_wsgi has any caching mechanisms or if >>> there might be an underlying issue causing this behavior. Your insights and >>> guidance on how to address or troubleshoot this matter would be greatly >>> appreciated. >>> >>> Thank you for your time and assistance. >>> >>> Best regards, Arthur >>> >> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/modwsgi/bc088c4d-9859-40aa-bd7a-41b1b95b445bn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/modwsgi/bc088c4d-9859-40aa-bd7a-41b1b95b445bn%40googlegroups.com?utm_medium=email&utm_source=footer>. >> > > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/49171a58-455d-4e76-81c1-7232ae82b8b3n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/49171a58-455d-4e76-81c1-7232ae82b8b3n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/1EE44FDB-E83E-4835-9313-FC3B3DD39C75%40gmail.com.
