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=15014&Method=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,
> 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.
>
------------------------------------------------------------------------------
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.
