[jboss-dev] Further profling: Where should I focus?

[David M. Lloyd]

On 01/05/2010 02:56 PM, Bill Burke wrote:
>
>
> David M. Lloyd wrote:
>> Caching behavior depends on the filesystem.  For zip mounts, "isDirectory"
>> and "lastModified" don't even hit the filesystem (in most cases).  Don't
>> take JProfiler data as real-world timing; it's useful to find slow spots,
>> sometimes, but it's not an accurate reflection of what the real speed of
>> the thing is.
>>
>> For real filesystem stuff, you CAN NOT EVER do any form of caching of file
>> metainformation because the backing data is not owned by VFS, and thus can
>> change without any sort of notice.
>>
>
> You can and should cache everything and anything because the App Server
> doesn't need live VFS-based information because 90% of the time it is
> static with the other 10% happening on redeployment.

That's fine BUT a general-purpose caching system will just fuck things up 
again.  If you know the info won't change, then don't keep asking for it. 
There are many different ways in which VFS is used - mounting a library, 
for example, can be done with a plain zip mount (in other words, everything 
is in RAM), whereas mounting a hot deployment must first copy the JAR 
before mounting to avoid locking issues on windows and the "disappearing 
classes" problem which occurs when you delete the JAR out from under the 
classloader before the classloader is done with it.

Mounting an exploded hot deployment must be done with a more complex copy 
operation so that changes to dynamic content can be propagated using 
different rules based on the content (e.g. HTML files should be copied 
immediately, but the semantics of changing class files is less clear). 
What can we cache here?

The "ownership" semantics of static files are not clearly defined either, 
and can depend on what is being mounted and why.  I suspect you'll find 
that there are very few (if any) cases where the filesystem is being hit 
for information such as "isDirectory" or "lastModified" information outside 
of hot deployment, which is the case where it can't be cached anyway.

> As I stated early, define a parallel non-cache api that invalidates the
> cache on diffs for sensitive operations (like hot-deployment).

Sure, if you like bugs and broken behavior.  Correctness first, speed 
second.  This is a complex problem that you cannot paint with a broad 
brush.  You must look at each use case separately before you can say stuff 
like "we need caching".

- DML