On 01/07/2016 06:30 PM, Steve Petrie, P.Eng. wrote:
Thanks to forum members for the four helpful replies, to my earlier message
that initiated this thread.
The replies expressed concerns, with the feasibility of my proposal to use
postgres tables to store short-lived context data, for dialog continuity during
website app transient sessions, with visitor browsers over modeless HTTP
connections.
Hope the four emails I sent in response (5 January 2016), went some way to
satisfying the concerns expressed.
Here is a list of the issues discussed, in the dialog mentioned above:
1. "Session" defined;
2. Avoid row DELETEs;
3. Periodically TRUNCATE each table in a pool of session context tables;
4. Embed a session ID key parameter in an HTML "hidden" field (optional);
5. Use sequence generators as rapid global iterators controlling access to
session context tables;
<SNIP>
Thanks to forum members for taking the time to read my email.
This feels hugely overcomplicated. I also didn't read most of the last thread,
so forgive me if you've answered this already: How many website requests a
second (that actually need to touch session data) are you expecting? How much
space is the session data going to take? (like, 5 Gig a day?)
If its a huge number, you should put effort into growing horizontally, not all
of this stuff.
If its a small number, you'll spend more time fixing all the broken things than
its worth.
Have you benchmarked this? In my mind, complicated == slow.
Sorry if I'm raining on your parade, it looks like you have really put a lot of
work into this.
Have you considered saving session data to disk is faster than saving to db? A
good reverse web proxy can stick a session to the same backend. 1 web proxy up
front, 5 web servers behind it. I'd bet its way faster.
-Andy
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
