Fwd: Advice on dynamic graphics with WO
Fwd: Advice on dynamic graphics with WO
- Subject: Fwd: Advice on dynamic graphics with WO
- From: Karl Gretton <email@hidden>
- Date: Fri, 02 Jan 2004 12:00:56 -0500
Hi,
Happy New Year everyone / Bonne Annie tout le monde.
I agree that storing images in the database is the most effective way
of keeping synchronization with database information. In our content
management application, we store all images in the database and do
versioning and security. Currently, for images (and other binary
objects such as PDFs) which have 'Public Read' permissions, we provide
the option of having these published to the web server filesystem.
However, we may stop doing this since there is no measurable
performance advantage that we have been able to find. Even under heavy
loads, neither the app server nor the database represent a bottleneck.
We use our own custom resource manager to fetch BLOBs using raw SQL and
then to cache these using a singleton-based Cache Manager. This is
parameterized and allows us to limit the amount of RAM consumed by the
cache and also to establish a strategy such as keeping the most
frequently used objects or only objects < X Mbytes. This code is part
of our legacy application which was originally running under
SilverStream 3.5 It is interesting to note that SilverStream doesn't
use a conventional webserver and all and has always stored ALL data as
BLOBs in the database and achieved very good performance doing so.
We are looking at moving this to a more 'pure' WO approach using EOs.
I have a couple of questions while we are on the subject:
How does EO deal with managing the amount of memory consumed by large
EOs? Say we have 10,000 BLOBS of over 1Mbyte each, eventually our
server would run out of RAM/SWAP. Does EO have any automatic
management for this?
Our current thoughts were to use the current Cache Manager architecture
(singleton pattern management object) and to have it still manage the
caching but actually fetching true EOs from the database via a private
EC.
Does anyone have any thoughts on this?
Regards,
Karl
On Jan 2, 2004, at 8:57 AM, Michael Halliday wrote:
Hey Jonathan,
As stated in my previous message we are storing all dynamic images in
our database. For our "community" sites with photo albums I am using
the shared editing context to fetch any image objects that will be
available across all sessions. This way it can cache the images once
which saves on server memory. This is how we are setup:
Photo object which stores all the data about the object...ie. name,
description, size, image type, date added, etc.
PhotoData object which has a one-to-one relationship with the Photo
object and stores the actually binary data. The reason we have this
extra table is so that we can fetch and sort images based on name,
description etc., without having to actually fetch all the images at
the same time. Instead, the images are faulted and fetched when the
faults are fired.
Hope this helps. I find this approach to be very elegant for any
images which require some form of "security". It beats trying to
integrate your WebObjects App with filesystem level security.
Take care,
Michael.
--SNIP
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.