cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <mi...@pcextremist.com>
Subject A lurker's RT -- proactive cache
Date Sun, 25 Aug 2002 19:22:56 GMT
First, some background: The server's a RedHat box running Cocoon w/ 
Tomcat and TUX in front.  TUX is a kernel-level, simple web server 
(basically static content) that shoots pages out of the system page 
cache at alarming speeds, with appropriate hardware copies data directly 
to network interface buffers rather than to main memory first, and if it 
can't serve the request, passes control of the socket to userland -- in 
my case, Tomcat/Cocoon on port 8080.  This also has the advantage of 
allowing Tomcat and the JVM to run as "nobody" since TUX can listen on 
80 and pass on to non-privaledged ports above 1024.  But I digress...

The initial purpose of this setup was to allow Tomcat/Cocoon the 
handling of dynamic data and TUX to handle static content -- their 
respective strong suits.  To put it in perspective, TUX can not only 
saturate a 100baseT link on meager Pentiums but has extraordinally low 
CPU and memory usage.  The less CPU/mem being used for static content, 
the more Tomcat/Cocoon has for the dynamic stuff.  This is the crux of 
my current mindset.  As I was working, I found myself wishing that they 
could have their caches combined -- or rather that TUX could have access 
to Tomcat/Cocoon's dynamic data cache.  This was dismissed as a pipe 
dream very quickly; native (kernel!) code tinkering around in a userland 
JVM instance shouldn't be considered a well-considered design.

But then I thought, "Why not have Cocoon's cache output files to a 
directory path that TUX can later serve?"  However, this ran into the 
problem of cache expiration.  If Cocoon's cache (from now on I'll refer 
to as a "reactive cache") were to output as a standard, serialized file 
for TUX to serve, TUX would indeed serve it, but it would no longer 
allow any requests to come into Tomcat/Cocoon.  Thus the reactive 
cache's entried would never be accessed again and would never expire its 
cache.  Thus stale data would forever more be served.

So would there be a way to allow Cocoon to expire cache entries 
immediately when prerequisite files were altered, database tables 
updated, etc.?  Not from within Java itself, no.  Not without excessive 
polling of the filesystem and other data stores.  This would so 
adversely affect the performance of the system so as to make any gains 
moot.  So what about opening up that Pandora's box which contains such 
items as "JNI code in Cocoon."

...I'll wait for the geering, insults, and epithets to die down...

Taken with the SGI library fam (File Alteration Monitor) for example, it 
would be possible to expire a cache entry as soon as a prerequisite was 
changed.  In the case of fam, the serialized file in the document tree 
would be deleted causing TUX to route the subsequent requests to 
userland to be generated again.  Obviously this would be horrible for 
absolutely dynamic data (for which any cache is merely a drain on the 
system), but would be a performance giant (in theory of course) when 
demonstrated against minimally dynamic content.  It would have all of 
the advantages of Cocoon CLI pre-generation while still allowing dynamic 
updates.

I would also think it would improve the speed of Cocoon caches even 
without TUX.  After all, the cache would never even have to check the 
filesystem.  It could just say, "My in-memory bit hasn't been flipped so 
I can assume that nothing has changed without any filesystem calls." 
 Think of the work done so that File.lastModified is called less often. 
 Wouldn't this simply be extending that thought to its logical conclusion?

Linux (2.4 kernel and higher), *BSD, Solaris, and IRIX all support fam. 
 I'm not certain about Solaris, but the others can use fam to interact 
with kernel inode monitors without any regular polling.  I seem to 
remember that Windows has a similar filesystem event callback system, 
but that may have been wishful thinking...  Anyone know for sure one way 
or the other?

Of course I saw the limitations of proposing a TUX-specific option. 
 After all, how many Cocooners out there have even given a second glance 
to TUX -- or even a first?  Aside from its use with Apache through some 
hacking sessions, this idea could also be used for Squid and other 
proxies.  Imagine having front-end proxies that simply serve content 
until they are explicitly told otherwise instead of having to constantly 
make checkup calls.

On the other end, instead of fam, the same might be used for databases 
as well.  For example, PostgreSQL could have a trigger function written 
that, when a dependent set of tables are changed, a cache expiration 
queue table could be populated with the affected entries and a linked C 
function (in the database) could fire off a "cache expired" message to 
the app server.  But of course, this requires that something like Cocoon 
have a socket listener or constantly open connection to its data input 
source.

 +----------+---------+  +------------+-----+
 | Database | DB data |  | Filesystem | fam |
 |          | minder  |  |            |     |
 |          +----+----+  |            +---+-+
 +----------+    |       +------------+   |
                 |                        |
                 +------------+-----------+
                              |
+-------------------+---------+------------+
|     Cocoon        | Cocoon Cache Manager |
|                   +-----+----------------+
|                   |     | Cache Exporter |
+-------------------+     +----+-----------+
                               |
                               |
                        +------+------+
                        |             |
          +-------------+--+       +--+-------------+
          |   Filesystem   |       | Network Socket |
          +----------------+       +-------+--------+
                                           |
             +---------+             +-----+-----+
             |   TUX   |             |   Squid   |
             +---------+             +-----------+


Anyway, something like that.  I hope my meager ASCII art skills can at 
least get across the basic premise.  What I think this entails includes 
(1) better knowledge of how the Cocoon cache current works than I have 
at this moment, (2) a cache event generation interface (implemented by a 
filesystem monitoring object that uses fam or similar technology or a 
custom database trigger and Cocoon-side socket listener), (3) a cache 
exporter interface (implemented by a filesystem serializer or 
Squid-cache--aware network component), and a heaping bowl of programming 
chutzpah.

Obviously my focus would be on getting TUX to work rather than on Squid 
as I use the former and not the latter.  What it really comes down to is 
that Squid is another box(es) to purchase and maintain and I am 
cheap/poor/bored (take your pick).  But I would just as soon make 
interfaces that weren't intimately tied to the filesystem and my 
specific goals (hence the discussion about Squid and databases).

Of course, if Sun added a filesystem callback interface to the I/O 
libraries, the native code wouldn't be necessary.  ;-)  Sure, not every 
OS supports it, but then not every platform supports threads either. 
 When not present, you emulate, right?

Any thoughts?  Am I absolutely off my rocker and in need of medication? 
 Is it something that you are already working on?  I've given my 
thoughts on advantages of a proactive cache.  What are the drawbacks to 
a proactive cache rather than a reactive one (other than simplicity and 
the fact that the reactive one is already there and works -- already got 
that)?

More info on fam: http://oss.sgi.com/projects/fam/faq.html
More info on TUX: http://www.redhat.com/docs/manuals/tux/TUX-2.2-Manual/


Thanks for your time,

Miles



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message