Inquiry about Possible Cache Mechanism or Issue in mod_wsgi with ApacheServer and Django

[王省三]

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

[Graham Dumpleton]

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

--
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 modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/bc088c4d-9859-40aa-bd7a-41b1b95b445bn%40googlegroups.com.

[王省三]

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] 的信中寫道：

[Graham Dumpleton]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/49171a58-455d-4e76-81c1-7232ae82b8b3n%40googlegroups.com.