Update on Performance Issues of PLoS Websites

Submitted by Richard Cave on Tue, 2008-03-18 17:56.

Performance of the websites hosted on Topaz has increased over the last two weeks with a variety of patches ported to the production servers. We still have an outstanding memory problem that requires a restart of the Topaz applications three times a day (these restarts usually occur around midnight, 8am and 4pm with a duration of less than 10 minutes). I feel that we're close to diagnosing the memory problem which is the last performance hurdle.

We're waiting for the Topaz developers to finish two outstanding tickets before we create a new release candidate (RC 0.8.2.2 for those that are counting). This release candidate will contain all of the patches, even better caching features and XSL/CSS bug fixes. We'll test the release candidate later this week and the production servers will run on this RC no later than Friday, March 28.

We also have a patch for search and will test the patch tomorrow. If testing goes well, then we will be able to place basic and advanced search back on the journal websites by the end of the week.

And now for something completely different.... We had a problem with one of our production servers Friday morning which caused an extended downtime. The Fedora server mysteriously stopped all network traffic and then rebooted. Russ and Josh are bringing the servers down for diagnostic tests and maintenance from 9-9:30pm PST. During this time, the journal websites will display the "undergoing site maintenance" page.

Trackback URL for this post:

http://www.plos.org/cms/trackback/341
TOPAZ update
from A Blog Around The Clock on Tue, 2008-03-18 19:13

The IT/Web has been hard at work to make TOPAZ, the platform for 5 out of 7 PLoS journals work smoothly again....

Richard Cave's blog | add new comment | email this page | Printer-friendly version
( categories: )

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
CiteULike integration
Submitted by Anders (not verified) on Fri, 2008-05-16 06:39.

Hi Richard,

Is anyone working on getting CiteULike to work with PLoS Computational Biology?

CiteULike is a great tool. And supporting it would get PLoS compbiol papers more exposure.

Best,
Anders

reply | email this page
Feedback form on ploscompbiol broken
Submitted by Anders (not verified) on Mon, 2008-03-31 03:10.

When I try to submit a comment through

http://www.ploscompbiol.org/feedbackCreate.action

I get

"
Not Found

The requested URL /journals/compbiol/feedback.action was not found on this server.
"

Best,
Anders

reply | email this page
Re: Feedback form on ploscompbiol broken
Submitted by Richard Cave on Fri, 2008-04-04 09:28.

Hi Anders,

Thanks for pointing out this problem. Turned out that the URL used in the feedback form was missing a slash. Russ has put a fix in place.

Rich

reply | email this page
Broken links (2 kinds)
Submitted by wooo (not verified) on Fri, 2008-04-18 16:13.

Just thought I'd mention, I got the following link (note the : with no port)... it obviously didn't work...

http://www.plosone.org:/user/secure/editProfile.action?tabId=pre

Also, adding links in comments or notes of an article is broken when there's a single quote in the url...

With no way to edit a comment, that means, you post, and there it is, broken... (don't think there's even a preview option for comments, is there?)

Thanks,
Steve

reply | email this page
Out of Memory Error (OOME)
Submitted by Richard Cave on Mon, 2008-03-24 19:18.

OOME is the acronym of the month. We've diagnosed the problems with the out of memory error. It turns out that many of the heavy lifting Java instances in the TOPAZ publishing application are session-scoped. What does this mean?!? For every user, a session is kept until a timeout period is reached, then it is assumed that the user is no longer visiting the site. The session is discarded and the Java garbage collection frees the held memory.

This was particularly problematic for the article XSL transformation of the XML to HTML. Each user was creating there own article XSL transform which was a) really really big and b) staying in memory for a really really long time. We've already changed the production settings so that sessions are kept for 10 minutes rather than a really really long time and this should have immediate impact on the garbage collection of the memory.

The developers are also changing each of the Java instances from session scope to request scope so they are only available as long as the requested object is available. We're testing the article XSL and preliminary results look promising.

More to follow as testing continues....

reply | email this page