Hi Byron (and others),
Quick follow up re: eliminating client variables (and wddx, etc.). Are you
saying that you are able to maintain login persistence using sessions with
the whole site in https so that you don't have to worry about logins being
dropped with sessions (which is probably what we will do)? Or did you move
to some other solution for login persistence?
Another, related, example would be maintaining a url throughout a login.
For instance, if you are on a site and click on a link to a password
protected, you will be re-directed to the login screen. Once you login, we
would like you to be directed automatically to the page. Sessions would be
a handy way to do that. But, if we wanted to maintain the option to not
have the whole site in https, then using sessions for this functionality
would seemingly have the risk of sessions being dumped when you move into
https and you would not be automatically redirected to the target page
after login. So, again, I'd be interested in knowing alternate ways to
handle that kind of scenario. (We have a way now but it may not be the most
Received: from mail.houseoffusion.com [220.127.116.11] by
mail67.safesecureweb.com with SMTP;
Wed, 16 May 2012 01:37:33 -0400
To: cf-talk <cf-talk@hous...>
Subject: Re: best practice on session variable persistence and ssl?
Date: Wed, 16 May 2012 01:37:16 -0400
Reply-To: cf-talk@hous... From: Byron Mann <byronosity@gmai...>
Content-Type: text/plain; charset="ISO-8859-1"
X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None
I hear ya, since we eliminated the client variables all together and that
whole wddx thing, our (internal) cf instances only go down during OS
patches. Can't remember the last time I had to restart the service
Should also mention we are using jetty which has seemed to uptick
performance all around.
Now shared is another ball of wax.
Lead Engineer and Architect
On May 16, 2012 1:30 AM, "Andrew Scott" wrote:
> Funny you should mention high session time outs.
> I was given a task by a friend to look at, on something that I did many
> years ago. Since then they had another developer come in make some
> and the server fell over about 5 times a day, when I looked at it, the
> session was set to 2 days, I was like WTF...
> Change it back to what I had set it at 6 years ago, and 8 months later
> hasn't fallen over once.
> Andrew Scott
> WebSite: http://www.andyscott.id.au/ > Google+: http://plus.google.com/108193156965451149543 >
> On Wed, May 16, 2012 at 3:12 PM, Byron Mann wrote:
> > Note on the wddx, we were doing the same thing. We put a to client
> > the onrequestend.cfm and to session in the application.cfm/c
> > This was all good until we started adding a lot of ajax calls and
> > increased the total numbed of http requests. We had all kinds of
> > issues and even client db corruption from the number and size (we had
> > rather large session structures) of write operations. This at one
> > adding about 1.5 secs per request.
> > We first moved to json serialization which seemed faster and smaller
> > size than wddx.
> > Though, eventually we moved away from client vars all together and are
> > using session variables for all apps on our internal cluster.
> > I doubt I'll every use client vars again, even in a cluster, and I've
> > learned to keep sessions as small as possible. One of our main issues
> > shared cf hosting are apps that have large sessions which hog
> > Came across a customer today with 100 sessions totalling about 45 MB,
> > that's just one example. High session timeouts are another factor in
> > performance as well. Often seen customers requesting us to up the
> > to days, no so good :-)
> > Byron Mann
> > Lead Engineer and Architect
> > Hostmysite.com
> > On May 15, 2012 2:44 PM, "Nick Gleason" wrote: