/Tag: performance

Session and Memory Leak on Wildfly 10

I recently re-wrote 10MinuteMail, my secure temporary email service, updating it from Seam 2 and JBoss 4.2 to Deltaspike and Wildfly 10.  Unfortunately I noticed a memory leak in the JVM.  During beta testing, the JVM heap usage would slowly grow, over 1-2 weeks until it reached an OOM (out of memory condition).

Memory Leak in the Old Gen on Wildfly 10

I performed analysis on heap dumps taken at various stages of memory consumption and discovered that the issue was HttpSessionImpl objects being held onto by the com.sun.faces.application.WebappLifecycleListener’s activeSessions property.  Since 10MinuteMail does some “manual” session expiration and management, and the new application is AJAX heavy, I figured I was doing something wrong.  But thanks to some great support on the forums, I soon learned that there is a bug in the Undertow sub-system that ships with Wildfly 10.0.0.FINAL which keeps old sessions around, causing a memory leak – 

[UNDERTOW-657] HttpSession never removed from activeSessions – JBoss Issue Tracker

The fix is to replace the Undertow modules that come with Wildfly 10 with the latest stable release versions.  You can find more details here –

Now my application works as expected with no memory leak or abnormal numbers of session objects.

JBoss Performance Tuning and MasterTheBoss

I review technical book manuscripts for a few different publishers, and recently had the pleasure of working on an upcoming book called JBoss Performance Tuning by Francesco Marchioni.  It’s coming out in December 2010 and will be a must have addition to your bookshelf if you deploy applications on JBoss.

The book contains extensive performance/load test results giving you hard data to work with when deciding which changes to make in your environment.  Some of the results were very surprising and the book has a lot of valuable data.

The author, Francesco Marchioni, also runs a popular JBoss related blog called  There are a ton of great articles and posts there, so check it out!

Google Speed!

Google has a nice collection of tutorials, tech talks, etc… related to making websites run faster. You can find it here: Let’s make the web faster This is no longer available.  Check out a 3rd party guide here: PageSpeed Guide and higher level Google Site here: PageSpeed Insights Rules

I strongly disagree with the first tutorial however. CSS: Using every declaration just once.

The premise of the tutorial is that in order to make your website faster, you should make the code you send to the browser smaller (TRUE) and that one of the best ways to optimize CSS files is to use every declaration just once. This second part is the part I disagree with so strongly.

Basically the author recommends reversing the standard organization of the CSS declarations. Here are the before and after examples from the tutorial:


h1, h2, h3 { font-weight: normal; }
a strong { font-weight: normal !important; }
strong { font-style: italic; font-weight: normal; }
#nav { font-style: italic; }
.note { font-style: italic; }


h1, h2, h3, strong { font-weight: normal; }
a strong { font-weight: normal !important; }
strong, #nav, .note { font-style: italic; }

So instead of having your selector/class/id contain all of the relevant styling declarations, you group the relevant selectors for each declaration. It’s changing the traditional one-to-many relationship of selectors and style declarations to a many-to-one relationship.

The upside, and the premise of the article, is that this reduces the size of the CSS by reducing duplicate lines of declarations. This is true, but is a very small upside compared with the downside.

The downside of this is that it makes writing, maintaining, and debugging your CSS MUCH harder. The styles applied to a given selector/element/class/id are now spread out over the entire CSS file.

If you’re a Java developer, this is akin to re-factoring every property in every bean you have into their own interface (since Java doesn’t do multiple inheritance) and having each bean implement a huge number of these interfaces. It’s backwards, and makes maintaining your application amazingly difficult.

The other thing is that the CSS file size savings are only 20-40%. If you’re gzipping your CSS files on your web server and setting a far futures expiration header (and you are doing both of those things, right?), then the savings are closer to 2-4%. Totally not worth it considering the downsides above.

MSSQL, jTDS, NVARCHAR and Slow Indexes

Mr. Slow

Mr. Slow by Vox

An application I’ve built is going into production soon. It’s the first application I’ve been involved with which will be using MSSQL server in production, I have some learning about MSSQL to do. After some research, I ended up using the jDTS JDBC driver instead of the Microsoft JDBC driver (which is feature incomplete and has some serious open issues).

We recently began performance testing and saw some odd behavior. Initially the application was performing well. However after few runs of the stress test the performance went from good to awful. The main web service call went from 600 ms to 23,000 ms. The database server’s CPU was pinned, and the app servers were barely loading, spending all their time waiting for the database server to return queries. Stranger still, my local instance (running against PostgreSQL) performed well with the same code and same stress tests. Luckily a smart MSSQL DBA was able to figure out why the database was burning so much CPU and responding so slowly.

One of the primary queries is against a table which has been growing. The select query is simple and had an indexed column in the WHERE clause. Even as the table grew to over a million rows, it should have been a very quick query. Unfortunately it was taking several seconds to complete. My local instance had over 30 million rows in the same table in PostgreSQL and the query was lightening fast. The DBA discovered that the query execution was converting the indexed varchar column into nvarchar values for comparison with the query parameter used in the WHERE clause which was inexplicably coming over as an nvarchar. This datatype mismatch between the column definition and the query parameter meant that MSSQL was doing a scan of the million+ record index instead of the almost instant seek it should have been doing.

It turns out that jTDS sends String parameters over as Unicode (nvarchar) by default. It’s easily fixed by adding this property to your connection-url:

[plain] sendStringParametersAsUnicode=false[/plain]

That immediately fixed the performance issues.

So, if you’re using jTDS and are using indexed varchar columns in your queries, you should add the property above to avoid your indexes being wasted and your queries running slowly. Shrinks Your Images

In my post on Improving Secondary Asset Loading Time in order to increase the performance of your web application I briefly touched on shrinking your media files to the smallest size that will give you acceptable quality.

Rather than waste your time playing with Photoshop export settings for each image, you can now use, a web applicaiton built to shrink your image files for you:

Performance just got a little bit easier. Optimizing images by hand is time consuming and painful. Smush it does it for you.

I’ve used it on a few images, and so far I’m impressed with the results.

Do you have any handy tricks for optimizing the size of your media files?