[CF-Talk] RE: cflocking.. -- ATTENTION -- MY CASE STUDY
Yes but during that test were those variables being written to at the same time? I beleive that if you do a read without locking, and a write occurs or is occuring at the same time, you will have problems. But what if there is no writing? Say you setup a datasource name if its not defined. Then thats it, it will never be written to again until the server restarts and application variables are lost. In this situation can't you do reads without locking? after the application loaded, there were no additional variables being written, just read. and yes, that was what caused the fatalities. there is a setting in CF Admin that can do the read locks automatically. that is what we're currently using and even under load testing we cannot find any real performance degradation. i know it sounds really bad. i've asked myself over and over "why the #$(* did allaire implement something that would force me to possibly rewrite everything i've done". to tell you the truth, that's exactly why we'll be moving to JSP/EJB in the next six months -- vendor independence. i can only wonder how many other development companies have or will be moving off ColdFusion because v4.5 was so unstable and questionable. -mike -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarRstsbodyRsts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: cflocking.. -- ATTENTION -- MY CASE STUDY
I totally agree with you Al. The final judgement should be on our shoulders. Give us the extra option and we will know which will be the best strategy for our unique situations. Even though I love speed, I would take stability any day. I don't mind a few a few milliseconds here and there but I do mind coming in to the server room on a weekend because the coldfusion service has stopped responding again. =) Adding cflocks aren't that bad at all but I would still like the option. I think allaire should concentrate on stability a little more to be honest. Xing From: "Al Musella, DPM" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Sat, 16 Sep 2000 20:57:26 -0400 To: [EMAIL PROTECTED] Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY I read that paper, and still would like to have an option for automatic locking. Maybe add an attribute to the cfapplication tag: automatic locking: on |off The development time saved on it will more than offset the cost of a faster processor needed for the 2 or 3 microseconds added to each template that will be wasted:) And if you have a transaction problem or a performance problem, you can do it manually. The best of both worlds. I think this one issue is what made Turbobasic and quickbasic such a hit in the 80s and early 90s and VB now. You didn't have to worry about nit picky little things that could crash your program, but which would be easily automated. Developers were free to just worry about the logic. Do you agree with Allaire's reasoning? (By the way - I am a big fan of CF from way back in the 2.0 years.. Al Musella a1webs.com Yes, they explained why. See Allaire's recent paper, "ColdFusion Locking Best Practices" http://www.allaire.com/handlers/index.cfm?ID=17318Method=Full best, paul At 11:56 AM 9/16/00 -0400, you wrote: Why can't cold fusion just automatically lock them? Has Allaire ever responded on this issue? - - -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
html font size=3I agree. The article claims they don't automate locking for (1) performance issues. Well, if I do all the same locks by hand the performance will be WORSE, and (2) to give the developer the option to do less granular locks. How about giving me the option to set a manual lock but otherwise automatically locking it?br br This issue is going to become a major problem as scores of unsophisticated Cold Fusion developers create sites that crash. Cold Fusion will get a reputation for being unstable NO MATTER that it is the developer's fault.br br At 08:57 PM 9/16/00 -0400, Al Musella, DPM wrote:br br blockquote type=cite citenbsp;nbsp;nbsp; I read that paper, and still would like to have an option for automatic br locking. Maybe add an attribute to the cfapplication tag:nbsp; automatic br locking: on |offbr nbsp;nbsp;nbsp; The development time saved on it will more than offset the cost of a br faster processor needed for the 2 or 3 microseconds added to each template br that will be wasted:)nbsp; And if you have a transaction problem or a br performance problem, you can do it manually. The best of both worlds.br nbsp;nbsp;nbsp;nbsp; I think this one issue is what madenbsp; Turbobasic and quickbasic such a br hit in the 80s and early 90s and VB now. You didn't have to worry about nit br picky little things that could crash your program, but which would be br easily automated.nbsp; Developers were free to just worry about the logic.br br Do you agree with Allaire's reasoning?br nbsp;nbsp; (By the way - I am a big fan of CF from way back in the 2.0 years..br br Al Musellabr a1webs.combr br br Yes, they explained why.nbsp; See Allaire's recent paper,br gt;quot;ColdFusion Locking Best Practicesquot;br gt;a href="http://www.allaire.com/handlers/index.cfm?ID=17318amp;Method=Full" eudora="autourl"http://www.allaire.com/handlers/index.cfm?ID=17318amp;Method=Full/abr gt;br gt;best,nbsp; paulbr gt;br gt;At 11:56 AM 9/16/00 -0400, you wrote:br gt; gt;Why can't cold fusion just automatically lockbr gt; gt;them? Has Allaire ever responded on this issue?br gt;br gt;--br br --br Archives: a href="http://www.mail-archive.com/cf-talk@houseoffusion.com/" eudora="autourl"http://www.mail-archive.com/cf-talk@houseoffusion.com//abr To Unsubscribe visit a href="http://www.houseoffusion.com/index.cfm?sidebar=listsamp;body=lists/cf_talk" eudora="autourl"http://www.houseoffusion.com/index.cfm?sidebar=listsamp;body=lists/cf_talk/a or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. /font/blockquotebr br -font size=3--br Peter Theobald, Chief Technology Officerbr LiquidStreaming a href="http://www.liquidstreaming.com/" eudora="autourl"http://www.liquidstreaming.com/abr [EMAIL PROTECTED]br Phone 1.212.545.1232 Fax 1.212.679.8032br /font/html -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: cflocking.. -- ATTENTION -- MY CASE STUDY
say, there is a cool regex example in Ben's "Advanced Cold Fusion (Green)" book dealing with ParamaterExists() Anyone want to build one for Locking? -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
IF all reads and writes of memory variables have to be locked, why do we have to be concerned with it? Why can't cold fusion just automatically lock them? Has Allaire ever responded on this issue? Maybe we could all email the request to allaire? I have thousands of templates that were written before this issue came into being, that don't have locks. That is probably the #1 reason for instability in my server:) Al Musella World Wide Websites At 03:12 PM 9/15/2000 -0400, you wrote: Yeah I thought it was agreed that all memory locking was suggested. Even in my presentation that I gave over a month ago I stated in there that there was disagreement but basically every memory variable whether written or read had to be locked. Ben Forta disagreed with that since his article had stated it was ok to not lock reads of memory variable(if he changed that I do not know), but as you can see with the performance test it was needed. Robert Everland III -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
Yes, they explained why. See Allaire's recent paper, "ColdFusion Locking Best Practices" http://www.allaire.com/handlers/index.cfm?ID=17318Method=Full best, paul At 11:56 AM 9/16/00 -0400, you wrote: Why can't cold fusion just automatically lock them? Has Allaire ever responded on this issue? -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
I read that paper, and still would like to have an option for automatic locking. Maybe add an attribute to the cfapplication tag: automatic locking: on |off The development time saved on it will more than offset the cost of a faster processor needed for the 2 or 3 microseconds added to each template that will be wasted:) And if you have a transaction problem or a performance problem, you can do it manually. The best of both worlds. I think this one issue is what made Turbobasic and quickbasic such a hit in the 80s and early 90s and VB now. You didn't have to worry about nit picky little things that could crash your program, but which would be easily automated. Developers were free to just worry about the logic. Do you agree with Allaire's reasoning? (By the way - I am a big fan of CF from way back in the 2.0 years.. Al Musella a1webs.com Yes, they explained why. See Allaire's recent paper, "ColdFusion Locking Best Practices" http://www.allaire.com/handlers/index.cfm?ID=17318Method=Full best, paul At 11:56 AM 9/16/00 -0400, you wrote: Why can't cold fusion just automatically lock them? Has Allaire ever responded on this issue? -- -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
html font size=3Oh. That may be true, but it is important to point out that that is wrong and won't work.br br At 01:16 PM 9/14/00 -0400, Mike Amburn wrote:br blockquote type=cite citei'd disagree... if you look back over all the emails in all of thebr threads, you should see that more people only lock writes versus lockingbr both. that consensus by the majority is what i was commenting too.br br -mikebr br gt; -Original Message-br gt; From: Peter Theobald [a href="mailto:[EMAIL PROTECTED]" eudora="autourl"mailto:[EMAIL PROTECTED]/a]br gt; Sent: Wednesday, September 13, 2000 8:30 PMbr gt; To: [EMAIL PROTECTED]br gt; Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDYbr gt; br gt; br gt; The consensus was *NEVER* that you didn't have to lock reads.br gt; Cold Fusion doesn't FORCE locking - it is up to you to lock br gt; access to an Application variable.br gt; If you lock the writes but don't lock the reads, then when br gt; Cold Fusion comes upon a read without a lock it will blindly br gt; run the read even if there is a (locked) write executing at br gt; the same time. In other words, locking writes without locking br gt; reads is completely useless.br gt; br gt; All an Exclusive lock does is mark the variable so that br gt; ANOTHER ATTEMPT TO LOCK IT will have to wait until the lock is freed. br gt; It is totally up to YOUR LOCKS to ensure the variable is not br gt; used by two threads at the same time.br gt; br gt; br gt; At 06:05 PM 9/13/00 -0400, Mike Amburn wrote:br gt; gt;i've been following the CFLOCK threads for months and months br gt; now. i evenbr gt; gt;started several. unfortunately, the problem is that there br gt; doesn't seembr gt; gt;to be any consensus on what's the end-all, be-all, br gt; definitive answer tobr gt; gt;the question quot;do you have to lock reads or just writes?quot; now i can'tbr gt; gt;speak for anyone else, however, i can tell you what we found br gt; during loadbr gt; gt;testing and you can do judge for yourself.br gt; gt;br gt; gt;recently, we hired Allaire to come in and load test (usingbr gt; gt;SilkPerformer) one of our main applications, which is incrediblybr gt; gt;database intensive and uses a lot of CFMODULES and br gt; application variablesbr gt; gt;(no client or session variables). before the test, the br gt; application ranbr gt; gt;perfect under normal load. however, as soon as we added simultaneousbr gt; gt;load (users requesting the same resources at the same exact time), webr gt; gt;immediately crashed with deadlocks in the database and applicationbr gt; gt;errors. again, runs perfect with all of our customers in br gt; production, butbr gt; gt;fails immediately under load.br gt; gt;br gt; gt;up until this point, our strategy had followed the majority br gt; consensus:br gt; gt;lock your writes, but not your reads. however, after 14 hours ofbr gt; gt;analyzing the problems of the load testing between Allaire and I, webr gt; gt;finally just enabled the auto-locking capabilities in CF br gt; Admin to see ifbr gt; gt;that did anything. (keep in mind, the Allaire rep had warned beforebr gt; gt;about locking reads) the result after enabling auto-lock? br gt; not a singlebr gt; gt;problem for the remainder of the engagement! that's right... br gt; no errors,br gt; gt;no deadlocks, nothing. it functioned under load BEAUTIFULLY with thebr gt; gt;auto-lock enabled until we finally got the numbers we wanted andbr gt; gt;finished the analysis.br gt; gt;br gt; gt;so again, i don't want to argue with anyone about their own strategy.br gt; gt;however, seeing it happen right in front of my eyes has me absolutelybr gt; gt;convinced WITHOUT A SHADOW OF A DOUBT that allaire is br gt; COMPLETELY correctbr gt; gt;when they suggest everyone lock BOTH application writes AND br gt; reads. andbr gt; gt;to tell you the truth, the performance hit for using the br gt; auto-lock seemsbr gt; gt;to be very minimal (at least on our application) so don't br gt; worry too muchbr gt; gt;about that if you don't want to go back and insert all the read-onlybr gt; gt;locks.br gt; gt;br gt; gt;so that's my two cents. hope it helps. =)br gt; gt;br gt; gt;-mikebr gt; gt;-br gt; -br gt; gt;Archives: a href="http://www.mail-archive.com/cf-talk@houseoffusion.com/" eudora="autourl"http://www.mail-archive.com/cf-talk@houseoffusion.com//abr gt; gt;To Unsubscribe visit br gt; a href="http://www.houseoffusion.com/index.cfm?sidebarstsamp;bodysts/cf_t" eudora="autourl"http://www.houseoffusion.com/index.cfm?sidebarstsamp;bodysts/cf_t/abr alk or send a message to [EMAIL PROTECTED] withbr 'unsubscribe' in the body. br br br br ---br Peter Theobald, Chief Technology Officerbr LiquidStreaming a href="http://www.liquidstreaming.com/" eudora="autourl"http://www.liquidstreaming.com/abr [EMAIL PROTECTED]br Phone 1.212.545.1232 Fax 1.212.679.8032br
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
The sad thing is this pretty much means that Allaire is admitting that the memory model in CF needs serious work. I'm paraphrasing of course ;) The way CF deals with memory in general is pretty weak. "Restart the service to release unused memory" is not my idea of an acceptable policy. As it's been explained to me by various people, including some Allaire folks, the memory model is also the source of the problems associated with not having an OnSessionTimeout or OnSessionEnd function/template. Basically, the server doesn't "know" when a session ends. It looks at the timeout parameter of each session and simply makes the ones that are past the current time inaccessible, or, I should say, refuses to read them. From what I've been told, the information still exists in memory until it is overwritten by new information. Has anyone tried using low-level diagnostics to see if they can access session information that has expired, i.e. test whether the information truly remains until overwritten? Don't anyone go writing a CFX that allows you to do this, if it's possible. That would be too cool and might make Allaire look bad ;) I'd like to differ slightly from your conclusion. In CF 4.5.x, the memory model changed so that CF would no longer release any memory that the service acquired. This actually was a change in the third-party memory manager, SmartHeap, used by CF. It doesn't matter whether the memory is consumed with session variables, cached queries, or whatever - CF simply won't release it. Whether the original information is still stored in memory or not doesn't really matter, as long as it's marked for deletion. The justification for this behavior is that CF is designed to be the "dominant" service on a box, and thus should be the only service consuming any serious resources - the typical NT deployment model of one service per machine. By holding on to acquired memory, CF can avoid the relatively significant costs involved in releasing and reacquiring memory. As long as the CF service can reuse the memory previously acquired, then there shouldn't be any problems. The real problem comes in when you have a component which causes a memory leak. For example, a while back I found that the Oracle client library in use on a specific server had a severe memory leak. Because of this, CF would continually consume more memory, even though it had already acquired enough to perform a repetition of previous activity. Eventually, the server would run out of memory and crash. However, if you have an environment without memory leaks, CF's behavior isn't necessarily unreliable or weak. It simply assumes that everything else (outside of CF) is in perfect working order. Personally, given the likelihood of memory problems in ODBC components and other things, I'd prefer that CF used the "release and reacquire" process as it did prior to 4.5.x. However, this isn't a "weak" memory model - it's simply a prioritization of performance over stability. Throughout the history of the CF product, Allaire has always favored performance over stability whenever the two may conflict. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
i'd disagree... if you look back over all the emails in all of the threads, you should see that more people only lock writes versus locking both. that consensus by the majority is what i was commenting too. You may see more emails here recommending the locking of writes only, but that's not a consensus. A consensus is not the same as a majority. If one faction disagrees violently, you don't have a consensus. In any case, the guys at Allaire, from the lead developer on down, have recommended locking all access to memory variables. They might have offered differing opinions on how to best do that, but they've all agreed that it should be done. I'm surprised that you're surprised at your outcome! Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
Yeah I thought it was agreed that all memory locking was suggested. Even in my presentation that I gave over a month ago I stated in there that there was disagreement but basically every memory variable whether written or read had to be locked. Ben Forta disagreed with that since his article had stated it was ok to not lock reads of memory variable(if he changed that I do not know), but as you can see with the performance test it was needed. Robert Everland III Web Developer Dixon Ticonderoga -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Friday, September 15, 2000 1:08 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY i'd disagree... if you look back over all the emails in all of the threads, you should see that more people only lock writes versus locking both. that consensus by the majority is what i was commenting too. You may see more emails here recommending the locking of writes only, but that's not a consensus. A consensus is not the same as a majority. If one faction disagrees violently, you don't have a consensus. In any case, the guys at Allaire, from the lead developer on down, have recommended locking all access to memory variables. They might have offered differing opinions on how to best do that, but they've all agreed that it should be done. I'm surprised that you're surprised at your outcome! Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
At 15:12 9/15/00 -0400, you wrote: Yeah I thought it was agreed that all memory locking was suggested. Even in my presentation that I gave over a month ago I stated in there that there was disagreement but basically every memory variable whether written or read had to be locked. Ben Forta disagreed with that since his article had stated it was ok to not lock reads of memory variable(if he changed that I do not know), but as you can see with the performance test it was needed. Yes but during that test were those variables being written to at the same time? I beleive that if you do a read without locking, and a write occurs or is occuring at the same time, you will have problems. But what if there is no writing? Say you setup a datasource name if its not defined. Then thats it, it will never be written to again until the server restarts and application variables are lost. In this situation can't you do reads without locking? Ryan -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
i'd disagree... if you look back over all the emails in all of the threads, you should see that more people only lock writes versus locking both. that consensus by the majority is what i was commenting too. -mike -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 13, 2000 8:30 PM To: [EMAIL PROTECTED] Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY The consensus was *NEVER* that you didn't have to lock reads. Cold Fusion doesn't FORCE locking - it is up to you to lock access to an Application variable. If you lock the writes but don't lock the reads, then when Cold Fusion comes upon a read without a lock it will blindly run the read even if there is a (locked) write executing at the same time. In other words, locking writes without locking reads is completely useless. All an Exclusive lock does is mark the variable so that ANOTHER ATTEMPT TO LOCK IT will have to wait until the lock is freed. It is totally up to YOUR LOCKS to ensure the variable is not used by two threads at the same time. At 06:05 PM 9/13/00 -0400, Mike Amburn wrote: i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors, no deadlocks, nothing. it functioned under load BEAUTIFULLY with the auto-lock enabled until we finally got the numbers we wanted and finished the analysis. so again, i don't want to argue with anyone about their own strategy. however, seeing it happen right in front of my eyes has me absolutely convinced WITHOUT A SHADOW OF A DOUBT that allaire is COMPLETELY correct when they suggest everyone lock BOTH application writes AND reads. and to tell you the truth, the performance hit for using the auto-lock seems to be very minimal (at least on our application) so don't worry too much about that if you don't want to go back and insert all the read-only locks. so that's my two cents. hope it helps. =) -mike - - Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarstsbodysts/cf_t alk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 Fax 1.212.679.8032 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarRstsbodyRsts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors, no deadlocks, nothing. it functioned under load BEAUTIFULLY with the auto-lock enabled until we finally got the numbers we wanted and finished the analysis. so again, i don't want to argue with anyone about their own strategy. however, seeing it happen right in front of my eyes has me absolutely convinced WITHOUT A SHADOW OF A DOUBT that allaire is COMPLETELY correct when they suggest everyone lock BOTH application writes AND reads. and to tell you the truth, the performance hit for using the auto-lock seems to be very minimal (at least on our application) so don't worry too much about that if you don't want to go back and insert all the read-only locks. so that's my two cents. hope it helps. =) -mike -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarRstsbodyRsts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: cflocking.. -- ATTENTION -- MY CASE STUDY
To add to Mike's message, I submitted an article on the Defusion site which covers fairly extensively how to do this (which scenarios, other options, etc, along with links to other resources, including many that were referenced in creating the article. It is basically a distillation of my personal experiences, along with references from other info I have). The title of the article (stealing a page from Ben Forta's titling strategy) is called "To lock, or not to lock". Let me know if there are any errors that any of you find in the article so I can correct them if need be. HTH, John Cummings - Original Message - From: "Mike Amburn" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 13, 2000 6:05 PM Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors, no deadlocks, nothing. it functioned under load BEAUTIFULLY with the auto-lock enabled until we finally got the numbers we wanted and finished the analysis. so again, i don't want to argue with anyone about their own strategy. however, seeing it happen right in front of my eyes has me absolutely convinced WITHOUT A SHADOW OF A DOUBT that allaire is COMPLETELY correct when they suggest everyone lock BOTH application writes AND reads. and to tell you the truth, the performance hit for using the auto-lock seems to be very minimal (at least on our application) so don't worry too much about that if you don't want to go back and insert all the read-only locks. so that's my two cents. hope it helps. =) -mike -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=stsbody=sts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
The sad thing is this pretty much means that Allaire is admitting that the memory model in CF needs serious work. I'm paraphrasing of course ;) The way CF deals with memory in general is pretty weak. "Restart the service to release unused memory" is not my idea of an acceptable policy. As it's been explained to me by various people, including some Allaire folks, the memory model is also the source of the problems associated with not having an OnSessionTimeout or OnSessionEnd function/template. Basically, the server doesn't "know" when a session ends. It looks at the timeout parameter of each session and simply makes the ones that are past the current time inaccessible, or, I should say, refuses to read them. From what I've been told, the information still exists in memory until it is overwritten by new information. Has anyone tried using low-level diagnostics to see if they can access session information that has expired, i.e. test whether the information truly remains until overwritten? Don't anyone go writing a CFX that allows you to do this, if it's possible. That would be too cool and might make Allaire look bad ;) Steve p.s. Here's the definition of "memory leak" from a book on C programming that I have ... "A bug in a program that prevents it from freeing up memory that it no longer needs. As a result, the program grabs more and more memory until it finally crashes because there is no more memory left." Sounds like a CF Server that isn't restarted on a nightly basis ;) -Original Message- From: Mike Amburn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 13, 2000 6:06 PM To: [EMAIL PROTECTED] Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors, no deadlocks, nothing. it functioned under load BEAUTIFULLY with the auto-lock enabled until we finally got the numbers we wanted and finished the analysis. so again, i don't want to argue with anyone about their own strategy. however, seeing it happen right in front of my eyes has me absolutely convinced WITHOUT A SHADOW OF A DOUBT that allaire is COMPLETELY correct when they suggest everyone lock BOTH application writes AND reads. and to tell you the truth, the performance hit for using the auto-lock seems to be very minimal (at least on our application) so don't worry too much about that if you don't want to go back and insert all the read-only locks. so that's my two cents. hope it helps. =) -mike -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=stsbody=sts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: cflocking.. -- ATTENTION -- MY CASE STUDY
Steve, Cold Fusion itself gets what ammounts to a bad wrap for it's memory usage. Before you consider it problematic, remember that it depends on a lot of other factors to manage memory correctly. First of all, if you have a dedicated CF server, CF is written to store more of itself in RAM over time to improve performance. This is what you want if you have a dedicated box. Secondly, applications that have infinite memory growth do actually usually plateau at some point, it is just that most people freak out and force a reboot before that plateau is acheived. Third, and most importantly, since CF is an application server, it depends on a lot of other things to work properly. It needs a properly functioning DB driver, your server needs to be configured correctly (i.e. enough swap space, IIS tweaks and CF tweaks in place, the application itself needs to be written (and locked) properly, and all third party stuff (CFX, etc.) needs to be examined for functionality. I have seen a lot of CF memory problems turn out to be completely unrelated to CF. A lot of the time, it is due to something else that is overlooked because it is simpiler, and in the short run only, easier to blame CF. That's not to say that there can't be memory handling issues with CF, but if you are having a memory issue, I would recommend a thorough read through http://www.allaire.com/Handlers/index.cfm?ID=15014Method=Full to make sure you have examined the problem from all angles. Just my two cents. HTH, John Cummings - Original Message - From: "Steve Bernard" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 13, 2000 6:41 PM Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY The sad thing is this pretty much means that Allaire is admitting that the memory model in CF needs serious work. I'm paraphrasing of course ;) The way CF deals with memory in general is pretty weak. "Restart the service to release unused memory" is not my idea of an acceptable policy. As it's been explained to me by various people, including some Allaire folks, the memory model is also the source of the problems associated with not having an OnSessionTimeout or OnSessionEnd function/template. Basically, the server doesn't "know" when a session ends. It looks at the timeout parameter of each session and simply makes the ones that are past the current time inaccessible, or, I should say, refuses to read them. From what I've been told, the information still exists in memory until it is overwritten by new information. Has anyone tried using low-level diagnostics to see if they can access session information that has expired, i.e. test whether the information truly remains until overwritten? Don't anyone go writing a CFX that allows you to do this, if it's possible. That would be too cool and might make Allaire look bad ;) Steve p.s. Here's the definition of "memory leak" from a book on C programming that I have ... "A bug in a program that prevents it from freeing up memory that it no longer needs. As a result, the program grabs more and more memory until it finally crashes because there is no more memory left." Sounds like a CF Server that isn't restarted on a nightly basis ;) -Original Message- From: Mike Amburn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 13, 2000 6:06 PM To: [EMAIL PROTECTED] Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors,
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
You had problems reading without locking, BUT, were you possibly writing to those variables at the same time? I was at a CF seminar and the speaker said you do not need to lock application variables IF YOU KNOW they will not be written to during the read. Maybe its a datasource name thats only written to once when its found not to be defined or something. Do you think this would be OK? Ryan -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
I understand everything that you pointed out, and agree with it. I have done a good deal of performance analysis and optimization of CF, I was actually offered a position as an Allaire Consultant, the guys who do that for a living. Anyway, the point is, I understand why it was done like it is, and that there are numerous factors involved, and ways to work around them but, when you really get down to it, should you have to "work around" the memory model? You have to agree that OnSessionTimeout and OnSessionEnd would be kickass additions. The memory leak quote was added because I find it funny that the definition applies to the way CF will sometimes act. I have been at this for going on 6 years now so I've learned to accept some things but, that doesn't stop me from wanting to raise the point every now-and-again. I appreciate your points though, and hope that others will take your and my comments together to reach their own conclusions. Steve -Original Message- From: John Cummings [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 13, 2000 7:06 PM To: [EMAIL PROTECTED] Subject: Re: cflocking.. -- ATTENTION -- MY CASE STUDY Steve, Cold Fusion itself gets what ammounts to a bad wrap for it's memory usage. Before you consider it problematic, remember that it depends on a lot of other factors to manage memory correctly. First of all, if you have a dedicated CF server, CF is written to store more of itself in RAM over time to improve performance. This is what you want if you have a dedicated box. Secondly, applications that have infinite memory growth do actually usually plateau at some point, it is just that most people freak out and force a reboot before that plateau is acheived. Third, and most importantly, since CF is an application server, it depends on a lot of other things to work properly. It needs a properly functioning DB driver, your server needs to be configured correctly (i.e. enough swap space, IIS tweaks and CF tweaks in place, the application itself needs to be written (and locked) properly, and all third party stuff (CFX, etc.) needs to be examined for functionality. I have seen a lot of CF memory problems turn out to be completely unrelated to CF. A lot of the time, it is due to something else that is overlooked because it is simpiler, and in the short run only, easier to blame CF. That's not to say that there can't be memory handling issues with CF, but if you are having a memory issue, I would recommend a thorough read through http://www.allaire.com/Handlers/index.cfm?ID=15014Method=Full to make sure you have examined the problem from all angles. Just my two cents. HTH, John Cummings - Original Message - From: "Steve Bernard" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 13, 2000 6:41 PM Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY The sad thing is this pretty much means that Allaire is admitting that the memory model in CF needs serious work. I'm paraphrasing of course ;) The way CF deals with memory in general is pretty weak. "Restart the service to release unused memory" is not my idea of an acceptable policy. As it's been explained to me by various people, including some Allaire folks, the memory model is also the source of the problems associated with not having an OnSessionTimeout or OnSessionEnd function/template. Basically, the server doesn't "know" when a session ends. It looks at the timeout parameter of each session and simply makes the ones that are past the current time inaccessible, or, I should say, refuses to read them. From what I've been told, the information still exists in memory until it is overwritten by new information. Has anyone tried using low-level diagnostics to see if they can access session information that has expired, i.e. test whether the information truly remains until overwritten? Don't anyone go writing a CFX that allows you to do this, if it's possible. That would be too cool and might make Allaire look bad ;) Steve p.s. Here's the definition of "memory leak" from a book on C programming that I have ... "A bug in a program that prevents it from freeing up memory that it no longer needs. As a result, the program grabs more and more memory until it finally crashes because there is no more memory left." Sounds like a CF Server that isn't restarted on a nightly basis ;) -Original Message- From: Mike Amburn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 13, 2000 6:06 PM To: [EMAIL PROTECTED] Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell yo
RE: cflocking.. -- ATTENTION -- MY CASE STUDY
The consensus was *NEVER* that you didn't have to lock reads. Cold Fusion doesn't FORCE locking - it is up to you to lock access to an Application variable. If you lock the writes but don't lock the reads, then when Cold Fusion comes upon a read without a lock it will blindly run the read even if there is a (locked) write executing at the same time. In other words, locking writes without locking reads is completely useless. All an Exclusive lock does is mark the variable so that ANOTHER ATTEMPT TO LOCK IT will have to wait until the lock is freed. It is totally up to YOUR LOCKS to ensure the variable is not used by two threads at the same time. At 06:05 PM 9/13/00 -0400, Mike Amburn wrote: i've been following the CFLOCK threads for months and months now. i even started several. unfortunately, the problem is that there doesn't seem to be any consensus on what's the end-all, be-all, definitive answer to the question "do you have to lock reads or just writes?" now i can't speak for anyone else, however, i can tell you what we found during load testing and you can do judge for yourself. recently, we hired Allaire to come in and load test (using SilkPerformer) one of our main applications, which is incredibly database intensive and uses a lot of CFMODULES and application variables (no client or session variables). before the test, the application ran perfect under normal load. however, as soon as we added simultaneous load (users requesting the same resources at the same exact time), we immediately crashed with deadlocks in the database and application errors. again, runs perfect with all of our customers in production, but fails immediately under load. up until this point, our strategy had followed the majority consensus: lock your writes, but not your reads. however, after 14 hours of analyzing the problems of the load testing between Allaire and I, we finally just enabled the auto-locking capabilities in CF Admin to see if that did anything. (keep in mind, the Allaire rep had warned before about locking reads) the result after enabling auto-lock? not a single problem for the remainder of the engagement! that's right... no errors, no deadlocks, nothing. it functioned under load BEAUTIFULLY with the auto-lock enabled until we finally got the numbers we wanted and finished the analysis. so again, i don't want to argue with anyone about their own strategy. however, seeing it happen right in front of my eyes has me absolutely convinced WITHOUT A SHADOW OF A DOUBT that allaire is COMPLETELY correct when they suggest everyone lock BOTH application writes AND reads. and to tell you the truth, the performance hit for using the auto-lock seems to be very minimal (at least on our application) so don't worry too much about that if you don't want to go back and insert all the read-only locks. so that's my two cents. hope it helps. =) -mike -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarstsbodysts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 Fax 1.212.679.8032 -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
