Re: Two performance problems (found during myfaces testing)
2012/3/9 Konstantin Kolinko knst.koli...@gmail.com: 2012/3/9 Martin Koci martin.kocicak.k...@gmail.com: Hi, we did performance tests in myfaces core project recently and we found two performance problems in tomcat (7.0.26): 1) javax.el.ExpressionFactory.newInstance() does not cache instance created with javax.el.ExpressionFactory.newInstance. - every invocation of this method reads service .properties file again and accesses disk. This was discussed a time ago [1], but I forgot to report it. +1. 2) org.apache.catalina.core.ContainerBase.fireContainerEvent; That method contains critical section: synchronized (listeners) { list = listeners.toArray(list); } Is is called pretty often with every put operation into request or session map. I see fireContainerEvent() calls in StandardSession. Moreover those are N x M loops: a loop in StandardSession over array of context.getApplicationEventListeners(); x a loop inside of context.fireContainerEvent(). +1 to file. I do not see such calls in relation to request. Where have you seen them? That code in tomcat looks like a candidate for CopyOnWriteArrayList Will it eliminate a need for List - Object[] conversions? Just a simple solution might be a ReadWriteLock. Can I create a bugzilla ticket fot those two? Regards, Kočičák [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg48482.html I added these two reported issues into Bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=52998 https://issues.apache.org/bugzilla/show_bug.cgi?id=52999 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Two performance problems (found during myfaces testing)
Hi, we did performance tests in myfaces core project recently and we found two performance problems in tomcat (7.0.26): 1) javax.el.ExpressionFactory.newInstance() does not cache instance created with javax.el.ExpressionFactory.newInstance. - every invocation of this method reads service .properties file again and accesses disk. This was discussed a time ago [1], but I forgot to report it. 2) org.apache.catalina.core.ContainerBase.fireContainerEvent; That method contains critical section: synchronized (listeners) { list = listeners.toArray(list); } Is is called pretty often with every put operation into request or session map. That code in tomcat looks like a candidate for CopyOnWriteArrayList Can I create a bugzilla ticket fot those two? Regards, Kočičák [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg48482.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Two performance problems (found during myfaces testing)
2012/3/9 Martin Koci martin.kocicak.k...@gmail.com: Hi, we did performance tests in myfaces core project recently and we found two performance problems in tomcat (7.0.26): 1) javax.el.ExpressionFactory.newInstance() does not cache instance created with javax.el.ExpressionFactory.newInstance. - every invocation of this method reads service .properties file again and accesses disk. This was discussed a time ago [1], but I forgot to report it. +1. 2) org.apache.catalina.core.ContainerBase.fireContainerEvent; That method contains critical section: synchronized (listeners) { list = listeners.toArray(list); } Is is called pretty often with every put operation into request or session map. I see fireContainerEvent() calls in StandardSession. Moreover those are N x M loops: a loop in StandardSession over array of context.getApplicationEventListeners(); x a loop inside of context.fireContainerEvent(). +1 to file. I do not see such calls in relation to request. Where have you seen them? That code in tomcat looks like a candidate for CopyOnWriteArrayList Will it eliminate a need for List - Object[] conversions? Just a simple solution might be a ReadWriteLock. Can I create a bugzilla ticket fot those two? Regards, Kočičák [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg48482.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org