JSP Taglib and very poor performance

Hi,

We have been working with the JSP taglib recently and have noticed that it lacks performance. It seems that Domino sessions are not pooled (bring one up at the start of the JSP and tear it down at the end) which makes the response times horrible. So i started to browse around and came across some WAS portal redbook where they mention something about a new “duration” attribute to the session-tag.

Is this applicable on the ordinary taglib as well (the redbook described how to use a “DominoSessionManager” to store a session in the HttpSession in the Login() method and remove it in the Logout()).

Say for example that you have an open WAS/Domino site with anonymous users. Are there any ways to get session pooling in this context. How would you terminate the domino session (and when?) if you don’t have any natural means to “exit” the users session. There is a time-out but without recycling the objects you will be in big trouble.

For the hell of it (and as a comparison) i built my own session pooling mechanism (with built-in time out/clean up, etc) in combination with a servlet and form-beans/view-beans. This way, i got sub-second response times, but it also meant a lot of more work. The JSP lib on the other hand is extremely powerful and rich but it lacks performance.

Will IBM ever implement some mechanisms to boost performance in this context? Or does such a mechanism exist today?

Kind regards

Daniel

Subject: JSP Taglib and very poor performance

There are a few mechanisms by which you can keep a Domino session open for longer than the span of time the <domino:session tag is executing - most easy is setting the session tag’s ‘duration’ attribute to either ‘request’ or ‘session’.

For duration=“session”, you also need to add RemoteSession.properties file containing

maxPersistentSessions=10

(or whatever number works best for you). The intent is to limit the number of lengthy sessions that are consuming resources on the Domino server. (It does not work correctly, though, as it does not really provide a WebServer wide limit…)

duration=“session” only works with remote (iiop) sessions, and is safest when there’s a fairly short session iiop timeout value. The default is 60 minutes, your normal use case will dictate what it should be, but I figure about 2 minutes - after which the user has left, or is working on something for the next 10 to 15 minutes.

The DominoSessionManager normally hooks the HttpSession, and will go away if the connection is lost.

I would not recommend your webapps dealing with the DominoSessionManager - that technique is designed to let all the portlets on a single portal page share a Domino session (not doing parallel rendering!) - since you have to log in to the portal server, it is redundant to make each portlet authenticate to acquire a Domino session, and as you noted, Portal has a well defined login/logout step so an orderly shutdown is possible, unlike with a regular webapp.

There is another attribute you might employ on some jsptags - the ‘dojkey’ attribute. It allows your servlets to pass in their Domino objects - session, database, view, document - to the jsp tags. But that won’t save you any work, so I don’t thing that’s what you are looking for either.

I think you might want to reconsider your design. A Domino session contains user-specific data, and serves as a place for the Domino server to cache some state for that user.

Even though all your users have the same Domino access rights - that of the Anonymous user - each browser-user will have some navigation context that would not make sense to another browser-user who connects only fractions of a second later, and by sharing the same Domino session the view the last one opens would be what all would see…

You might want to explore a sort of publishing model - have your Domino jsp app write out files on a timer interval, and let all your users load from those html files from your webserver. Unless there is some advantage to having each Anonymous user hit the jsp + have the Domino server return the documents to your webapp so it can regenerate that html…

-sl