Choices for Client Vars: Registry Bad, Datasource Good
Client Variables and the Registry
Ask any experienced ColdFusion troubleshooter and he will tell you the same thing, "Don't store client variables in the registry." In fact, when examining a sick server one this is one of the first items I look at. If the customer says "It seems like the server stops about every hour" it's a safe bet that the default storage is set to Registry and the default purge interval has been left alone at 1 hour and 7 minutes (which is kind of an odd interval - probably some Adobe employee's anniversary in binary).
In many cases this is a "hidden" problem waiting to burst onto the scenes and bite some poor site owner in his nether regions. The owner launches his or her site and begins to gather traffic with the default settings for client variables. By default ColdFusion stores 90 days worth of client variables in the Registry - so the site can actually perform well for a few months. But then, out of no where, the server starts to drag and even stop every hour or so. Under the hood the purge operation is starting to find client vars that are 90 days old or more and it is taking quite a long time to delete them. The OS sees the registry keys being deleted and (sometimes) attempts to shrink the registry size. This affects a sort of "locking" on the registry where new keys are not being written - meaning requests are queuing and the server is slowing to a crawl. Now you might think that fixing this is as easy as switching from the registry to a datasource or cookie storage as the default, but there are some nuances to this fix that bear mentioning.
Read More7 Comments
-
67 is the first useful prime number after 60. (Yes, 61 is a prime, too, but it's too close to 60 to be of use.) Setting timeouts in durations of primes is common because it lessens the likelihood that two timeout sessions will overlap.
Of course, that's completely anecdotal and may not in any way be the reason why they chose 67 minutes, but that's always made sense to me. -
@Rick,
Ok... so you win the prize for esoteric knowledge :) That is really cool - although one wonders how slow a computer has to be to worry about seconds rather than teraflaps or something smaller (ha). -
Thanks, I never knew what the Disable global client variable updates was for. Now I know when to use it. -
If you are running a cluster of ColdFusion servers, should you create a different database for each server to use, or can you just use the same database for all of them? -
@Matt,
That greately depends on your configuration. If you are talking about load balancing (which is not the same as clustering) then One of the advantages of running a single DB for client vars is that they can then persist across the various servers... But if you are using sticky sessions this is probably not necessary (although it is convenient.).
If you are talking about true clustering then you really have only the option of using a single DB since all of the instances in the "cluster" are supposed to be replicating.
Not sure if this answers your question :) -
@Mark,
Yes, we are using load balancing. Right now we have both Sticky Sessions and Session Replication turned on and we are storing sessions in the registry, which is causing the slowdowns that your article addresses. The replication is only on in case one of the servers were to go down.
If we switch to storing sessions in a datasource, would we be able to turn off Sticky Sessions and Session Replication?
Sites to Watch
Aggregators
RSS
