巨大なDjangoセッションテーブル、通常の動作またはバグ？

Question

おそらくこれは完全に正常な動作ですが、django_sessionテーブルははるかに大きい必要があります。

DELETE FROM %s WHERE expire_date < NOW() 

番号：

• 我々はおよそ持っているサイズが期限切れのセッションによって引き起こさではありませんので

  まず第一に、私は毎日、次のクリーンアップコマンドを実行します。毎日5000人のユニークビジター（ボットが除外されています）。

• SESSION_COOKIE_AGEがテーブルだから少し1,000,000 を超える行

を持って、私は、Djangoはまた訪れるすべてのロボットのためのセッション鍵を生成することを推測している

2週間、デフォルトに設定されていますボットはクッキーを保存しないので、新しいクッキーが継続的に生成されます。

これは正常な動作ですか？ Djangoが匿名ユーザーのためのセッションを生成しない、または少なくともセッションを使用していないユーザーのセッションを生成しない設定がありますか？

Answer 1

少しのデバッグの後、私は問題の原因を追跡することができました。 私のミドルウェア（そして私の意見のほとんど）にはrequest.user.is_authenticated()があります。

django.contrib.authミドルウェアはrequest.userソース

LazyUser()に設定していますがreturn Noneが、OKがあり、なぜhttp://code.djangoproject.com/browser/django/trunk/django/contrib/auth/middleware.py?rev=14919#L13は（私は見ていません...）

class AuthenticationMiddleware(object): 
    def process_request(self, request): 
     assert hasattr(request, 'session'), "The Django authentication middleware requires session middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to insert 'django.contrib.sessions.middleware.SessionMiddleware'." 
     request.__class__.user = LazyUser() 
     return None 

LazyUser通話get_user(request)ユーザーを取得するには：

出典：http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/init.py?rev=14919#L100

： http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/middleware.py?rev=14919#L5

class LazyUser(object): 
    def __get__(self, request, obj_type=None): 
     if not hasattr(request, '_cached_user'): 
      from django.contrib.auth import get_user 
      request._cached_user = get_user(request) 
     return request._cached_user 

get_user(request)方法はuser_id = request.session[SESSION_KEY]

ソースを行います

出典：セッションにアクセスする際

def get_user(request): 
    from django.contrib.auth.models import AnonymousUser 
    try: 
     user_id = request.session[SESSION_KEY] 
     backend_path = request.session[BACKEND_SESSION_KEY] 
     backend = load_backend(backend_path) 
     user = backend.get_user(user_id) or AnonymousUser() 
    except KeyError: 
     user = AnonymousUser() 
    return user 

はtrueに accessedを設定 http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/base.py?rev=14919#L183

def _get_session(self, no_load=False): 
    """ 
    Lazily loads session from storage (unless "no_load" is True, when only 
    an empty dict is stored) and stores it in the current instance. 
    """ 
    self.accessed = True 
    try: 
     return self._session_cache 
    except AttributeError: 
     if self._session_key is None or no_load: 
      self._session_cache = {} 
     else: 
      self._session_cache = self.load() 
    return self._session_cache 

そして、それは、セッションの初期化になります。バグは、accessedがtrueに設定されているときにもセッションを生成する不良セッションバックエンドによって引き起こされました。

Answer 2

Djangoはこれらの期限切れのセッションmanagement command to cleanupを提供しています！

Answer 3

ユーザーセッション（匿名ユーザーの場合でも）やsession.set_test_cookie()（たとえば、このメソッドを呼び出しているDjangoのデフォルトのログインビュー）を使用するページでロボットが何かを設定することは可能ですか？どちらの場合も、新しいセッションオブジェクトが作成されます。 robots.txt内のそのようなURLを除外すると役立ちます。

Answer 4

私の場合は、正確に意味を理解することなくに間違って設定しました。

私のdjangoサービスに対するすべてのリクエストは、セッションエントリ、特にアップストリームロードバランサからのハートビートテスト要求を生成します。数日間稼働した後、django_sessionテーブルが巨大になった。