Hi,

Our site has gone live using liferay 4.4.2. We currently have a memory leak with IE 7 (could be other IE versions as-wel) every page load adds around 2MB to the iexplore process.

This same thing is occuring to the www.liferay.com site.. ie keep refreshing the home page while keeping the task manager open, you'll see the Mem Usage increase by up to 1MB for each refresh..

Any ideas..

Jason.

Thread moved: Miscellaneous.
-jr

Is MSIE patched to the last state? I do not have any problems with MSIE 7.0.5730.13

with regards, Archie

I'm at MSIE 7.0.5730.11

We are having users complain. Each page load on our site consumes around 2MB of memory.. Funny thing is that when I remove the google analytics code the problem goes away..

Removing the google analytics code from the pages is not an option. I'm not blaming the google code, I think we must have some javascript that is conflicting with it.. but I'm not sure how/where..

Jason.

Hi there Jason,
There are a few things you might try to narrow down where the memory leak could be happening.

Does it happen on a page with no portlets added to the page?
Does it happen when you're using the Classic theme?

The Google Analytics code could be interfering with any number of things, but changing those things above will help narrow it down to where it could be coming from.

Thanks Jason,

There are two ways how to use the Google analytics in the pages - the older one, based on urchin.js and the newer one, based on ga.js... Maybe You could try the other one if the one from them causes the problem...

with regards, Artur

I have tried with both the older urchin and ga javascript and they both leak.

To replicate this I take the classic theme and place the google anaytics code before the closing body tag. Then create a page with no portlets, then keep refreshing the page, My iexplore process increases by at least 1MB per page refresh.

If I remove the google analytics the leak disappears, Also if you run it locally from localhost then it also does not leak, but it does leak if you use your IP address, or some other name..

As, I mentioned above I m getting this on the www.liferay.com site..Is anyone also getting this..
I am also testing with Drip, which shows both my simple test site and www.liferay.com both have memory leaks for IE.

Jason.

Hi Jason,

I have the same problem with or without google scripts.

I have already asked, but it seems that nobody else is having the same problem... It's strange, isn't it?

I have the problem with Firefox, IE and Safari.

Thanks,
Mariano.

:-) Maybe nobody noticed this is the problem related to some concrete web site, because the memory leaks in Explorer or Firefox are "pretty usual"... :-(

Well... I am using only Liferay portlets / applications, and I also face this problem with Liferay.com...

Regarding the pretty usual memory leaks, I am used to work for my client with the browser opened from 9 to 6 without needing to restart it.

Now, when I am reading Liferay Forum all day, I need to restart it after a couple of hours (or less) because the browser memory increases and increases, and it becomes unusable. It's weird...

I noticed the browser memory leak problem as well with both IE 6 and Firefox 2.0.0.14 the past couple of days well working with the out of the box Liferay site. At this point I have not narrowed it down to a particular theme or pages with/without portlets. It looks like it is going to be a process of elimination.

Doing a quick search of leak detection tools, has anybody tried using any of these?

IE Leak
Microsoft Beta Leak Detector

Here's a great article on Leaky Patterns

I didn't try them.

I searched for a Firefox Add-On to see if there was a problem related to Javascript but nothing's better to Firebug, yet. And I couldn't find anything with it =(

I'll take a look at them!

Thanks,
Mariano.

I have tried the IE Leak Detector tool and found that as many as 40+ DOM elements are leaking out of a good many of the portlets. Some seem to be worse than others.

The problem right now is I have to restart my IE 6 browser every 30 minutes because it sucking down so much memory. When using FF the browser sometimes just locks up.

Hm :-( Interesting - 30 minutes this is really bad.. I cannot confirm such a drastic problems by me (firefox 2.0.0.14, MSIE 7)...

Hi all,
We've done some testing and I thought I would report back to you what our findings were.

Google Analytics

Some of you mentioned that Google Analytics seemed to be causing the problem, and since we removed it about 20 minutes ago, it seems to have cleared the memory leak, or at least lowered it to a non-noticeable degree.
We'll keep testing, but if nothing else, I think it's safe to say that we don't have a major leak. Before removing GA, it would eat up roughly 1MB of RAM per request. Now it seems to stay pretty solid.

Liferay 5.0.1 and earlier
In Liferay 5.0.1 and earlier, we used jQuery 1.1.4, which I've now found out had a memory leak that has since been fixed in the 1.2.x branch (which is the most current). jQuery has been upgraded in version 5.1, and I will do what I can to work on a patch to see if there is any possible way to roll back a fix for those of you who can't upgrade.

Like I said, we just removed the GA code, and there are others online who have posted similar problems with GA's javascript causing memory issues in multiple browsers, and with such a reduction, it seems to have cleared up the problem significantly.

Knowing our team, we'll also probably do some testing internally to see if there is a way for us to fix the GA problem, if at least for Liferay users (we may be able to clear the memory in a way that Google can't in a widespread fashion). Of course, that's conjecture at this point, but we will be looking at it.

Thank you guys for your patience and involvement in helping us fix this. Memory leaks are a tricky beast to debug, and we really appreciate you guys letting us know your experiences.

If anyone is still experiencing memory leaks on the website (after clearing your cache), if you could please post your IE version with build number (found by going to Help > About Internet Explorer | Version number that would be incredibly helpful.
Also, if you're on IE6, Microsoft has released a patch for IE6 that clears up a lot of memory leak problems, so updating with at least that patch could go a long way to helping.

Thanks everyone,

Thanks for reporting this! Really nice to see that Liferay is taking the community serious and picks up the signals of possible problems

Besides that, I can't wait to upgrade to 5.1 when it's released!

Nate,

Thanks for your reply and the effort you are putting into this.. as I was losing hair over this one...and my javascript debuging skills in IE are very limited...

While you are looking into the javascript, another complaint we have received from our SEO/SEM reports is the amount of javascript on each page. I have seen a post here somewhere that posses the question on why is their so much javascript for anonymous users...ie users who cannot change layout or add applications...


Jason.

Hi Jason,
That actually is a common complaint, and it's something we are actually investing quite a bit into resource-wise, into finding the best way to handle the user experience for Javascript based components, and for everyday users.

A quick question, are you guys taking advantage of the barebones javascript setting? This is something you guys can set in your portal.properties, and overwrite to limit the Javascript to just what you guys wish to use.

Right now, as of 5.1, the barebones JS is about 48k gzipped. It's not huge, but it's not trivial either.

So, the issue for us is that there is a tension between waiting for one large file to download and cache, and having multiple http requests for each component.

Now, I'll be the first to admit I'm not the smartest guy in the world, so if anyone has any cool ideas for solving this problem I am all ears, and would love to hear it, but I'll first list off a few of the ideas we've had, and some of the concerns.

One idea we've had is to lazy load the javascript, either via DOM insertion into the head, or ajax. With ajax, the issue is a matter of caching. We could manage this on the server side, and it's something we're actually going to look into over the next couple of weeks.
I know a lot of ajax heavy sites do this, and I think it works for them more because they usually have one product they're managing, whereas we are a framework and a product.
I'm not saying it can't work for us, but that there are a lot of considerations.

Another concern I have is that browsers don't do cache "chunking", meaning, if you download file1.js and it contains Module A, Module B, and Module C, and then you download file2.js, and it contains Module A, Module D, and Module E, you still have to redownload Module A all over again.
And since different portlets use different modules (and in varying combinations) the user would have to redownload the possible combinations (even if only 1 line of Javascript is different), meaning that the entire user experience degrades, though theoretically on paper, the Javascript is smaller.

There's also the issue of Javascript dependency and waiting for the Javascript to download asynchronously, even though the HTML that depends on the Javascript has already been rendered. This means the users will either think the elements are broken, or have to wait for the data to transfer over the pipe.

There are ways we can get around this, and we are working hard to make the portal use unobtrusive javascript as much as possible, but they aren't minor changes that need to be made, so it is taking a bit of time.

But hopefully that answers yours (and others) question about Javascript size, some of the considerations we're having to take into account, some of the challenges, and what our plans are.

I don't want to hijack this thread though, so if you have any more questions related to this, a new thread would probably be best

Nate,

Do you mean the javascript fast load setting or is there a new barebones setting in releases > 4.4.1

Our problem is not necessarily the size of external js files..but of the amount of js in the html..
ie if you look at the liferay site the header tag has a few hundred lines of js.

Jason.

Hi Jason,
Yes, there is a new setting in 4.4.x+ called javascript.barebone.files where you list the files you wish to include.

About the amount of Javascript in the HTML, that is something we've been addressing as well. For instance, in Liferay 5.1 (just released), we stripped most of the JS that was showing up in the html (addPortlet, addPortletHTML, showTemplates, and a lot of others). The themeDisplay JS in the header is still there, and I'm currently trying to think of a good way around it (it's basically server data that changes frequently, and we need access to it from the JS).
And many portlets still embed JS into the page, but our goal (and we're working quite hard on it) is to be as unobtrusive as possible with the Javascript, for not only SEO reasons, but accessibility and best practices.

But it is a concern many have asked us about, and we're currently working on some fixes and improvements for it.

Hopefully that answers your question.

Thanks Jason,