Actually that isn't the scenario at all on this... we are streaming
these files in flash so the faster we can get them to the user the
faster it will start playing. Each box in this cluster has 32 GB of
ram and these are small files. Also caching isn't an option because we
aren't using sticky sessions on the cluster....
I'll try the firebug thing.
On 11/22/06, Mischa Uppelschoten ext 10
<[EMAIL PROTECTED]> wrote:
I was just trying to take advantage of the vast ammount memory
on this box and avoiding the overhead of IO.
<$0.02> I would argue that if a user is going to wait 30 seconds or more to download
an mp3, it's not going to matter whether you spend two seconds to store the file on disk
first. However, with a user having the ability to open up multiple windows and multiple
users being able to hit your server, I would be concerned about every page request taking
up 5MB (or whatever the mp3 file size is) of RAM. Not even considering the fact that it
will be child's play to cache the request if it's a file, and much harder/expensive to do
when you keep it in memory. </$0.02>
/m
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?falogin.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
--
Steven Ross
web application & interface developer
http://www.zerium.com
[mobile] 404-488-4364
[fax] 928-484-4364
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
