Alright, I apologize again, I guess the concept is a little convoluted,
but you'll have to have a little open mind, I think it works...
You will have to add another "render cycle". Currently there are two
render cycles, Rewind and Render. Essentially a render cycle walks
through the component tree allowing each component to do what needs to
be done during that cycle. Currently there is:
1) rewind
- have component tree absorb form parameters
2) render
- render html from component tree
What we'll have to do is to add a cacheInfo cycle:
1) rewind
- have component tree absorb form parameters
2) cacheInfo
- get cacheInfo from component tree
3) render (unless cacheInfo says we don't need to)
- render html from component tree
During the cacheInfo cycle we would simply interrogate each component to
give us its cacheInfo. A Component could then:
- not set any cacheInfo
- stating that it defers to child components
- set equivalent to do-not-cache ( expires=0, lastmod=0, etc )
- this means that it's not cacheable
- set appropriate lastmod/expires info
- this of course depends on application logic....
- something to remember is that at the lowest level is the .html file
- so that would use the lastmod of the file itself
The framework would then just have to collect and aggregate this
information in some predictable way ( greatest lastmod, smallest expires
).. and voila.. we have lastmod/expires information for any part of the
component tree.. Then the framework could return a NOT_MODIFIED if the
lastmod matches, etc.... We could then put a HTTP-Cache in front of our
servlet somehow.
Of course the benefits are:
- faster response
- higher throughput
- less CPU ( web, db )
- less bandwidth ( to a slow client could mean alot! )
but:
- lastmod must be less expensive/faster than a full render.
- pages must not change too much..
And if you don't want the functionality, because it doesn't have the
desired ROI, then just turn off cacheInfo cycle.
[EMAIL PROTECTED] wrote:
I've also read Fernando's previous email and it looks like a very
interesting idea.
However, i see a few problems:
- you can't tell which sub-components will render until you
actually render their containing component. So, if this must happen,
what exactly are the gains? Are you interested in network traffic,
server load, or both?
- How exactly will people implement lastmodified/expires at the
component level? It seems it will always depend on the context on
which each component is used and so it cannot be implemented at
that level.
The way i see it, this would have to be addressed at the page level,
meaning that the user will have to implement all the
lastmodified-expires logic on his own. But it still is a step forward.
From Fernando Padilla <[EMAIL PROTECTED]>:
true.
that is why the framework can't be smart enough to do this by it self.
I apologize, in this email I was refering to an earlier email that I
sent out a while ago..
In that email I was asking for framework support for
lastmodified/expires throughout the component tree. So that people
could implement lastmodified/expires at the component level, and the
framework would simply aggregate this information and could tell you the
lastmodified/expires for a whole page, or simply a portion of the
component tree.
That way if I implement a component of some complexity I could scope the
lastmodified/expires logic where it should live ( on that component ),
and have it instantly integrated wherever page or super component it
might be used.
So with "proper" support for lastmodified/expires from the framework,
every page from tapestry could work appropriately with any standard HTTP
cache mechanism. So with some work you can increase the scalability of
your tapestry application, within the component-based framework, not
through any hacks.
Currently I have to implement the lastmodified/expires logic as a filter
ontop of Tapestry that looks for particular urls...
fernando
By the way, we put squid in front of our servers and we have a cache hit
of about 80%. And with some of the client-side-include work that I'll
be integrating, we will get even more!
Howard Lewis Ship wrote:
What is "properly"? That is, when a page is constructed by pulling
data out of some large collection of database entities and stateful
server-side properties, any of which may have changed between
timepoint A and timepoint B, how do you effectively and efficiently
determine that something is "out of date" at timepoint B? It is not a
trivial problem to solve, it may be THE problem in server side web
development.
On 4/26/06, Fernando Padilla <[EMAIL PROTECTED]> wrote:
I can't resist commenting on your "cache" feature :) :)
just support lastModified and expires properly! :) then you can simply
put Squid in front of your server, or we can develop a basic
SquidFilter. :) :)
Brian K. Wallace wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
speed before 5 hits. (feed the masses and all that :-))
In speaking of performance... (I'm off in dream land here, I know... but
I like it there sometimes)
Many moons ago, there was talk of a 'tool' /'utility' that would
basically spider a Tapestry app and get all the generated HTML resulting
in basically a statically generated site. This helps tremendously when
you're running behind a web server that's tuned to serve static content
- - it's what they do and they do it pretty well with no overhead past
itself (meaning no java, no db, etc). I'd like to see if we can't add
some sort of 'cache' attribute to the HTML (somewhere) that would allow
Tapestry to perform this type of "wait, it says to cache it - i've
already generated it, I'll just grab that and use it" processing. This
would also allow Tapestry to build on first access but write out the
generated HTML so the next time a request comes in for it, the web
server would find it first (outside the mapping for Tapestry). Granted
this would only work for pages that were "cache=true" and had no dynamic
components inside it, but for a lot of sites that's enough (especially
outside a 'user' area). If there's a static form, submitting it would
pass back to Tapestry for processing.
I'd see this as only improving performance if you run Tapestry behind
something like Apache. Granted, you'd get a lot of "that's not fair -
you're not comparing our framework to yours if you don't hit your
framework more than once when we have to hit ours every time"
comments... but hey ;-)
My .02
Brian
Howard Lewis Ship wrote:
The basic AOP infrastructure is coming along. I expect the rest to
ramp up pretty quickly once I get that in place, but we're still
talking months. Maybe a useable beta by year's end.
I think I predicted a big performance boost for Tapestry 4 apps vs.
equivalent Tapestry 3 apps. I believe the difference between 4 and 5
will be greater. In fact, I expect OGNL support to be an add on, and
the built-in code will be an improved version of tapestry-prop (from
Tapestry @ JavaForge). I want Tapestry to be extremely high
performance, as one of its differentiators from JSF and Rails.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
stsYXpMZrbap+Q7Jxn+Lh0k=
=xbzo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
