renaming source directories in a seam-gen project
by Dan Allen
I would like to propose that we modify the name of the source
directories in a seam-gen project so they better reflect how they are
built rather than what classes they might contain. The current paths
are:
src/action
src/model
The src/action directory works as the hot deployable classpath when
running in development mode. In production mode, they both get dumped
into the same classpath. Here is the renaming I am proposing:
src/action -> src/hot
src/model -> src/main (or src/static)
I am *not* looking for a major change here. This is just a small task
that I feel would just cause less confusion. For instance, I often
recommend to clients to move classes that have "solidified" out of the
hot deployment directory so that they are not constantly reloaded
(hence wasting build time). But currently it feels unnatural to put an
action component under src/model.
I would like to know if these names are okay and if, perhaps, you have
a better choice for "src/main". I really don't expect objections to
"src/hot", but you have a chance to speak up.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years
XSRF and JSF2
by Christian Bauer
Because it is back on Slashdot again today, I remembered why the
"let's automatically build a view if we don't have one in RESTORE VIEW
phase" proposal in JSF 2.0 was not sitting right with me.
You need a little background on XSRF (Wikipedia or something) and see
the older discussion here and especially my last comment:
http://www.seamframework.org/Community/IsSeamRemotingVulnerableToCrossSit...
I actually now think that we should have a cryptographically strong
(and of course mandatory) view identifier for better XSRF protection.
There are some other solutions worth discussing but AFAIK most of the
good ones involve a token/session mapping of some kind, so we run into
the "view has expired" problem again.
17 years
InitialContext performance issues
by Jay Balunas
I have been looking more into the InitialContext and some of the performance
issues surrounding it.
There are really a couple of things to look at. One is how the
InitialContext is created, and manged, and the other broad category is how
often and what items are looked up? I have investigated the first, and have
begun investigating the second.
InitialContext creation and management
------------------------------------------------
The only location were seam creates and manages the InitialContext is the
"org.jboss.seam.util.Naming" class (see:
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/N...).
The properties are set in one location and done only once in the
initialization of seam (see:
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/I...).
I see two issues here - one is creating the initial context every single
time it is needed, and the other is processing/checking the properties every
time it is called.
The first issue would require some caching mechanism or logic for reuse. I
am not an expert on when it makes sense to reuse an instance of the
InitialContext, and when we need to get it fresh. I can say that we
currently use they exact same properties to initialize it and those are set
during Seam initialization and do not appear to ever change once created.
Is there a way to cache and optimize this instantiation?
The second issue is that we do a certain amount of processing every time the
context is requested, this could be optimized. Currently I see a few
blocked threads on the "props.size()" call in the Naming class which is a
synchronized method on the Hashtable. This could easily be avoided.
Although we need to maintain the logic that if the property list is empty we
continue to call "new InitialContext()" and not pass in the properties
object. This is because the first thing the InitialContext constructor does
with a properties object is clone it which can be costly. I have attached a
patch that implements these changes for review.
Another item I noticed is that the only place (excluding some test code)
that does not use "Naming.getInitialContext()" is the
"org.jboss.seam.remoting.messaging.JBossConnectionProvider". It using the
"new InitialContext()" directly. Shane - is there a reason for this?
I'll write up my findings on the lookup usage asap.
Thanks,
Jay
--
blog: http://in.relation.to/Bloggers/Jay
17 years
annotations in JavaDoc
by Dan Allen
Does anyone know how to force the javadoc tool to include annotations
even if they are not marked as @Documented? Graciously the Seam
project marked most (if not all) annotations as @Documented, but in
JPA, none of them are marked this way. Thus, it is difficult to share
browse mappings w/o looking at the code.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years
Seam 2.1CR1 library versions
by Jozef Hartinger
Delver tool output:
/examples/wiki/lib,jdom.jar,1.0,,
/examples/wiki/lib,j4j.jar,-,No version found in manifest,
/examples/wiki/lib,hibernate-search.jar,3.0.1.SNAPSHOT-20080202,,
/examples/wiki/lib,jmimemagic-0.1.0.jar,0.1.0,,
/examples/wiki/lib,commons-lang-2.3.jar,2.3,,
/examples/wiki/lib,rome-0.9.jar,0.9,,
/examples/wiki/lib,ws-commons-util-1.0.2.jar,-,No version found in manifest,
/examples/wiki/lib,ejb3-persistence.jar,3.0 Final Release March 14 2007,,
/examples/wiki/lib,hibernate-validator.jar,3.0.0.GA,,
/examples/wiki/lib,lucene-highlighter-2.1.0.jar,build 2007-02-14,,
/examples/wiki/lib,hibernate-tools.jar,-,No version found in manifest,
/examples/wiki/lib,xmlrpc-client-3.1.jar,3.1,,
/examples/wiki/lib,jakarta-oro-2.0.8.jar,2.0.8 2003-12-28 11:00:13,,
/examples/wiki/lib,hibernate-annotations.jar,3.3.0.GA,,
/examples/wiki/lib,dbunit-2.2.jar,-,No version found in manifest,
/examples/wiki/lib,jboss-archive-browsing.jar,2.0.2.Alpha,,
/examples/wiki/lib,ehcache-1.3.0.jar,-,No version found in manifest,
/examples/wiki/lib,hibernate3.jar,3.2.3.ga,,
/examples/wiki/lib,xmlrpc-common-3.1.jar,3.1,,
/examples/wiki/lib,hibernate-commons-annotations.jar,3.0.0.GA,,
/examples/wiki/lib,hibernate-entitymanager.jar,3.3.1.GA,,
/lib,saaj-api.jar,-,No version found in manifest,
/lib,jboss-system.jar,4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA
date=200807192035),,
/lib,commons-beanutils.jar,1.6,,
/lib,jboss-deployers-core-spi.jar,2.0.0.Beta6,,
/lib,lucene-core.jar,2.3.0 613715 - buschmi - 2008-01-21 01:30:48,,
/lib,portlet-api.jar,1.0,,
/lib,jboss-seam-remoting.jar,2.1.0.CR1,,
/lib,cglib.jar,-,No version found in manifest,
/lib,jboss-seam-jul.jar,2.1.0.CR1,,
/lib,jsr250-api.jar,-,No version found in manifest,
/lib,jaxws-api.jar,-,No version found in manifest,
/lib,jboss-seam-pdf.jar,2.1.0.CR1,,
/lib,jboss-embedded-api.jar,-,No version found in manifest,
/lib,ejb-api.jar,3.0,,
/lib,ehcache.jar,-,No version found in manifest,
/lib,commons-lang.jar,2.3,,
/lib,jboss-seam-wicket.jar,2.1.0.CR1,,
/lib,jbpm-jpdl.jar,3.2.2 (date:12-Sep-2007 13:59),,
/lib,quartz.jar,1.6.0,,
/lib,asm.jar,1.5.3,,
/lib,hibernate-search.jar,3.0.1.GA,,
/lib,wicket-extensions.jar,1.3.3,,
/lib,resteasy-jaxrs.jar,-,No version found in manifest,
/lib,jsf-api.jar,1.2_09-b01-BETA1,,
/lib,core.jar,-,No version found in manifest,
/lib,jboss-seam-rss.jar,2.1.0.CR1,,
/lib,jsf-impl.jar,1.2_09-b01-BETA1,,
/lib,jsr181-api.jar,-,No version found in manifest,
/lib,jgroups.jar,2.4.1,,
/lib,commons-httpclient.jar,3.1,,
/lib,jfreechart.jar,-,No version found in manifest,
/lib,jboss-seam-mail.jar,2.1.0.CR1,,
/lib,urlrewritefilter.jar,3.0.4,,
/lib,wicket.jar,1.3.3,,
/lib,spring.jar,2.0.6,,
/lib,richfaces-api.jar,3.2.2.BETA4,,
/lib,janino.jar,-,No version found in manifest,
/lib,jcommon.jar,-,No version found in manifest,
/lib,dbunit.jar,-,No version found in manifest,
/lib,meldware-mailapi.jar,-,No version found in manifest,
/lib,jbosscache-core.jar,2.2.0.CR6,,
/lib,slf4j-api.jar,1.4.2,,
/lib,yarfraw.jar,-,No version found in manifest,
/lib,jboss-cache.jar,1.4.1.SP9,,
/lib,asm-attrs.jar,1.5.3,,
/lib,wicket-datetime.jar,1.3.3,,
/lib,jaxb-api.jar,-,No version found in manifest,
/lib,slf4j-log4j12.jar,1.4.2,,
/lib,hibernate.jar,3.2.4.sp1,,
/lib,jboss-logging-spi.jar,2.0.5.GA,,
/lib,jta.jar,-,No Manifest File,
/lib,hibernate-validator.jar,3.0.0.GA,,
/lib,richfaces-ui.jar,3.2.2.BETA4,,
/lib,cglib-nodep.jar,-,No version found in manifest,
/lib,hsqldb.jar,private-2007/08/31-08:52:19,,
/lib,itext-rtf.jar,-,No version found in manifest,
/lib,jms.jar,-,No version found in manifest,
/lib,jsr173_api.jar,-,No version found in manifest,
/lib,jboss-seam-ui.jar,2.1.0.CR1,,
/lib,antlr-runtime.jar,-,No version found in manifest,
/lib,drools-core.jar,4.0.4,,
/lib,testng.jar,5.6-200706070953,,
/lib,bsh.jar,2.0b4 2005-05-23 11:49:20,,
/lib,commons-logging.jar,1.1,,
/lib,jboss-vfs.jar,2.0.0.Beta11,,
/lib,servlet-api.jar,2.5,,
/lib,jboss-seam-excel.jar,2.1.0.CR1,,
/lib,jboss-seam.jar,2.1.0.CR1,,
/lib,joda-time.jar,1.4,,
/lib,itext.jar,-,No version found in manifest,
/lib,activation.jar,1.1,,
/lib,ant-antlr.jar,1.7.0,,
/lib,concurrent.jar,1.3.4 compiled: February 17 2005,,
/lib,el-api.jar,1.0,,
/lib,jboss-jmx.jar,4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA
date=200807192035),,
/lib,antlr.jar,-,No version found in manifest,
/lib,wicket-ioc.jar,1.3.3,,
/lib,drools-compiler.jar,4.0.4,,
/lib,meldware-mailjmx.jar,-,No version found in manifest,
/lib,jboss-el.jar,1.0_02.CR2,,
/lib,mail.jar,1.4,,
/lib,mvel14.jar,1.2.21 January 14 2008,,
/lib,jboss-seam-ioc.jar,2.1.0.CR1,,
/lib,groovy-all.jar,1.5.4,,
/lib,commons-io.jar,1.3.1,,
/lib,hibernate-annotations.jar,3.3.0.GA,,
/lib,jxl.jar,-,No version found in manifest,
/lib,jaxrs-api.jar,-,No version found in manifest,
/lib,richfaces-impl.jar,3.2.2.BETA4,,
/lib,persistence-api.jar,1.0,,
/lib,jsp-api.jar,2.1,,
/lib,jboss-common-core.jar,2.0.4.GA,,
/lib,jboss-seam-debug.jar,2.1.0.CR1,,
/lib,dom4j.jar,-,No version found in manifest,
/lib,jboss-seam-resteasy.jar,2.1.0.CR1,,
/lib,commons-digester.jar,1.7,,
/lib,jsf-facelets.jar,1.1.15.B1,,
/lib,commons-collections.jar,3.2,,
/lib,javassist.jar,-,No version found in manifest,
/lib,hibernate-commons-annotations.jar,3.0.0.GA,,
/lib,hibernate-entitymanager.jar,3.3.1.GA,,
/lib,jboss-deployers-client-spi.jar,2.0.0.Beta6,,
/lib,log4j.jar,1.2.14,,
/lib,gwt-servlet.jar,-,No version found in manifest,
/lib/interop,jboss-seam-jul.jar,2.1.0.CR1,,
/lib/interop,jboss-seam-wls-compatible.jar,2.1.0.CR1,,
/lib/interop/src,jboss-seam-wls-compatible-sources.jar,2.1.0.CR1,,
/lib/interop/src,jboss-seam-jul-sources.jar,2.1.0.CR1,,
/lib/test,thirdparty-all.jar,-,No version found in manifest,
/lib/test,jboss-embedded-all.jar,-,No version found in manifest,
/lib/test,hibernate-all.jar,-,No version found in manifest,
/lib/gen,cglib.jar,-,No version found in manifest,
/lib/gen,asm.jar,1.5.3,,
/lib/gen,jtidy.jar,-,No version found in manifest,
/lib/gen,asm-attrs.jar,1.5.3,,
/lib/gen,ant.jar,1.7.0,,
/lib/gen,hibernate.jar,3.2.4.sp1,,
/lib/gen,jta.jar,-,No Manifest File,
/lib/gen,bsh.jar,2.0b4 2005-05-23 11:49:20,,
/lib/gen,jboss-seam.jar,2.1.0.CR1,,
/lib/gen,hibernate-tools.jar,-,No version found in manifest,
/lib/gen,el-api.jar,1.0,,
/lib/gen,antlr.jar,-,No version found in manifest,
/lib/gen,jboss-el.jar,1.0_02.CR2,,
/lib/gen,common.jar,-,No version found in manifest,
/lib/gen,text.jar,-,No version found in manifest,
/lib/gen,freemarker.jar,2.3.8,,
/lib/gen,dom4j.jar,1.6.1,,
/lib/gen,runtime.jar,-,No version found in manifest,
/lib/gen,javassist.jar,-,No version found in manifest,
/lib/gen,jboss-seam-gen.jar,2.1.0.CR1,,
/lib/gen/src,jboss-seam-gen-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-rss-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-excel-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-resteasy-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-mail-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-pdf-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-remoting-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-ioc-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-wicket-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-debug-sources.jar,2.1.0.CR1,,
/lib/src,jboss-seam-ui-sources.jar,-,No version found in manifest,
/lib/src,jboss-seam-sources.jar,2.1.0.CR1,,
/build/maven/lib,maven-2.0.8-uber.jar,1.0,,
/build/maven/boot,classworlds-1.1.jar,1.1,,
/build/lib,ant-launcher.jar,-,No version found in manifest,
/build/lib,ant.jar,1.7.0,,
/build/lib,ant-nodeps.jar,1.7.0,,
/build/lib,maven-ant-tasks.jar,2.0.10-SNAPSHOT,,
--
Jozef Hartinger
JBoss QA Intern
Office phone: +420 532 294 130, ext 82-62 130
E-mail: jharting(a)redhat.com
17 years
Seam 2.1.0.CR1 code freeze
by Pete Muir
All
Please don't commit to trunk without clearing with Norman or Jozef
until Norman gives the go ahead.
Norman, all the issues in JIRA are now complete for 2.1.0.CR1, so its
over to you and Jozef to get the release out :-)
Thanks
Pete
17 years
Re: [seam-dev] Some profiling of blocking threads
by Pete Muir
Thanks Ryan :-)
On 25 Sep 2008, at 16:27, Ryan Lubke wrote:
> Thanks,
>
> Jim and I will look into it.
>
> Pete Muir wrote:
>> Ryan, Ed,
>>
>> Jay has been working on performance analysis for Seam.
>>
>>> UIComponent$AttributesMap
>>> -----------------------------------------------------
>>> - Issues related to this were responsible for about 20% of the
>>> blocked threads
>>> - Reported time spent blocked ranged from 30 ms - 848 ms with an
>>> average estimated to be 400ms
>>> - I need to rerun the tests to be more specific.
>>> - One of the items that was strange with this block was that it
>>> sometimes included completely unrelated actions or classes.
>>> - after adjusting the filters, and rerunning the tests several
>>> times I was able to narrow it down.
>>>
>>> * Investigation:
>>> Unfortunately this issue is in the RI JSF implementation itself.
>>> The UIComponentBase implements its own Map (AttributeMap) ( see http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...
>>> <http://fisheye5cenqua.com/browse/javaserverfaces-sources/jsf-api/src/java...
>>> >). This is not an issue directly, but you will see calls to the
>>> "getAttributesThatAreSet" method in the get, put, and remove
>>> methods of the map. This is implemented in the UIComponent class
>>> ( see: http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...)
>>> . The real issue is the call to "this.getClass().getPackage();".
>>> This call will eventually synchronize in the
>>> "ClassLoader.getPackage" method on the "packages" object for the
>>> whole classloader. This is why other threads were also blocked on
>>> this - like
>>> org.jboss.seam.contexts.Contexts.isApplicationContextActive()
>>> which is accessing a ThreadLocal object.
>>>
>>> We really have 3 options for this issue. - We can work with the
>>> RI to get the handling of the package check changed so that the
>>> values are some how cached in the component - how often do
>>> packages change while running ;-)
>>> - We can take a look and try to find excessive use of the
>>> components interactions with the AttributeMap.
>>> - We do nothing - but keep an eye on JSF 2 to make sure items like
>>> this are handled better.
>>
>> Naively, I would assume it should be possible to cache the value of
>> this.getClass().getPackage().
>>
>> HTH,
>>
>> Pete
>>
>> Begin forwarded message:
>>
>>> *From: *"Jay Balunas" <tech4j(a)gmail.com <mailto:tech4j@gmail.com>>
>>> *Date: *24 September 2008 22:05:51 BST
>>> *To: *"seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>"
>>> <seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>>
>>> *Subject: **[seam-dev] Some profiling of blocking threads*
>>>
>>> I have been executing the 25 user performance tests through the
>>> profiler to identify hot spots and areas of concern. I am
>>> initially looking at our blocking threads, and behavior around
>>> them that is causing the problems.
>>>
>>> Test Description
>>> --------------------
>>> - Use the 25 user wiki forum front page jmeter tests discussed in
>>> the previous email.
>>> - Uses same environment and procedures as defined in the previous
>>> email.
>>> - Tests are executed through the profiler with CPU recording
>>> turned on.
>>> - I have modified the default filters to allow the following
>>> packages
>>> - org.jboss.seam
>>> - javax.faces
>>> - most of the java.util collections and map classes
>>>
>>> Profile Results
>>> -------------------
>>> This is not a complete analysis of the entire application or even
>>> all of the blocking threads - I will continue to work on them and
>>> feed more information back to list.
>>>
>>> These items were detected via the thread usage history page, that
>>> shows all blocked and waiting threads and their stack traces.
>>>
>>> javax.naming.InitialContext.lookup
>>> -----------------------------------
>>> - as expected a large number of blocked threads were waiting or
>>> blocked while attempting to lookup the initial context.
>>> - One interesting thing is that not all of these were blocked on
>>> a Hashtable - others were blocked on, or were related to calls to
>>> Properties and WeakHashMap objects. This is likely caused by
>>> further method invocations that have been filtered out.
>>> - I will look further, but wanted to look at some of the other
>>> areas that were blocked.
>>>
>>> UIComponent$AttributesMap
>>> -----------------------------------------------------
>>> - Issues related to this were responsible for about 20% of the
>>> blocked threads
>>> - Reported time spent blocked ranged from 30 ms - 848 ms with an
>>> average estimated to be 400ms
>>> - I need to rerun the tests to be more specific.
>>> - One of the items that was strange with this block was that it
>>> sometimes included completely unrelated actions or classes.
>>> - after adjusting the filters, and rerunning the tests several
>>> times I was able to narrow it down.
>>>
>>> * Investigation:
>>> Unfortunately this issue is in the RI JSF implementation itself.
>>> The UIComponentBase implements its own Map (AttributeMap) ( see http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...
>>> <http://fisheye5cenqua.com/browse/javaserverfaces-sources/jsf-api/src/java...
>>> >). This is not an issue directly, but you will see calls to the
>>> "getAttributesThatAreSet" method in the get, put, and remove
>>> methods of the map. This is implemented in the UIComponent class
>>> ( see: http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...)
>>> . The real issue is the call to "this.getClass().getPackage();".
>>> This call will eventually synchronize in the
>>> "ClassLoader.getPackage" method on the "packages" object for the
>>> whole classloader. This is why other threads were also blocked on
>>> this - like
>>> org.jboss.seam.contexts.Contexts.isApplicationContextActive()
>>> which is accessing a ThreadLocal object.
>>>
>>> We really have 3 options for this issue. - We can work with the
>>> RI to get the handling of the package check changed so that the
>>> values are some how cached in the component - how often do
>>> packages change while running ;-)
>>> - We can take a look and try to find excessive use of the
>>> components interactions with the AttributeMap.
>>> - We do nothing - but keep an eye on JSF 2 to make sure items like
>>> this are handled better.
>>>
>>> org.ajax4jsf.application.AjaxViewHandler
>>> --------------------------------------------
>>> - This was not a large % of the blocked threads but caught my eye
>>> as a potential trouble spot because it seemed directly related to
>>> ajax calls.
>>> - This was easier to track down and the root cause is in the
>>> org.ajax4jsf.application.ViewHandlerWrapper class.
>>> - see http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/jav...
>>> - The problem is all the calls to "fillChain" which is a
>>> synchronized method in the class.
>>> - We need to find out how often the "_initialized" field is false
>>> - is this once a request, once for each component, etc...
>>> - it appears to be called many times - I will look further into
>>> this.
>>>
>>> -------------------------------------
>>> This is all I have had time for so far, but will continue to
>>> investigate some of the other aspects of the application. After
>>> completing the analysis of the primary blocking thread issues I
>>> will move on to other areas to profile. These will focus on
>>> specific issues raised by the team and the forums. I will also
>>> add performance tests and analysis for the dvd store example.
>>>
>>> Regards,
>>> Jay
>>>
>>>
>>> --
>>> blog: http://in.relation.to/Bloggers/Jay
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
17 years
Initial performance findings and baselines
by Jay Balunas
Hello All,
I have been looking at Seam 2.1 performance and begun profiling the wiki
example. Below are my initial findings. More will follow but I wanted to
provide some base information that we look at and compare with changes that
we make.
Environment
------------------------------
All tests were executed on my laptop (specs provide below).
* Lenovo T61
- 2GB Ram
- Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
- 7200RPM 200GB Hard drive
- Fedora 8 with all updates as of 9-22-09
- MySQL 5.0.45
- Sun jdk1.5.0_14
- JBoss AS 4.2.3.GA
* Test tools
- jmeter 2.3.2
- jprofiler 5.12
Test Description
-----------------------------
* Tests were all done with the wiki example
- svn trunk (rev 9017)
- deployed following the production deployment instructions
- plus addition mysql instructions from Christian
- MySQL primed with the live seamframework.org data as of July 30th.
* Between all tests
- AS server and test applications were restarted
- 3 page hits were conducted prior to load tests to prime system
* The tests described here were all focused on the first page of the users
forum
- http://localhost:8080/Community/SeamUsers
Multi User Load Test Results
----------------------------
* These tests were primarily to provide a base line of performance for
comparison.
- profiling was not done as part of these tests
- result times are averages of the runs completed
JBoss AS 4.2.3 as is
---------------------
25 users x 25 requests each
- Average request time 8.85 sec
- Median request time 8.22 sec
- Throughput 131.4 per min
- notes:
- server.log was 1.2 GB
- See jboss_423_base_25u.png
50 users x 25 requests each
- Average request time 22.72 sec
- Median request time 18.33 sec
- Throughput 96 per min
- notes:
- server.log is 2.4 GB
- this pushed my machine to its limit
- the final 10-15 threads would appear to freeze
- but would finish fine (except for 1 of the runs)
- See jboss_423_base_50u.png
Notes: Obviously the biggest issue here was logging I reduced all logging to
INFO by modifying the jboss-log4j.xml file and setting root logging level
and adjusting one other category. The results were dramatic as seen below.
JBoss AS 4.2.3 with reduced logging
------------------------------------
25 users x 25 requests each
- Average request time 3.08 sec
- Median request time 2.94 sec
- Throughput 283.5 per min
- notes:
- server.log was 87.6 KB
- See jboss_423_rd_log_25u.png
50 users x 25 requests each
- Average request time 10.10 sec
- Median request time 9.30 sec
- Throughput 237.6 per min
- notes:
- server.log is 96 KB
- all thread completed correctly and without issue.
- See jboss_423_rd_log_50u.png
1 user x 1000 requests
- wanted to get sample with just one user and many requests
- Average request time 264 ms
- Median request time 255 ms
- Throughput 255.5 per min
- notes:
- server.log is 79 KB
- Very tight deviation only 42 ms as expected
Notes: Obviously this is the configuration that I will use for the profiling
tests to follow, and for comparison runs based on changes made to the code.
I have begun profiling runs of the 25 user tests through JProfiler to
identify where threads are blocking and tracking down areas for
improvements. These tests with the profiler truly push my machine to the
limit, but I am see some results. I will be writing a follow up email with
at least some of that information soon - possibly today.
Regards,
Jay
--
blog: http://in.relation.to/Bloggers/Jay
17 years
Some profiling of blocking threads
by Jay Balunas
I have been executing the 25 user performance tests through the profiler to
identify hot spots and areas of concern. I am initially looking at our
blocking threads, and behavior around them that is causing the problems.
Test Description
--------------------
- Use the 25 user wiki forum front page jmeter tests discussed in the
previous email.
- Uses same environment and procedures as defined in the previous email.
- Tests are executed through the profiler with CPU recording turned on.
- I have modified the default filters to allow the following packages
- org.jboss.seam
- javax.faces
- most of the java.util collections and map classes
Profile Results
-------------------
This is not a complete analysis of the entire application or even all of the
blocking threads - I will continue to work on them and feed more information
back to list.
These items were detected via the thread usage history page, that shows all
blocked and waiting threads and their stack traces.
javax.naming.InitialContext.lookup
-----------------------------------
- as expected a large number of blocked threads were waiting or blocked
while attempting to lookup the initial context.
- One interesting thing is that not all of these were blocked on a
Hashtable - others were blocked on, or were related to calls to Properties
and WeakHashMap objects. This is likely caused by further method
invocations that have been filtered out.
- I will look further, but wanted to look at some of the other areas
that were blocked.
UIComponent$AttributesMap
-----------------------------------------------------
- Issues related to this were responsible for about 20% of the blocked
threads
- Reported time spent blocked ranged from 30 ms - 848 ms with an average
estimated to be 400ms
- I need to rerun the tests to be more specific.
- One of the items that was strange with this block was that it sometimes
included completely unrelated actions or classes.
- after adjusting the filters, and rerunning the tests several times I
was able to narrow it down.
* Investigation:
Unfortunately this issue is in the RI JSF implementation itself. The
UIComponentBase implements its own Map (AttributeMap) ( see
http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...).
This is not an issue directly, but you will see calls to the
"getAttributesThatAreSet" method in the get, put, and remove methods of the
map. This is implemented in the UIComponent class ( see:
http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/jav...).
The real issue is the call to "this.getClass().getPackage();". This call
will eventually synchronize in the "ClassLoader.getPackage" method on the
"packages" object for the whole classloader. This is why other threads were
also blocked on this - like
org.jboss.seam.contexts.Contexts.isApplicationContextActive() which is
accessing a ThreadLocal object.
We really have 3 options for this issue.
- We can work with the RI to get the handling of the package check changed
so that the values are some how cached in the component - how often do
packages change while running ;-)
- We can take a look and try to find excessive use of the components
interactions with the AttributeMap.
- We do nothing - but keep an eye on JSF 2 to make sure items like this are
handled better.
org.ajax4jsf.application.AjaxViewHandler
--------------------------------------------
- This was not a large % of the blocked threads but caught my eye as a
potential trouble spot because it seemed directly related to ajax calls.
- This was easier to track down and the root cause is in the
org.ajax4jsf.application.ViewHandlerWrapper class.
- see
http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/jav...
- The problem is all the calls to "fillChain" which is a synchronized
method in the class.
- We need to find out how often the "_initialized" field is false - is this
once a request, once for each component, etc...
- it appears to be called many times - I will look further into this.
-------------------------------------
This is all I have had time for so far, but will continue to investigate
some of the other aspects of the application. After completing the analysis
of the primary blocking thread issues I will move on to other areas to
profile. These will focus on specific issues raised by the team and the
forums. I will also add performance tests and analysis for the dvd store
example.
Regards,
Jay
--
blog: http://in.relation.to/Bloggers/Jay
17 years
s:debug
by Nicklas Karlsson
Do you think there would be use for a simple "mini-debug-page" tag, sort of
<s:debug/>
that would give an overview of the conversation id,
long-running/nested status and a short dump
of the components in the various scopes? The layout could be something
like a datatable with
conversation info in the header and scopes in columns.
I find it useful to be able to watch the info in RT when running the
application to see that conversations
are begun and ended correctly without going to the debug page.
There could also be attributes for hiding scopes for a more brief output.
---
Nik
17 years
