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: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick Peavy Sent: Monday, January 25, 2010 10:18 PM To: discussion@acfug.org 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 derr...@derrickpeavy.com 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: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick Peavy Sent: Sunday, January 24, 2010 10:40 PM To: discussion@acfug.org 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 derr...@derrickpeavy.com 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 <char...@carehart.org> 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: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick Peavy Sent: Thursday, January 14, 2010 8:31 PM To: discussion@acfug.org 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 http://www.fusionlink.com -------------------------------------------------------------
