Built with Seam
You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.
| Online: | 33 Members of 4185 |
| Forum: Seam Users |
 |
14. Mar 2008, 00:42 CET | Link |
I appreciate very much the commitment of the Seam Team to performance tuning! It is very important because we can never be tooooo fasssssst......
But you can do very much right now!
Most important hint - follow what the YUI-Performance team is telling us:
Summary:
- gzip everything (.xhtml, .js, .css, .xml)
- merge and compress your .js and .css-files
- add expiration headers to your images
- remove etag's
- don't use img-tag, use css and css-sprites
- put .css links at the top of your template
- put .js script-tag at the bottom of your template (if possible)
- don't use s:remote (extract the file with Firefox and save it in your script-dir)
- add only the interface.js?xxx to your pages (remote.js will be included in the merged and compressed file)
- The Seam-Team should add text/javascript Content-Type to the response of the remote servlet, because without that no gzip compression is possible
- Download and use the newest JSF RI 1.2.08 - improved performance!
This is the cookbook:
- Download YUI Compressor and put it on your classpath
- In your ANT build add a tasks for merging your .css and .js files. The sequence of the files is very important!
<target name="css.concat">
<concat destfile="${war.dir}/css/my-concat.css">
<filelist dir="${war.dir}/css/" files="screen.css, specialA.css, spcialB.css"/>
</concat>
</target>
<target name="js.concat">
<concat destfile="${war.dir}/script/my-concat.js">
<filelist dir="${war.dir}/script/jquery" files="jquery.js, jqueryPlugins.js"/>
<filelist dir="${war.dir}/script/" files="remote.js, ..., my.js"/>
</concat>
</target>
// you can extracted remote.js (Seam Remoting) with Firefox
// It is save because the file-content will not change until you install a
// newer Seam Release or you change the webapp context - then you have to extract and save
// the file again in your script-dir !!!
- then minify the scripts with YUICompressor
<target name="css.minify" depends="css.concat">
<java jar="lib/yuicompressor-2.3.4.jar" fork="true" failonerror="true">
<arg line="${war.dir}/css/my-concat.css"/>
<arg line="-o ${war.dir}/css/my-min.css" />
</java>
</target>
<target name="js.minify" depends="js.concat">
<java jar="lib/yuicompressor-2.3.4.jar" fork="true" failonerror="true">
<arg line="${war.dir}/script/my-concat.js"/>
<arg line="-o ${war.dir}/script/my-min.js" />
<arg line="--nomunge" />
</java>
</target>
Call the targets in your build script, remove your old .css and .js references and add the references to my-min.css and my-min.js files in your templates. Replace s:remote with the call to only interface.js?xxxxx in all your xhtml pages.
<script type="text/javascript" src="/mysite/seam/resource/remoting/interface.js?sysUserAdmin" defer="defer"></script>
- add a filter to your web.xml (if you work with JBoss AS 4.2.x). This filter adds expiration headers to the files of the defined directories (or mime-types).
<filter>
<filter-name>CacheControlFilter</filter-name>
<filter-class>org.jboss.web.tomcat.filters.ReplyHeaderFilter</filter-class>
<init-param>
<param-name>Cache-Control</param-name>
<param-value>max-age=86400</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CacheControlFilter</filter-name>
<url-pattern>/img/*</url-pattern>
<url-pattern>/script/*</url-pattern>
<url-pattern>/css/*</url-pattern>
</filter-mapping>
- add the following to your server.xml file in the jboss-web.deployer directory. This adds gzip compression to the defined mime-types
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
// important part - do same for 8443 or 443 port
compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/xhtml+xml,application/x-javascript,application/javascript,text/xhtml"
compression="on"/>
- remove the image-tags in your xhtml files and replace them with css (where possible). Use this Sprite Generator.
If you don't understand the technique follow this ALA Article CSS Sprites: Image Slicing’s Kiss of Death.
Ok, this is what I found so far - and it works relay. I recommend to give it a try.
Thanks for the info.
Do you have any numbers showing in what order of magnitude the performance effect of those tips are?
I think they can be helpful in squeezing out the last percent of performance but I think the result that (hopefully) comes out of the performance tuning to the framework itself that it upcoming...
If a man speaks in the forest and there is no woman around to hear him, is he still wrong?
Hi Nicklas
We are not talking about but about much more (show the Video of the YUI-Performance team).
First you should use FireBug in the Net-Tab mode in your FF-Browser. There you can see how many Requests will be done for your pages, if there are missing images or files (makes everything extremely slow). And you will see how much time each request will take.
Lets talk about something we can both test: Seam Framework Org. Clear your FF Cash and reload the Home Page, what you can see in the Net-Tab of FireBug is approx the following:
26 Requests - 2.58 seconds - with 258kb of content! Let's analyse this:
the first request - home - takes 16ms and is gzip - perfect! This means that the database/JSF/Seam/Facelet/tomcat/jboss AS did produce the content in 16ms - what about the other 2.49... or so seconds - thats all static content!
You will see 4 .css files with a total of 31kb - all downloaded in sequence and an approx. time of 50ms to 170ms each. If you concatenate them to 1 file, reduce the size with YUICompressor and gzip it, i would say you save 3 Requests (total of 200ms) and reduce the network traffic by 20kb of content.
Same for the .js files there are richfaces ajaxScript, jquery, jqueryPlugins, lacewiki.js and remote.js who are loaded every time and in sequence. We are talking about 5 Requests - 1.2 seconds - 146kb of content. If you concatenate and gzip them you will have approx. 50kb - 1 Request - 300ms. You save 0.9 seconds.
This is especially important because the Browser will stop rendering the page until the css and js are parsed!
The rest of the requests are images approx. 10 or 12. Each needs 16ms to 250ms, the downloads are partially in parallel. If you use css sprites you have 1 image of perhaps 20kb - 1 request and you save approx. 0.5 seconds.
Summary: I would guess that the Seam Framework Home Page would load in under 1 second - with a empty browser cache - if you follow the above advises.
OK, now you've got my attention ;-)
Your observations would make a nice addition to the performance knowledge base
If a man speaks in the forest and there is no woman around to hear him, is he still wrong?
Of course the numbers will vary depending on your infrastructure. But the best is - if your Internet connection is slow the profits are bigger. And you will see similar relative gains if you test with localhost.
This is all common-sense stuff and of course, it has been applied as good as currently possible on sfwk.org already. If some JS or CSS files are not merged, there is a good reason for it - either because it complicates development or build process at the moment. Other things, like the non-cached Seam Remoting Javascript stubs (due to changing cid parameter) are open and known JIRA issues.
The CSS sprite stuff is bullshit. Images are cached on the browser with no problem. Same goes for the advice because they found some IIS/Apache bug.
All in all, with todays client bandwidth, this is mostly irrelevant optimization. What really matters is how long it takes the server to generate the content, which is completely dependent on database access and page fragment caching.
Check out my weblog or have a look at the books I wrote.
And by the way, I don't trust the Firebug timer at all.
Check out my weblog or have a look at the books I wrote.
And this is why this analysis is incorrect: It takes the server between 200 and 1000ms to generate the sfwk.org homepage. depending on load. Forget the Firebug numbers and the 0.01 percent performance increase you might see from these little optimizations.
If you want to help, write me a plugin-aware dynamic page fragment cache component, add a switch that disables conversation identifiers for the Seam resource servlet, analyze Hibernate second-level cache usage, etc. All of these will have a 100 times more effect than making sure that a (COLD CACHE!) browser request doesn't download 10 kb too much.
Check out my weblog or have a look at the books I wrote.
Hi Christian
I think you are wrong ;-)
Try it, it costs you less then you think?
Dude, what part of we already did everything that makes sense and that was feasible at this time is so hard to understand? Optimizing cold cache requests is irrelevant. Optimizing cache usage is what really matters, both on the client and on the server.
Check out my weblog or have a look at the books I wrote.
File a feature request in JIRA for this.
Read about how to report a bug.
I will file this on JIRA. Thanks!
To Christian. It was a mistake to use Seam Framework Org for my example. You can take springframework.org if you like ;-).
But much better would be, if you look at apache.org or google.com. They merge very much of there files, they compress everything, they gzip all content (google does compression and gzip on html), google uses css sprites. They add expiration headers on there images. The .js files are compressed and g zipped.
Are they doing bullshit or are they dump? I don't think so.
Of course there is much more on performance - and everything should be common-sense stuff.
Seam Conversation Scope? Thank you very much for your work!
Hibernate Lazy Loading? Thank you very much for your work!
Proper pagination of large tables with Hibernate - and partial page rendering with Richfaces and A4J? Great!
Use of EL shortcuts! Just do it.
Database tuning? I my experience a lot of java developers are not interested in databases, especially not in db tuning (I don't mean you - you know it of course!).
PrimaryKey / ForeignKey indexing, clustered- vs. non-clustered indexes, full coverage index, order-clause-index, what means lpad/rpad,convert in where-clauses to the query optimizer, proper update statistics and rebuild of indexes, etc. etc.
Second Level cache? Important thing but not so easy like the other stuff, lots of trade offs.
Page Fragment caching? Same as Second Level cache?
JSF State saving strategy? Important but out of our possibilities.
EL Performance? Do your best.
Seam In and Out performance? Do your best.
configuration of log4j.xml after you have downloaded JBoss AS - and before you run the Seam examples ;-)
Thank you
You finally got it: If you run google.com, then you need to eliminate every bit and byte overhead.
If you however run a normal website or a simple webapp, your time is better invested optimizing things that really matter on a smaller scale. None of the more obscure techniques (CSS sprites, compressing cached JS files...) have any relevant effect in such an environment.
Check out my weblog or have a look at the books I wrote.
Ok, lets take it sportive.
I am running Internet Sites and Intranet Sites with hundreds of concurrent users. I have implemented most of the above advises and I can tell you that it works - and the response time is not only improved by 0.01%. You must not trust me - I suggest that you watch the Video of Yahoo and read some of the papers they provide and follow my links to the other sites. There are more people out there who care about performance.
I'd like to thanks for this article about performance issues.
I'm developing a system for an ONG where customers access this system from countries where most of the time the Internet connection is not so good.
I didn't make any measure about performance gains, but I got feedbacks from users saying the system got faster. I think this is more important than numbers.
Regards, Ricardo
Maybe I'm wrong, but you're better off worrying about your JBoss clustering design and implementation and reducing the amount of AJAX calls your Seam apps are doing.
In the end, the most important things in Seam are basic CRUD/transactions, conversations and possibly jBPM integration.
User experience in terms of AJAX-ifying stuff is secondary...