cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: DO NOT REPLY [Bug 6879] - [PATCH] Cache improvement using ESI invalidation protocol
Date Wed, 24 Apr 2002 21:08:03 GMT
Marcelo,
a short answer.
I send the reply to the Cocoon dev. List. I think the
topic is very interesting and need to be discussed with
a broader publicum. 
Let's discuss the topic there!

<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6879>

>  I apologize for the delay on the reply.
>  First, I am not offended.

:-)

<skip/>

>http://otn.oracle.com/products/ias/web_cache/content.html
>  Here the anwser of your questions:
>    1) I can't understand this point.

The current Caching process is something like this:

Cachable request ---> CachingxxxPipeline ---> lookup Store ---> Validate Object

When I understand everything right you do something like
this:


                              Http Post Message
                                     |
                                    XSP
                                     |
                          External Cache Invalidator 
                                     |
                                     |
                        Some Invalidator Server Thread                             
                                     |
                                     |
                                     -
(Ignore current process ---->) Validate Object

So this is my current high level understandig of your approach.
_Please_ correct me, if I understand something wrong here. Draw a 
picture, that helps!

Ahem it's the "ignore current process" part, which I don't like ;-)...

Question: Why is it impossible for you to do it in the current Caching 
process?

>    2) In my test case the background Thread do not impact in the 
>performance of Cocoon, that is, enabling or not the server through 
>cocoon.xconf file the average response time of cocoon components is the 
>same. One alternative is to leave the entry in cocoon.xconf commented 
>and the user that need the behaviour uncomment it.

Note: you're not the only thread in Cocoon. Every Thread has an direct impact 
on the Performance. Multithreading is very complex and I made the expierence
in Cocoon to implement Threads only when it is neccassary and for a
generic use (see Berins proposals about event queues...)

>    3) The logon in the invalidator xsp page uses standard http/https 
>protocol and is a regular XSP page, that is, the security warkaround 
>here is equal to any other xsp page. As an aditional security feature 
>its possible to check the IP number of the sender. (Username/password 
>and ip checking is the standard security filters implemented by Oracle 
>Web Cache and I don't know any security problem with this comercial 
>product). In the other hand this xsp page only parses an xml input 
>message and signals the Cache Server to invalidate pages.

Again, when implementing such a feature then IMO it must:
(a) fit in the current Cocoon pipeline process 
(b) and more generic, like a system wait security and authorization model
which supports different protocols...

>    4) This functionality bost the final performance of database 
>intensive calculation. For example in a tradicional portal page like My 
>Yahoo, the stocks quotes content is viewed by millions of user a day, if 
>this stock quotes are calculated, obviusly, by an sql query in a target 
>database, the XSP page that query this table never will be more quickly 
>than the cached xsp content that only call at the method "isValid" of 
>the ExternalCacheValidity object.
>    In this situation the control of the content is inverted, that is, 
>the origin of the sources signals at the cache instead of the provider 
>ask for a new content. As a final result instead of to sent a jdbc 
>message to the database for the content of the quotes in every page hit 
>only a few messages are sent by the database when the table is updated.
>   And thats all, if you have any other questions sent me an email,  I 
>would like to receive positive or negative comment.

This I believe and I can feel your pain. I think you ideas are valid but
IMHO they must fit better into the current Cocoon pipeline architecture.

But it would be interesting what other devs. think of it.

Greets
  ~Gerhard
 
"Anything awful makes me laugh. 
I misbehaved once at a funeral..."


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


Mime
View raw message