"Going back" in the UI takes too long

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a campaign that contains a lot of data, e.g.: 
http://odss.mbari.org/canon/stoqs_september2013/
2. Select a Platform, e.g.: AUV Dorado (The UI updates in under 2 seconds with 
this filtered selection)
3. Clear the Platform selection to "go back" to the original view

What is the expected output? What do you see instead?

We expect the interface to respond in less than a few seconds, instead in takes 
over 5 seconds to return to the original view.

Original issue reported on code.google.com by MBARIm...@gmail.com on 14 Nov 2013 at 8:01

[GoogleCodeExporter]

This issue was first reported by a user In the spring of 2013. We expected that 
the new dedicated server installed in the summer of 2013 would improve the 
response time, but unfortunately it'd did not provide appreciable improvement.

We now need to investigate memcached or some other caching mechanism to improve 
responsiveness.

Original comment by MBARIm...@gmail.com on 14 Nov 2013 at 8:12

[GoogleCodeExporter]

Django's caching tutorial documentation is at 
https://docs.djangoproject.com/en/1.3/topics/cache/

Original comment by MBARIm...@gmail.com on 15 Nov 2013 at 5:15

[GoogleCodeExporter]

Tried implementing an per-site cache:

1. yum install memcached python-memcached
2. chkconfig memcached on
3. /sbin/service memcached start
4. pip install python-memcached
5. Modify settings.py:
    Add to MIDDLEWARE_CLASSES:
       'django.middleware.cache.UpdateCacheMiddleware',
    and
       'django.middleware.cache.FetchFromCacheMiddleware'

+# Assumes memcached is running on localhost at the default port of 11211
+CACHES = {
+    'default': {
+        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
+        'LOCATION': '127.0.0.1:11211',
+    }
+} 

Going back IS much faster. For an initial load of 2 seconds, going back takes 
just 0.17 seconds. However, the tracklines on the map do not properly update. 
This is because with the AJAX request the server creates a map file for 
Mapserver to execute. This is not cached by the Django framework.

One idea to fix this is to separate the mapfile generation into a separate 
request (view) and to implement per-view caching. There will be a bit of code 
modification in stoqs/views/query.py, urls.py, and may some other files.

Original comment by MBARIm...@gmail.com on 18 Nov 2013 at 3:49

• Changed state: Started

[GoogleCodeExporter]

The per-view cache appears to work with the mapfile generation factored out of 
the summaryData request/view. The per-view configuration is as above with out 
the additions to MIDDLEWARE_CLASSES and a decorator is applied to the view code 
function.

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 7:35

[GoogleCodeExporter]

This issue was closed by revision c93675f07698.

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 7:39

• Changed state: Fixed

[GoogleCodeExporter]

Deployed on kraken and noticed that the ajax request to build the mapfile 
executes before onInit() finished requesting the platform list (which is needed 
to draw the map). This results in features not being drawn on the map on first 
load.

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 4:54

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision ab33f043687b.

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 4:57

• Changed state: Fixed

[GoogleCodeExporter]

Ooops.  Error in .then()...

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 5:07

• Changed state: Started

[GoogleCodeExporter]

Ooops.  Error in .then()...

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 5:07

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision de1a43769ea2.

Original comment by MBARIm...@gmail.com on 19 Nov 2013 at 5:08

• Changed state: Fixed