id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
5513	Last session refactoring vastly down Django performance	Manuel Saelices	Jacob	"Changes made in [6333] are wonderful because allow Django to store session information not only in database, rather in file system or memcached.

But the problem is Django is now too much slower (I'll have to investigate why). These are my experiments in my web site, that is more than a simple poll application:

{{{
  ~$ cd django_src
  ~$ svn up -r6332
  [...]
  ~$ ab2 -n 200 http://localhost:8000/
  [...]
  Document Path:          /
  Document Length:        8598 bytes

  [...]
  Total transferred:      966800 bytes
  HTML transferred:       928600 bytes
  Requests per second:    33.75 [#/sec] (mean)
  Time per request:       29.631 [ms] (mean)
  Time per request:       29.631 [ms] (mean, across all concurrent requests)
  Transfer rate:          159.29 [Kbytes/sec] received

  [...]

  ~$ svn up -r6333
  [...]
  ~$ ab2 -n 200 http://localhost:8000/
  [...]
  Document Path:          /
  Document Length:        8598 bytes

  [...]
  Total transferred:      966800 bytes
  HTML transferred:       928600 bytes
  Requests per second:    22.18 [#/sec] (mean)
  Time per request:       45.086 [ms] (mean)
  Time per request:       45.086 [ms] (mean, across all concurrent requests)
  Transfer rate:          104.69 [Kbytes/sec] received
}}}

My sessions is stored on postgresql. It downs from '''33.75rps''' to '''22.18'''. It's a great performance penalty.

Other experiments: with {{{file}}} session backends speed ups Django to '''32.50''' rps (like old database session machinery) and with memcached ({{{cache}}} backend) it ups to {{{33.15rps}}}, more or less like file backend also.

I think is a must to do a tunning and profiling here."		closed	Contrib apps	dev		fixed	slowness performance	ferringb@…	Accepted	1	0	0	0	0	0