Thanks Charlie for confirming that setting. Do you want to know where I learned that? The answer is : From Mr. Super Charlie Arehart. Thanks. :-)
<Ajas Mohammed /> http://ajashadi.blogspot.com We cannot become what we need to be, remaining what we are. No matter what, find a way. Because thats what winners do. You can't improve what you don't measure. Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. On Tue, Jan 26, 2010 at 10:50 AM, Charlie Arehart <[email protected]>wrote: > Ok, but to be clear I really was only discussing the technical aspect. > I’m not sure what all the other observations brought to that part of the > discussion. My bottom line point was not to argue against your use of client > variables. I suggested a reason why one may choose to do it and yet treat > them like session variables (with timeouts in hours/minutes rather than > months/weeks), and that was if you can’t rely on sessions because they’re > lost over restarts. I just wanted to suggest that there was another > approach (in the idea of J2EE sessions being persisted by the J2EE server, > if offered as an option.) I should also have pointed out that multiple > instances with replication (in CF Enterprise) would also afford the kind of > protection of sessions over restarts, but many have a hard time getting that > working acceptably, so it’s not the first thought I’d have for this problem > I was suggesting. But if you have still other reasons to favor client vars > over sessions, no worries. But yes, I do hope the info on sessions/bots may > help. I’ll say again, though, that things in BD may be different. Can’t > recall if they have the global client variables, lastvisit and hitcount. > > > > /charlie > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Derrick > Peavy > *Sent:* Monday, January 25, 2010 10:18 PM > > *To:* [email protected] > *Subject:* Re: [ACFUG Discuss] Ideal memory & Configuration for CF > Production server? > > > > Charlie: > > > > Good point about possibly treating client vars like session. I'd like to > elaborate. > > > > I have 4 client vars in my app. That's all. Three are integers, and the > fourth is a single char. Not sure that matters in any case. Everything else > is session aside from the static application vars that most people use. > > > > In general I think it's important to create apps that are specific to the > business, the client, and the users who use them. Before you write that off > as a "yeah, don't we all," what I want to emphasize in that, is the "user" > part. > > > > With my main application, the traffic pattern of the user is such that they > are not sticking around. I run a classifieds site and it's a very specific > target. To compare, CraigsList gets about 20 pages views per user according > to (cough) Alexa. Oodle gets 5-6. It's hard to compare - impossible - to > these sites. But as a broad metric, having 2-3 pages per user visit is not > bad. The bounce rate is low and basically, that's the nature of > classifieds. > > > > That being said, if my average user is a touch and go user, and they are > only looking at 2-3 pages, and their repeat frequency is going to be spread > over several days possibly, then there is no value in retaining the client > data. And when that client data is so sparse anyway (whole other topic), > then it's even less important. On top of that, the client data that is used > is non identifiable for the most part and is never required to be known by > the user. So, when the session expires, it's no problem if the client data > has been removed too. > > > > Again, this is less about CF or technical arguments than it is about the > user pattern and the business needs. Additionally, while I do track usage > internally (two systems), there is also Google Analytics which is going to > track repeat users, etc., So again, the client data is of no value. If the > user has been inactive for 6 hours (delete time), the client data is of no > use no matter what. > > > > Now, the issue that prompted this "purging" on a regular basis is the issue > of spiders and bots and crawlers (oh my). So, I noticed that you posted a > link for that and I will be checking that out very carefully. > > > > Perhaps I can change my tactics. > > * > _____________________* > > *Derrick Peavy* > > [email protected] > > 404-786-5036 > > > > *“Innovation distinguishes between a leader and a follower.” -Steve Jobs* > > > > *"A good deal that used to be a great deal, is not nearly as good as an > awful deal that was once a horrible deal." - Dan Gilbert, > http://bit.ly/8gUruX* > > *_____________________* > > > > > > On Jan 25, 2010, at 4:01 PM, Charlie Arehart wrote: > > > > Derrick, I’ll offer a couple of follow-ups to your points to help others > with the discussion we’re now having. > > First, you mention using BD, and I’ll note that the problem that I bet was > hitting Ajas is not one that would happen on BD (the “global client variable > updates” that I discuss in the blog and recording I point to). So your > experience of the impact of client vars might be quite different from what > CFers would experience. > > Second, you mention expiring sessions in 20-30 minutes. Whether on CF or BD > (or Railo), there is no connection between sessions and client variables. > The former are stored in memory and have timeouts in minutes or hours > typically, while client variables are stored in either a db, the registry, > or a cookie and have timeouts in days (the default being 90). > > But your tool that purges those records that are more than even 6 hours old > suggests that you’re using client variables like session variables. Maybe > you liked that they were stored in DB, rather than memory, which means they > live over restarts. I will note that I indicated that session variables are > stored in memory “typically”. If one runs CF (or BD or Railo) as a J2EE web > app on a J2EE server and setting CF to use J2EE sessions, some J2EE servers > DO let you indicate that you want sessions to be stored in other than > memory. Some support DBs, some write to files, etc. Not saying all that to > suggest you should change your approach, just that if one DOES want to get > the goal of persisted sessions, there is another approach available to some. > > > > /charlie > > > > *From:* [email protected] [mailto:[email protected] <[email protected]>] *On > Behalf Of *Derrick Peavy > *Sent:* Sunday, January 24, 2010 10:40 PM > *To:* [email protected] > *Subject:* Re: [ACFUG Discuss] Ideal memory & Configuration for CF > Production server? > > > > Ajas: > > > > As always, I caveat my reply with "I am not the usual developer." > > > > First, I only have one database for client storage for all of the CF apps > on the server. Since, there are only a few on the server, and only 1 is NOT > -MY- app, it's not a problem. > > > > So, that solves a large part of the problem. At least with Blue Dragon, the > table structure includes a field for the app name. So, I can't see a > reasonable possibility of any problems. > > > > Second, I expire sessions within 20 or 30 minutes. So, I really don't need > the non identifiable old records laying around for very long. > > > > In addition to the admin settings of expire in X days, I run a script four > times a day which does a very quick, simple, clean thing - delete records > from the database that are more than 6 hours old. This keeps my database > used for client storage down to 40-100 MB in size depending on the day and > the traffic load. > > * > _____________________* > > *Derrick Peavy* > > [email protected] > > 404-786-5036 > > > > *“Innovation distinguishes between a leader and a follower.” -Steve Jobs* > > > > *"A good deal that used to be a great deal, is not nearly as good as an > awful deal that was once a horrible deal." - Dan Gilbert, > http://bit.ly/8gUruX* > > *_____________________* > > > > > > > On Jan 24, 2010, at 10:15 PM, Ajas Mohammed wrote: > > > > > Thanks Charlie and others as well. > > Charlie, your long emails are always helpful. Thanks for sharing. :-) > > I was looking at client storage tables in the 15 databases we have and the > record count is about 388466 in both CDATA and CGLOBAL. And this count is > pretty much same in *Every* 15 of the databases CDATA, CGLOBAL. I am trying > to find why we have so many records. If the flush is set for 1 hr 7 minutes > by default, then I wonder why we have so many records. I believe we have > client variables to expire if not visited in 2 days or so. > > Any thoughts about high number of records in CDATA & CGLOBAL. Can people > share their numbers i.e. record count etc > > Thanks, > > <Ajas Mohammed /> > http://ajashadi.blogspot.com > We cannot become what we need to be, remaining what we are. > No matter what, find a way. Because thats what winners do. > You can't improve what you don't measure. > Quality is never an accident; it is always the result of high intention, > sincere effort, intelligent direction and skillful execution; it represents > the wise choice of many alternatives. > > > On Fri, Jan 15, 2010 at 7:31 PM, Charlie Arehart <[email protected]> > wrote: > > Thanks, and to your next observation, I’ll note that I do list resources > listing sites using CF in my CF411: > > > > http://www.carehart.org/cf411/#cfpowered > > > > /charlie > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Derrick > Peavy > *Sent:* Thursday, January 14, 2010 8:31 PM > > > *To:* [email protected] > *Subject:* Re: [ACFUG Discuss] Ideal memory & Configuration for CF > Production server? > > > > > > I for one appreciate your efforts! > > * > *OT - was asked yesterday during a bus dev call "what is your site built > in/with" that old saw. When I said cold fusion they chuckled. This from a 26 > year old. No matter. He asked what other sites are built with CF. That old > saw. Used to be a list but I am not sure it's kept up anymore. > > > > The one that came to mind was Bank of America, but there are other big > ones. > > > > *_____________________* > > *Derrick Peavy* > > > > > ------------------------------------------------------------- > > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink <http://www.fusionlink.com> > ------------------------------------------------------------- > > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink <http://www.fusionlink.com> > ------------------------------------------------------------- > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink <http://www.fusionlink.com> > ------------------------------------------------------------- >
