Re: Question -- Session Operations - Feasibility Of Proposed Synchronization Method?

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