Loading ...
Sorry, an error occurred while loading the content.

Re: using memcached as a StateDB

Expand Messages
  • Thanos Chatziathanassiou
    I had my svn repository disk die on me recently, but still have my working copy around and got some free time to hack it. It turned into a real Apache::Session
    Message 1 of 5 , Dec 17, 2009
    • 0 Attachment
      I had my svn repository disk die on me recently, but still have my
      working copy around and got some free time to hack it.
      It turned into a real Apache::Session session store back-end for
      Apache::ASP and seems to be working fine so far, although it is a bit
      rough around the edges.

      Due to ``internal'' and ``application'' not being valid keys for most
      Apache::Session implementations, I had them hard-coded to
      ``00000000000000000000000000000000'' and
      ``ffffffffffffffffffffffffffffffff'' respectively. The ugly part is
      Apache::ASP::State::ApacheSession::ServerAutoKeys, which creates these
      automatically if they're needed when a request arrives.
      I'm afraid it is prone to deadlock if there are multiple simultaneous
      first requests and the session store is something heavier than memcached
      (memcached and redis seem to be fine with it by design of course). Due
      to this, it is off by default, but can be turned on in the server
      configuration.
      The hard-coded 1MB limit item size in memcached is somewhat problematic
      for internal and I had it run out without compression by creating about
      28000 sessions. The space each session occupies in internal is fixed,
      regardless of its contents, right ?
      I suppose having the session manager clean up on a tighter schedule is
      an option with a fast backend though.

      Some benchmarks look promising:
      memcached running on localhost
      $ perl multi_http.pl --requests=1000 --concurrency=5
      --url=http://127.0.0.1:8080/asp/benchmarks/memcached/index.asp
      Child 001: 200 requests success: 200, failure: 0 in 1.560713 sec
      Child 003: 200 requests success: 200, failure: 0 in 1.564235 sec
      Child 004: 200 requests success: 200, failure: 0 in 1.577891 sec
      Child 002: 200 requests success: 200, failure: 0 in 1.630787 sec
      Child 005: 200 requests success: 200, failure: 0 in 1.565008 sec
      Parent total time: 1.66203 sec

      classic sessions running on shmfs/tmpfs via MLDBM::Sync::SDBM_File
      $ perl multi_http.pl --requests=1000 --concurrency=5
      --url=http://127.0.0.1:8080/asp/benchmarks/classic/index.asp
      Child 001: 200 requests success: 200, failure: 0 in 1.849258 sec
      Child 005: 200 requests success: 200, failure: 0 in 1.973691 sec
      Child 004: 200 requests success: 200, failure: 0 in 2.004447 sec
      Child 002: 200 requests success: 200, failure: 0 in 2.064989 sec
      Child 003: 200 requests success: 200, failure: 0 in 2.094894 sec
      Parent total time: 2.106399 sec

      I did not yet try with MLDBM::Sync::SDBM_File on an NFS mounted
      filesystem (the server that would be hosting that died along with my svn
      repository), but these results look tempting.
      Since I'm afraid my disk might also die on me and I'd have to redo
      everything from the start, I'm attaching what I have so far.

      Once again, this has not been (properly) tested. This quite ugly. It is
      most definitely NOT production-stuff material. It is not even ready.
      Caveat emptor. Still, it shows Apache::Session back-end can be made to work.


      Configuration for the file served above:
      for memcached version:
      ---8<---
      PerlSetVar AllowSessionState 1
      PerlSetVar AllowApplicationState 1
      PerlSetVar StateDB Apache::Session::Memcached
      #Memcached
      PerlSetVar ApacheSessionParams Servers
      PerlAddVar ApacheSessionParams 127.0.0.1:11211
      PerlAddVar ApacheSessionParams Namespace
      PerlAddVar ApacheSessionParams testing
      PerlAddVar ApacheSessionParams CompressThreshold
      PerlAddVar ApacheSessionParams 10000
      PerlAddVar ApacheSessionParams AutoCreateApplicationInternalKeys
      PerlAddVar ApacheSessionParams 1
      ---8<---
      (The author of Apache::Session::Store::Memcached has not implemented
      ``Namespace'' and since I was already playing with his module, I cheated
      and changed it so that it uses Cache::Memcached::Fast instead of plain
      Cache::Memcached)

      for classic version:
      ---8<---
      PerlSetVar AllowSessionState 1
      PerlSetVar AllowApplicationState 1
      PerlSetVar StateDB MLDBM::Sync::SDBM_File
      PerlSetVar StateDir /dev/shm/apache
      ---8<---

      Other tested back-ends:
      #Sybase
      PerlSetVar StateDB Apache::Session::Sybase
      PerlSetVar ApacheSessionParams DataSource
      PerlAddVar ApacheSessionParams
      dbi:Sybase:database=session_db;server=dev_server
      PerlAddVar ApacheSessionParams UserName
      PerlAddVar ApacheSessionParams username
      PerlAddVar ApacheSessionParams Password
      PerlAddVar ApacheSessionParams password
      PerlAddVar ApacheSessionParams Commit
      PerlAddVar ApacheSessionParams 1

      #SQLite3
      PerlSetVar StateDB Apache::Session::SQLite3
      PerlSetVar ApacheSessionParams DataSource
      PerlAddVar ApacheSessionParams dbi:SQLite:dbname=/tmp/session.db

      #Postgres
      PerlSetVar StateDB Apache::Session::Postgres
      PerlSetVar ApacheSessionParams DataSource
      PerlAddVar ApacheSessionParams DBI:Pg:dbname=dev_server;host=192.168.100.46
      PerlAddVar ApacheSessionParams UserName
      PerlAddVar ApacheSessionParams username
      PerlAddVar ApacheSessionParams Password
      PerlAddVar ApacheSessionParams password
      PerlAddVar ApacheSessionParams Commit
      PerlAddVar ApacheSessionParams 1

      #Redis via self-made Apache::Session::Redis using Redis-0.08
      PerlSetVar StateDB Apache::Session::Redis
      PerlSetVar ApacheSessionParams Server
      PerlAddVar ApacheSessionParams 127.0.0.1:6379
      PerlAddVar ApacheSessionParams Namespace
      PerlAddVar ApacheSessionParams testing
    Your message has been successfully submitted and would be delivered to recipients shortly.