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/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=sts&body=sts/cf_talk or send
a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
