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.
As I stated early, define a parallel non-cache api that invalidates the
cache on diffs for sensitive operations (like hot-deployment).
Try the test again with a "warmed up" JVM and no profiler
agent installed
and you'll probably see a different story.
No different story here. JVM "warm up" has no effect. Still the VFS
taking 60% of the time.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com