Re: am I understanding sessions correctly?

[Chris Curvey]

>
> Yes, your caching seems a likely culprit, and so does the asynchronous
> nature of you AJAX (but it seems like you've got a handle on that
> part). I haven't thought through the load balancer bit yet, but
> presumably they are all using the same cache / database / session
> store..?
>

update -- we seem to have resolved the problem by installing memcached
and using the "django.contrib.sessions.backends.cached_db" session
middleware.  We also seem to have gotten a nice (and unexpected)
performance boost as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: am I understanding sessions correctly?

[Chris Curvey]

Thanks for the thoughts, Stuart.

On Dec 23, 2:08 pm, Stuart Laughlin  wrote:
> On Dec 22, 9:01 am, ChrisCurvey wrote:
>
> > The short version:  when processing a request, does Django *always*
> > collect session information from the session store before starting the
> > view?
>
> Yes. However note that django only saves to the session database when
> the session has been modified. It doesn't seem like that's affecting
> you, but I can't be sure.

So long as Django is auto-saving and auto-fetching, I think I should
be OK.  I guess I could set up something to monitor the database
activity.

>
> http://www.djangobook.com/en/2.0/chapter14/
>
> > The long version:
>
> > i have an application that makes heavy use ofAJAX.  When a user
> > changes something on the page, the page fires anAJAXPOST to apply
> > the changes to the database, then a series ofAJAXGETs to refresh
> > other portions of the page.
>
> You say, "then a series ofAJAXGETs" but when is "then"? Presumably
> in the post's callback function? Because otherwise you have no
> guarantee that the POST completes before the GETs fire.

The query is fired from jQuery, and here's my code.  (I realize this
is getting a little far from being Django-specific)

  $.ajax({url: "/hold_time_cost/" ,
  data: {tran_num : $(this).attr('tran_num'),
 value : checked,
 file_number : file_number},
  type: "POST",
  async: false,
  cache: false,
  complete: function(request, status) {
get_unbilled_costs(file_number);
get_held_costs(file_number);
  }
});

>
>
> > Some of the GETs are expensive, so I have some process_response()
> > middleware that caches the HTML generated by the GET in the Django
> > session.  (It's the standard database session store.)  I also have
> > some process_request() middleware that either returns the cached HTML
> > if it can, or invalidates the cache on any POST.
>
> > Just to add to the fun, I have a four identical Django/mod_wsgi
> > instances running behind a round-robin load balancer.  So the POST
> > request might get handled by Django1, the first GET by Django2, the
> > second GET by Django3, and so on.
>
> > My problem is that sometimes the results of the POST are not visible
> > in the results of the GET.  The problem is intermittent, which is
> > leading me to point the finger at my cacheing strategy.  My assumption
> > was that Django would reload the session from the database every time
> > before starting my view code, but I'm wondering if that is not true
> > (or if there is some other issue that I'm not thinking about).
>
> Yes, your caching seems a likely culprit, and so does the asynchronous
> nature of youAJAX(but it seems like you've got a handle on that
> part). I haven't thought through the load balancer bit yet, but
> presumably they are all using the same cache / database / session
> store..?

I'm wondering if maybe I should futz with using the
django.contrib.sessions.backends.cached_db for a session engine.

>
> --Stuart

-- Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: am I understanding sessions correctly?

[Stuart Laughlin]

On Dec 22, 9:01 am, Chris Curvey  wrote:
> The short version:  when processing a request, does Django *always*
> collect session information from the session store before starting the
> view?
>

Yes. However note that django only saves to the session database when
the session has been modified. It doesn't seem like that's affecting
you, but I can't be sure.

http://www.djangobook.com/en/2.0/chapter14/

> The long version:
>
> i have an application that makes heavy use of AJAX.  When a user
> changes something on the page, the page fires an AJAX POST to apply
> the changes to the database, then a series of AJAX GETs to refresh
> other portions of the page.
>

You say, "then a series of AJAX GETs" but when is "then"? Presumably
in the post's callback function? Because otherwise you have no
guarantee that the POST completes before the GETs fire.

> Some of the GETs are expensive, so I have some process_response()
> middleware that caches the HTML generated by the GET in the Django
> session.  (It's the standard database session store.)  I also have
> some process_request() middleware that either returns the cached HTML
> if it can, or invalidates the cache on any POST.
>
> Just to add to the fun, I have a four identical Django/mod_wsgi
> instances running behind a round-robin load balancer.  So the POST
> request might get handled by Django1, the first GET by Django2, the
> second GET by Django3, and so on.
>
> My problem is that sometimes the results of the POST are not visible
> in the results of the GET.  The problem is intermittent, which is
> leading me to point the finger at my cacheing strategy.  My assumption
> was that Django would reload the session from the database every time
> before starting my view code, but I'm wondering if that is not true
> (or if there is some other issue that I'm not thinking about).

Yes, your caching seems a likely culprit, and so does the asynchronous
nature of you AJAX (but it seems like you've got a handle on that
part). I haven't thought through the load balancer bit yet, but
presumably they are all using the same cache / database / session
store..?


--Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.