Xing
Good points!
But, then, why doesn't it, also, make sense to use static html pages (processed and
cached by the web server) and avoid CF & SQL altogether.
A little bit of devil's advocate role playing here. I understand the
advantages/costs/tradeoffs of DDC (Database-generqated Dynamic Content) for
presentation of html pages.
I just think that the same may apply to non-text Content.
The difference I see is that:
text content is likely to change (correct spelling, format, format option
for printing, etc)
most non-text content probably won't change (other than be replaced by
different static content)
This may change in the future as we may want to programatically manipulate
non=text content before presentation.
An example might be to reduce the size/resolution (or other manipulation) of
an image or sound file before presentation... kind of a dynamic thumbnail.
There are programs such as ImageMagik which can do this for images, probably
something exists for
If there is a need to maintain a large repository of digital (non-text) content then a
database appears to offer some significant advantages for: accessing, cataloging,
security, referential integrity, backup...
Maybe the advantages of database will change the way non-text content is stored and
served.
How about a "specialty server" optimized for this purpose. This server would
efficiently access and cache large binary files. A request for content would go
directly to the "specialty Server", bypassing both Application Server and Web Servers.
The "Specialty Server" would receive the request, retrieve the requested content,
attach the appropriate headers/mime-type and serve the content, directly.
As the web evolves, we may need to change the way we think about non-text content...
... what, with applets, embeds, images,etc - what percentage of the typical page (at
the browser client) is actually text?
Apple's new OSX uses Quartz for presentation services... this mean that everything you
see on the screen is in PDF format. (See below).
Does this mean that we could serve PDF pages directly to a Mac Client and eliminate
all plug-ins browser overhead, extra OS Presentation overhead... probably!
Couldn't the same approach apply to images, audio, video... probably!
Just some questions/thoughts.
Sorry for rambling.
* Quartz. Based on the Internet-standard PDF (Portable Document Format), Quartz is a
power-ful
new 2D graphics system that delivers on-the-fly rendering, anti-aliasing, and
compositing of
PostScript-strength graphics with pristine quality. Thanks to Quartz, graphic elements
that were
sharp before are now dramatically sharper-even when their size is greatly increased.
Every-thing
graphics pros create in 2D will have stunning impact
.
Quartz features built-in support for PDF, enabling users to embed and manipulate PDF
data
with any optimized Mac OS X application. Users can also "print to PDF," giving them
the ability
to output any document as a PDF file. So you can easily create Quartz-enhanced,
graphics-rich
documents that can be shared with anyone. Since this capability is available to all
Mac OS X
applications, Macintosh developers now have a whole new palette of creative tools at
their
disposal.
At 9:55 AM -0700 9/15/00, Xing Li wrote:
> > Are you saying that if you take the broader perspective, that using a
>> db instead of files is the most efficient way to serve content, any
>> content?
>
>I don't believe db based solution is the way to go to server every type of
>content. In my case, this is true. The site pushes out text content in the
>averge range of 30KB per pop. Before, I used CF to read in files to a
>variable and the outputting that to the browser so basically I had CF as the
>bridge between the browser and file. So instead of having CF accessing the
>file system i/o directly I have asked CF to access the db instead. I do not
>have any performance numbers for you but the improvement is significant but
>this will only help you if you plan to do tons and tons of file reads.
>
>So basically the I have changes the previous path of :
>
>Browser << Web Server << ColdFusion << File System
>to
>Browser << Web Server << ColdFusion << Database
>
>If you are serving images then the fastest way to do it is stil lthe old
>fashioned way of :
>
>Browser << Web Server << File System
>
>All the new webservers are have their own caching mechanism you don't have
>the overhead of coldfusion,asp, or anyother tool pushing the content fromt
>he database to the webserver. In my experience, and since I have to do
>everything through ColdFusion, ColdFusion << SQL is more efficient than
>ColdFusion << File System in the long haul. However If you can skip
>coldfusion, skip it. No matter how fast your machine is, having the
>webserver caching large files is gotta to be faster than cf or sql
>caching/pushing out large files.
>
>Xing
>
>
>
>
>> If this logic is valid, wouldn't the same be true for serving images,
>> pdf files, sound files, etc?
>>
>> From an application design standpoint, it is a lot cleaner to store
>> everything in the db because:
>>
>> you get all the good things & discipline of a db
>>
>> you avoid all the problems screwing around with the OS's file system
>>
>> So, in an ideal world, all content would be in the database.
>>
>> For example, I have heard thgat storing images (or any blobs) in a db
>> will bring it to its knees.
>>
>> I have experimented a little with smaller images and not experienced
>> any problems other than CF 4.0's inability to manipulate binary data.
>> I use ASP to binary read an image, and store it in the db (never
>> storing/renaming/deleting anything in the file system). Then a small
>> ASP program is used to retrieve & serve the images when requested in
>> an <img> tag.
>>
>> Are you saying that if you take the broader perspective, that using a
>> db instead of files is the most efficient way to serve content, any
>> content?
>>
>> Stands to reason that saving/retrieving a few sectors in a db is a
>> lot more efficient than going through all the overhead of
> > allocating/opening a file, etc, then saving/retrieving a few sectors
> > in the file
> >
> > Hmmm... this is very important.
> >
> > Got any performance stats?
> >
> > I'll looked at the fanfiction site... interesting
>>
>> Dick
>>
>>
>>
>> At 2:17 AM +0000 9/21/09, Xing Li wrote:
>>> Steve Katz,
>>>
>>> You might want to check out www.fanfiction.net for pointers.
>>> Archiving/Publishing of stories from lesser known authors is exactly what we
>>> do there. The stories are uploaded by the user and the content, no matter
>>> how large, is stored into MS SQL 2000b2 database. You can save and serve the
>>> stories out of physical files but I have found out that it is much more
>>> efficient to serve them straight from the db. Reading straight from a file
>>> and pushing that file to the web is general faster than a db solution on a
>>> small scale. However, once you have tons of traffic and thus tons of file
>>> i/o calls, the cpu spikes like crazy and everything slows down. The
>>> database, although slower under low load, is much more optimized for heavy
>>> constant reads and not to mention a internal caching mechanism.
>>>
>>> Xing
>>>
>>> www.fanfiction.net
>>>
>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Steven Katz <[EMAIL PROTECTED]>
>>>> To: <[EMAIL PROTECTED]>
>>>> Sent: Thursday, September 14, 2000 4:00 PM
>>>> Subject: Upload and retrieval of stories?
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm developing a site that will feature short- to medium-length
>>>>> stories from lesser-known authors. I have designed a page that will
>>>>> serve as a template, into which I will insert the material contributed
>>>>> from the authors. I would rather that this process of inserting
>>>>> content not be a manual one. In fact, I would like the programmatic
>>>>> solution to include a web-based administrative interface. Normally,
>>>>> this might consist of some forms and CF or PHP, allowing the user to
>>>>> upload content to a database, where the material could then also be
>>>>> made available to the templates for the dynamic creation of pages.
>>>>> However, form fields seem to have a rather small character limit,
> >>>> preventing one from simply pasting an entire story into them. This
>>>>> isn't really what I want to do anyway. Has anyone devised a good
>>>>> process for accomplishing something similar? Perhaps there's no reason
>>>>> to store this material in a database, anyway? I'd be very interested
>>>>> to hear your suggestions.
>>>>>
>>>>> Thanks,
>>>>> Steven
>>>>>
>>>>> --------------------------------------------------------------------------
>>>> ----
>>>>> Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
>>>>> 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/cf-talk@houseoffusion.com/
>>>> 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/cf-talk@houseoffusion.com/
>>> To Unsubscribe visit
>>> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>>> k 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=lists&body=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=lists&body=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=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
