[core] lock profiling results for current myfaces

[Martin Koci <ma...@gmail.com>]

Hi,

I'm doing some profiling for a view, where thousand of concurrent users
is planned.  Configuration myfaces trunk, juel, tomcat 6.0.26, OWB trunk

Here are the top blocking locks:

1) java.util.Collections$SynchronizedMap.get(Object)
de.odysseus.el.tree.impl.Cache.get(String)	

2)java.beans.PropertyDescriptor.getReadMethod()
javax.el.BeanELResolver$BeanProperty.getReadMethod()	

3)org.apache.catalina.core.ContainerBase.fireContainerEvent(String,
Object)
....
org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String,
Object)...
... ServerSideStateCacheImpl.saveSerializedViewInServletSession

4)javax.faces.FactoryFinder._getFactory(String)
javax.faces.FactoryFinder.getFactory(String)
org.apache.myfaces.context.servlet.FacesContextImplBase.getRenderKit()	

ad 1 and 2) - those come from JUEL. The first one I try to avoid with
[1] and second one with [2] as Mark Struberg suggested. ( why JUEL uses
SynchronizedMap, not ConcurrentHashMap ?)



3) and 4) are from myfaces - any ideas if they can be avoided?

Regards,

Kočičák


[1] https://issues.apache.org/jira/browse/MYFACES-3160
[2]
https://github.com/struberg/juel/commit/da3791b91c3e23c973ee865050846b980399ecff

Re: [core] lock profiling results for current myfaces

[Bernd Bohmann <be...@atanion.com>]

Hello Martin,

3) if you don't need to replicate the ViewState in a cluster then you
can use a own StateManager without informing the container that the
ViewStateMap has changed.

4) if org.apache.myfaces.CONFIG_REFRESH_PERIOD=0 is configured we can
use an unsynchronized version. But
org.apache.myfaces.CONFIG_REFRESH_PERIOD=0 must configured for all
webapps that shared this MyFaces class.

Regards

Bernd

On Wed, Jul 27, 2011 at 9:20 PM, Martin Koci
<ma...@gmail.com> wrote:
> Hi,
>
> I'm doing some profiling for a view, where thousand of concurrent users
> is planned.  Configuration myfaces trunk, juel, tomcat 6.0.26, OWB trunk
>
> Here are the top blocking locks:
>
> 1) java.util.Collections$SynchronizedMap.get(Object)
> de.odysseus.el.tree.impl.Cache.get(String)
>
> 2)java.beans.PropertyDescriptor.getReadMethod()
> javax.el.BeanELResolver$BeanProperty.getReadMethod()
>
> 3)org.apache.catalina.core.ContainerBase.fireContainerEvent(String,
> Object)
> ....
> org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String,
> Object)...
> ... ServerSideStateCacheImpl.saveSerializedViewInServletSession
>
> 4)javax.faces.FactoryFinder._getFactory(String)
> javax.faces.FactoryFinder.getFactory(String)
> org.apache.myfaces.context.servlet.FacesContextImplBase.getRenderKit()
>
> ad 1 and 2) - those come from JUEL. The first one I try to avoid with
> [1] and second one with [2] as Mark Struberg suggested. ( why JUEL uses
> SynchronizedMap, not ConcurrentHashMap ?)
>
>
>
> 3) and 4) are from myfaces - any ideas if they can be avoided?
>
> Regards,
>
> Kočičák
>
>
> [1] https://issues.apache.org/jira/browse/MYFACES-3160
> [2]
> https://github.com/struberg/juel/commit/da3791b91c3e23c973ee865050846b980399ecff
>
>
>
>
>