> I would like to add that Ken's *not necessarily* right - if the > server is a dedicated CF server then DO USE THE REGISTRY for > client variables. The registry provides the greatest performance > when using client variables, which is why it is used by default > and why it is even an option. Do you think MM made it an option > just because it was possible or because it can be highly useful? > There are three options for three or more server environments. > > Just plan ahead for it. When you build the server, adjust the > registry to grow to around 100MB and it won't slow down and > cause the server to crap out. Monitor the size of the registry > as well, drop the persistance of client variable data from 90 > if the registry grows to large or allow the registry to grow > larger. > > Just my two cents. I've said it before I'll say it again the > next time some SCREAMS that the registry won't work. One users > bad experience shouldn't deter all others from the truth.
I guess that the problem with "the truth" is that it can be perceived so subjectively. I've had quite a few bad experiences with using the registry for Client variable storage, though - and they haven't all been mine, personally, but several have been with clients for whom it failed in a relatively dramatic fashion. The reason MM (or, more accurately, Allaire) made it an option is that, at the time, they didn't necessarily know how bad this could be, or more likely, at the time, you weren't likely to get enough traffic for it to be so bad. Client variables were introduced in CF 2.0, and they could only be stored in the registry then. The ability to store them in other places wasn't introduced until CF 4, I think. Back in those days, heavy use didn't mean the same as it does now, and very few people were building line-of-business apps on the web. As for best performance, yes, the registry may be faster than using a database. Using cookies will be just as fast, though. Performance, however, is probably not the only metric most people care about. Reliability is pretty important to most people, and registry storage is far less reliable than database storage. The Windows registry is not your typical database. It's a hierarchical data store, like an LDAP server, rather than a relational data store. It's not designed for transactional processing, like a relational database typically is. The registry is designed to be read often, and written to infrequently. The typical usage pattern for a Windows app using the registry is to read the appropriate keys on startup, then write changes to those keys if necessary on shutdown. That's quite a bit different from constantly writing to the registry. There are several weak points with using the registry. It can become fragmented, just like other files in general. This will slow performance after time. It can become corrupted - and I've encountered this personally - requiring a restore and consequently losing all of the client data. It makes it difficult to migrate an application from one server to another. In summary, I strongly recommend against using the Registry as a Client variable data store. I recommend against using a file-based database like Access for this also - that has its own, very serious, problems. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get Your Own Dedicated Windows 2000 Server PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation � $99/Month � Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionb FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
