Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <1417581742.1136281801581.JavaMail.jira@ajax.apache.org>
Date: Tue, 3 Jan 2006 10:50:01 +0100 (CET)
From: "Jean-Baptiste Quenot (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1709) Speedup portal loading
In-Reply-To: <213771436.1134392625691.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361593 ] 

Jean-Baptiste Quenot commented on COCOON-1709:
----------------------------------------------

Ralph, I don't know why I don't get notified of your comments, not even on cocoon-dev.

I made some tests, with or without cache (I added a boolean flag), and with or without Ralph's change on the Castor mapping, and the results are quite surprising: it seems that no caching is needed anymore with his change, but what I don't understand is that only the first profiles loading takes longer.

The facts in milliseconds:

loadProfile-without-cache-and-older-cocoon: 1551, 1014, 1403
loadProfile-without-cache-and-newer-cocoon: 505, 183, 174
loadProfile-with-cache-and-newer-cocoon: 601, 142, 113

I would expect that without cache, the newer Castor mapping would always take about 505ms.

> Speedup portal loading
> ----------------------
>
>          Key: COCOON-1709
>          URL: http://issues.apache.org/jira/browse/COCOON-1709
>      Project: Cocoon
>         Type: Improvement
>   Components: Blocks: Portal
>     Versions: 2.1.9-dev (current SVN)
>     Reporter: Jean-Baptiste Quenot
>  Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config
>
> Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow.  This patch allows to cache the result for further invocations.  However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets.  Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable.
> An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles.  Note that the key of the object is the URI returned by the source.  This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira