Browser Issue

[d]

Re: Browser Issue

"Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
news:pan.2006.0 4.13.15.33.42.6 97799@andyjeffr ies.co.uk...[color=blue]
> On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:[color=green]
>> It is much more efficient to let the webserver deliver images directly,
>> and as I see it, there is no _good_ reason not to go that route.[/color]
>
> What about situations where there are multiple front-end web servers
> connecting to multiple database servers.
>
> You don't really want to allow users to upload images (profiles, forums,
> etc) in to a folder on one of the machines (whichever one of the farm they
> happen to connect to for the upload process) and then have to sync between
> every server to every other server every few minutes.
>
> Of course, shared storage (NFS etc) is another way of getting the same
> goal, but multiple DBs may be more fault tolerant.[/color]

Shared storage is the answer in that situation - storing images in a
database has such a massive overhead, not to mention cumbersome file access.
It might be easier from the coder's point-of-view, but that doesn't mean
squat to a project :)
[color=blue]
> Cheers,
>
>
> Andy
>
> --
> Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
> http://www.gphpedit.org | PHP editor for Gnome 2
> http://www.andyjeffries.co.uk | Personal site and photos
>[/color]

[Jerry Stuckle]

Re: Browser Issue

d wrote:[color=blue]
> "Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
> news:pan.2006.0 4.13.15.33.42.6 97799@andyjeffr ies.co.uk...
>[color=green]
>>On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
>>[color=darkred]
>>>It is much more efficient to let the webserver deliver images directly,
>>>and as I see it, there is no _good_ reason not to go that route.[/color]
>>
>>What about situations where there are multiple front-end web servers
>>connecting to multiple database servers.
>>
>>You don't really want to allow users to upload images (profiles, forums,
>>etc) in to a folder on one of the machines (whichever one of the farm they
>>happen to connect to for the upload process) and then have to sync between
>>every server to every other server every few minutes.
>>
>>Of course, shared storage (NFS etc) is another way of getting the same
>>goal, but multiple DBs may be more fault tolerant.[/color]
>
>
> Shared storage is the answer in that situation - storing images in a
> database has such a massive overhead, not to mention cumbersome file access.
> It might be easier from the coder's point-of-view, but that doesn't mean
> squat to a project :)
>
>[color=green]
>>Cheers,
>>
>>
>>Andy
>>
>>--
>>Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
>>http://www.gphpedit.org | PHP editor for Gnome 2
>>http://www.andyjeffries.co.uk | Personal site and photos
>>[/color]
>
>
>[/color]

I disagree here. Storing images in the database does not have to be "massive
overhead". If they are in their own table (with just id and image, for
instance), there is no overhead when accessing other information. As for
accessing the image itself, when the table is indexed the database can go
straight to the data block containing the start of the image and read from
there. Overhead is not significantly different than what the OS has to do in
searching a directory to get to the file.

Sure, it's a little more overhead. But not that much. And sharing disks or
directories (I assume you mean that vs. memory - which only works on a single
server) can be problematic, also. For instance - storing images with the
equivalent of an autoincrement field. The server has to get a directory
listing, find the next unused number and write the file. No problem here - but
what if two servers want to do it at the same time? Whichever one goes second
will have to detect the file already exists on open, and get a new directory
listing. A database will handle these situations.

All in all, if you don't use a database you're just moving the required code to
the program instead of letting the database handle it.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[d]

Re: Browser Issue

"Jerry Stuckle" <jstucklex@attg lobal.net> wrote in message
news:pYmdnV2izO jfAqPZnZ2dnUVZ_ uWdnZ2d@comcast .com...[color=blue]
>d wrote:[color=green]
>> "Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
>> news:pan.2006.0 4.13.15.33.42.6 97799@andyjeffr ies.co.uk...
>>[color=darkred]
>>>On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
>>>
>>>>It is much more efficient to let the webserver deliver images directly,
>>>>and as I see it, there is no _good_ reason not to go that route.
>>>
>>>What about situations where there are multiple front-end web servers
>>>connecting to multiple database servers.
>>>
>>>You don't really want to allow users to upload images (profiles, forums,
>>>etc) in to a folder on one of the machines (whichever one of the farm
>>>they
>>>happen to connect to for the upload process) and then have to sync
>>>between
>>>every server to every other server every few minutes.
>>>
>>>Of course, shared storage (NFS etc) is another way of getting the same
>>>goal, but multiple DBs may be more fault tolerant.[/color]
>>
>>
>> Shared storage is the answer in that situation - storing images in a
>> database has such a massive overhead, not to mention cumbersome file
>> access. It might be easier from the coder's point-of-view, but that
>> doesn't mean squat to a project :)
>>
>>[color=darkred]
>>>Cheers,
>>>
>>>
>>>Andy
>>>
>>>--
>>>Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
>>>http://www.gphpedit.org | PHP editor for Gnome 2
>>>http://www.andyjeffries.co.uk | Personal site and photos
>>>[/color]
>>
>>
>>[/color]
>
> I disagree here. Storing images in the database does not have to be
> "massive overhead". If they are in their own table (with just id and
> image, for instance), there is no overhead when accessing other
> information. As for accessing the image itself, when the table is indexed
> the database can go straight to the data block containing the start of the
> image and read from there. Overhead is not significantly different than
> what the OS has to do in searching a directory to get to the file.
>
> Sure, it's a little more overhead. But not that much. And sharing disks
> or directories (I assume you mean that vs. memory - which only works on a
> single server) can be problematic, also. For instance - storing images
> with the equivalent of an autoincrement field. The server has to get a
> directory listing, find the next unused number and write the file. No
> problem here - but what if two servers want to do it at the same time?
> Whichever one goes second will have to detect the file already exists on
> open, and get a new directory listing. A database will handle these
> situations.
>
> All in all, if you don't use a database you're just moving the required
> code to the program instead of letting the database handle it.[/color]

I'd put it that you're moving the work to a different database - the
filesystem, which is built for exactly this kind of thing :)
[color=blue]
> --
> =============== ===
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstucklex@attgl obal.net
> =============== ===[/color]

[no-1]

Re: Browser Issue

if you use an OpenVMS cluster as your web-server farm - this is a moot
problem as they natively share - concurrently - the disk devices.

[Jerry Stuckle]

Re: Browser Issue

d wrote:[color=blue]
> "Jerry Stuckle" <jstucklex@attg lobal.net> wrote in message
> news:pYmdnV2izO jfAqPZnZ2dnUVZ_ uWdnZ2d@comcast .com...
>[color=green]
>>d wrote:
>>[color=darkred]
>>>"Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
>>>news:pan.200 6.04.13.15.33.4 2.697799@andyje ffries.co.uk...
>>>
>>>
>>>>On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
>>>>
>>>>
>>>>>It is much more efficient to let the webserver deliver images directly,
>>>>>and as I see it, there is no _good_ reason not to go that route.
>>>>
>>>>What about situations where there are multiple front-end web servers
>>>>connectin g to multiple database servers.
>>>>
>>>>You don't really want to allow users to upload images (profiles, forums,
>>>>etc) in to a folder on one of the machines (whichever one of the farm
>>>>they
>>>>happen to connect to for the upload process) and then have to sync
>>>>between
>>>>every server to every other server every few minutes.
>>>>
>>>>Of course, shared storage (NFS etc) is another way of getting the same
>>>>goal, but multiple DBs may be more fault tolerant.
>>>
>>>
>>>Shared storage is the answer in that situation - storing images in a
>>>database has such a massive overhead, not to mention cumbersome file
>>>access. It might be easier from the coder's point-of-view, but that
>>>doesn't mean squat to a project :)
>>>
>>>
>>>
>>>>Cheers,
>>>>
>>>>
>>>>Andy
>>>>
>>>>--
>>>>Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
>>>>http://www.gphpedit.org | PHP editor for Gnome 2
>>>>http://www.andyjeffries.co.uk | Personal site and photos
>>>>
>>>
>>>
>>>[/color]
>>I disagree here. Storing images in the database does not have to be
>>"massive overhead". If they are in their own table (with just id and
>>image, for instance), there is no overhead when accessing other
>>information . As for accessing the image itself, when the table is indexed
>>the database can go straight to the data block containing the start of the
>>image and read from there. Overhead is not significantly different than
>>what the OS has to do in searching a directory to get to the file.
>>
>>Sure, it's a little more overhead. But not that much. And sharing disks
>>or directories (I assume you mean that vs. memory - which only works on a
>>single server) can be problematic, also. For instance - storing images
>>with the equivalent of an autoincrement field. The server has to get a
>>directory listing, find the next unused number and write the file. No
>>problem here - but what if two servers want to do it at the same time?
>>Whichever one goes second will have to detect the file already exists on
>>open, and get a new directory listing. A database will handle these
>>situations.
>>
>>All in all, if you don't use a database you're just moving the required
>>code to the program instead of letting the database handle it.[/color]
>
>
> I'd put it that you're moving the work to a different database - the
> filesystem, which is built for exactly this kind of thing :)
>
>[color=green]
>>--
>>============= =====
>>Remove the "x" from my email address
>>Jerry Stuckle
>>JDS Computer Training Corp.
>>jstucklex@att global.net
>>============= =====[/color]
>
>
>[/color]

Yep, I'm moving the work to a different database - the RDB, which is built for
exactly this kind of thing!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===