2009-10-27 35 views
9

Tôi có Django đang chạy trong Apache thông qua mod_wsgi. Tôi tin rằng Django là bộ nhớ đệm trang của tôi phía máy chủ, đó là gây ra một số chức năng không hoạt động chính xác.Làm thế nào để vô hiệu hóa Django/mod_WSGI Trang Caching

Tôi có đồng hồ đếm ngược hoạt động bằng cách nhận thời gian máy chủ hiện tại, xác định thời gian đếm ngược còn lại và xuất số đó vào mẫu HTML. Một bộ đếm thời gian đếm ngược javascript sau đó tiếp quản và chạy đếm ngược cho người dùng.

Sự cố phát sinh khi người dùng làm mới trang hoặc điều hướng đến một trang khác với đồng hồ đếm ngược. Bộ hẹn giờ xuất hiện để nhảy xung quanh đến các thời điểm khác thường, thường quay trở lại cùng một thời gian lặp đi lặp lại trên mỗi lần làm mới.

Sử dụng HTTPFox, trang không được tải từ bộ nhớ cache của trình duyệt của tôi, vì vậy có vẻ như Django hoặc Apache đang lưu vào bộ nhớ cache của trang. Có cách nào để vô hiệu chức năng này không? Tôi sẽ không có đủ lưu lượng truy cập để lo lắng về việc lưu vào bộ nhớ cache đầu ra của tập lệnh. Hoặc tôi hoàn toàn sai về lý do tại sao điều này xảy ra?

[Chỉnh sửa] Từ các bài đăng bên dưới, có vẻ như bộ nhớ đệm bị tắt ở Django, có nghĩa là nó phải xảy ra ở nơi khác, có lẽ trong Apache?

[Chỉnh sửa] Tôi có mô tả kỹ lưỡng hơn về những gì đang xảy ra: Đối với 7 yêu cầu đầu tiên được thực hiện cho máy chủ, các trang được hiển thị bằng tập lệnh và trả về, mặc dù mỗi 7 trang đó dường như được lưu vào bộ nhớ cache khi nó hiển thị sau. Trên yêu cầu thứ 8, máy chủ phục vụ lên trang đầu tiên. Trong yêu cầu thứ 9, nó phục vụ trang thứ hai và cứ như vậy trong một chu kỳ. Điều này kéo dài cho đến khi tôi khởi động lại apache, khi quá trình bắt đầu lại.

[Chỉnh sửa] Tôi đã định cấu hình mod_wsgi để chỉ chạy một quy trình tại một thời điểm, điều này làm cho bộ hẹn giờ đặt lại về cùng giá trị trong mọi trường hợp. Điều thú vị là, có một thành phần khác trên trang của tôi hiển thị một hình ảnh ngẫu nhiên trên mỗi yêu cầu, sử dụng thứ tự ('?'), Và điều đó làm mới với các hình ảnh khác nhau mỗi lần, cho biết bộ nhớ đệm đang diễn ra ở Django chứ không phải trong Apache.

[Chỉnh sửa] Trong bản chỉnh sửa trước, tôi đã quay lại và xem xét tệp views.py có liên quan, tìm thấy biến bắt đầu đếm ngược đã được đặt chung trong mô-đun, bên ngoài chức năng chế độ xem. Di chuyển thiết lập đó bên trong các chức năng xem đã giải quyết được vấn đề. Vì vậy, nó bật ra không phải là một vấn đề bộ nhớ đệm sau khi tất cả. Cảm ơn tất cả mọi người đã giúp bạn về điều này.

+0

http://www.djangobook.com/en/2.0/chapter15/ – cwallenpoole

Trả lời

6

Từ kinh nghiệm của tôi với mod_wsgi trong Apache, nó là rất khó rằng họ đang gây ra bộ nhớ đệm. Một vài điều cần thử:

  1. Có thể là bạn có một số proxy server giữa máy tính và máy chủ web được một cách thích hợp hay không thích hợp bộ nhớ đệm trang. Đôi khi các ISP chạy các máy chủ proxy để giảm băng thông bên ngoài mạng của họ. Bạn có thể vui lòng cung cấp tiêu đề HTTP cho trang đang được lưu trong bộ nhớ cache hay không (Firebug có thể cung cấp cho bạn). Các tiêu đề mà tôi đặc biệt quan tâm bao gồm Cache-Control, Expires, Last-Modified và ETag.
  2. Bạn có thể đăng MIDDLEWARE_CLASSES từ tệp settings.py của mình không. Có thể bạn có một Middleware thực hiện bộ nhớ đệm cho bạn.
  3. Bạn có thể grep mã của mình cho các mục sau "bộ nhớ cache tải", "django.core.cache" và "cache_page" không. A * grep -R "search" ** sẽ hoạt động.
  4. Cài đặt.py (hoặc bất kỳ thứ gì nó nhập như "từ nhập từ địa phương *") có bao gồm CACHE_BACKEND không?
  5. Điều gì sẽ xảy ra khi bạn khởi động lại apache? (ví dụ: khởi động lại dịch vụ sudo apache). Nếu một khởi động lại xóa vấn đề, sau đó nó có thể là apache làm bộ nhớ đệm (có thể là điều này cũng có thể rõ ràng ra một bộ đệm phụ trợ bộ đệm Django địa phương)
+0

Tôi đồng ý. Có thể là Apache hoặc ISP của bạn đang lưu bộ nhớ đệm. –

+0

1. Trang web hiện đang chạy trên máy chủ trên mạng cục bộ của chúng tôi, do đó không có proxy. 2. MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', ) 3. Không ai trong số những cụm từ đó xuất hiện ở bất kỳ đâu trong mã. 4. No 5. Khởi động lại Apache sẽ xóa vấn đề và làm mới bộ nhớ đệm với giá trị mới – Travis

1

Bạn đã thiết lập cụ thể bộ nhớ đệm Django chưa? Từ các tài liệu có vẻ như bạn sẽ biết rõ ràng nếu Django được bộ nhớ đệm vì nó đòi hỏi phải làm việc trước để làm cho nó hoạt động. Cụ thể, bạn cần phải xác định nơi lưu các tệp được lưu trong bộ nhớ cache.

http://docs.djangoproject.com/en/dev/topics/cache/

+0

tôi đã không làm bất kỳ điều này sơ bộ công việc, vì vậy tôi đoán bộ nhớ đệm Django bị vô hiệu hóa ... Bất kỳ ý tưởng những gì khác có thể gây ra vấn đề với thời gian bắt đầu hẹn giờ được lưu trữ? Có thể apache với mod_wsgi được làm điều này? – Travis

1

Bạn đang sử dụng cấu hình đa xử lý cho Apache/mod_wsgi? Nếu bạn có, điều đó sẽ giải thích tại sao các phản hồi khác nhau có thể có giá trị khác nhau cho bộ hẹn giờ có khả năng khi bộ hẹn giờ được khởi tạo sẽ khác nhau đối với mỗi yêu cầu xử lý quy trình. Vì vậy, tại sao nó có thể nhảy xung quanh.

Có một chi của:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

làm việc trong chế độ cấu hình hoặc bạn đang chạy Apache/mod_wsgi và có lẽ gửi cấu hình đó là những gì những gì. Không biết, có quá nhiều ẩn số.

+0

httpd -V cho thấy MPM Prefork đang được sử dụng. threaded: no, forked: yes (số đếm biến) – Travis

+0

Sau đó, các yêu cầu riêng biệt có thể được xử lý bởi các quy trình khác nhau và do đó các quy trình đó có thể có các quan điểm riêng biệt về dữ liệu. Đồng thời đọc 'http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html' để biết các mối nguy hiểm khi sử dụng prefork với mod_python và mod_wsgi. –

+0

Điều đó dường như là những gì đang xảy ra. Tôi đã thay đổi cấu hình để chạy ở chế độ Daemon, hạn chế số lượng các quy trình thành một, điều này đã giới hạn nó chỉ với một phiên bản được lưu trong bộ nhớ cache của trang. Vì vậy, bộ đếm thời gian của tôi đặt lại cho cùng một giá trị trên mọi yêu cầu. Đó là tiếc là vẫn không phải là hành vi mong muốn mặc dù. – Travis

2

Tôi vừa bắt gặp này:

Hỗ trợ tự động tải lại để giúp các công cụ triển khai, bạn có thể kích hoạt hỗ trợ cho nạp lại tự động. Bất cứ khi nào một cái gì đó thay đổi tệp .wsgi, mod_wsgi sẽ tải lại tất cả các quy trình daemon cho chúng tôi.

Cho rằng, chỉ cần thêm các chỉ thị sau đây để phần Directory của bạn:

WSGIScriptReloading On 
+1

Được bật theo mặc định, do đó bạn không phải lo lắng về điều đó. Cách tải lại được xử lý được mô tả trong http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode –

+2

Tôi không biết - nhưng tôi có thể nói rằng tôi đã sử dụng wsgi trên hai máy khác nhau - một với một trang web dựa trên Django phức tạp (OpenStack Dashboard/Horizon), và một với các kịch bản lệnh đơn giản hơn - và bật WSGIScriptReloading lên mỗi khi thực hiện nó vì vậy khi tôi sửa đổi các kịch bản - các sửa đổi sẽ có hiệu lực khi tải lại trang tiếp theo mà không phải khởi động lại Apache. – Brad

+1

Vâng tôi có thể nói rằng tôi đã viết mod_wsgi và mã có nó theo mặc định. Như đã giải thích trong tài liệu mà tôi đã liên kết, cho chế độ nhúng trên tệp kịch bản lệnh WSGI được tải lại và không phải tất cả mã ứng dụng. Bạn nên kiểm tra kỹ xem bạn có đang sử dụng chế độ nhúng hay chế độ daemon như tài liệu mô tả hay không. Khá thường xuyên, mọi người không có chỉ thị WSGIProcessGroup và không sử dụng chế độ daemon như họ nghĩ. –

Các vấn đề liên quan