[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mason
Subject:    RE: [Mason] "Slow Cache"
From:       Jonathan Swartz <swartz () transbay ! net>
Date:       2000-02-27 0:33:15
[Download RAW message or body]

Yes, I remember it well. :) There's a reason that we ran from database to 
filesystem components that has nothing to do with speed or CPU usage: 
developer convenience. Unless you've got some really slick database tools, 
you'll be hard pressed to match ls/cat/grep/find/emacs/vi/cvs... and the
hundreds of other tools that leverage a standard file system. We ended
up having to rewrite many of these for the database.

Thus one needs to consider carefully whether a small increase in speed 
and manageability is worth the decrease in developer productivity. As
cannot be stated enough, developers are more expensive than hardware.

I can see the desire to not keep things in per-process memory, but doesn't
NFS have a memory cache too?

Jon

At 03:00 PM 2/25/00 -0800, Chris Dobosz wrote:
>Interesting how things come full circle.  In Mason's early days components
>only existed in a database.
>
>Chris Dobosz
>
>-----Original Message-----
>From: mason-admin@netizen.com.au [mailto:mason-admin@netizen.com.au]On
>Behalf Of Jon Frisby
>Sent: Friday, February 25, 2000 2:50 PM
>To: mason@netizen.com.au
>Subject: [Mason] "Slow Cache"
>
>
>Memory consumption is a big issue for me...  Perhaps moreso than CPU usage,
>to an extent.
>
>Here's an idea: People have talked about putting components into a database,
>for manageability and centralization.  Why not take this concept and tweak
>it just a smidge:  Have a two-layered cache, the second layer of which is
>the database.
>
>Given a fast database such as MySQL, and a construct like heap-tables, this
>could be faster than filesystem lookups.  Components would exist in memory
>once for the database, and once during a request, after which time they are
>discarded.  Assuming that the size of your components combined is greater
>than you wish your per-process in-memory cache to be, this could provide a
>significant performance benefit versus being forced to continually grab
>components off of disk. (especially if they are on NFS and you don't happen
>to be running a Solaris server to a NetApp box...)
>
>Each web server could have it's own MySQL, thus allowing relatively linear
>scalability. (depending on the nature of your application)
>
>-JF
>MrJoy.com: Because coding is FUN!
>
>
>_______________________________________________
>Mason maillist  -  Mason@netizen.com.au
>http://netizen.com.au/mailman/listinfo/mason
>
>
>_______________________________________________
>Mason maillist  -  Mason@netizen.com.au
>http://netizen.com.au/mailman/listinfo/mason
> 


_______________________________________________
Mason maillist  -  Mason@netizen.com.au
http://netizen.com.au/mailman/listinfo/mason

[prev in list] [next in list] [prev in thread] [next in thread]