Web UI painfully slow

corbint@uk.ibm-dot-com.no-spam.invalid (tobycorbin) wrote in news:fo7hc6
$udd$1@localhost.localdomain:

Is there something I've missed on the install that is
causing this?

I am also interested in what the repository team has to say :)

Couple thigs I noticed
1) check the admin and ensure your JVM has at least 1Gig (first page of the
JVM)
2) check the services, which one are taking the most time ?

Then... well... I will attend a in-deth course about WebSphere performance
in April.. I may know more then... I know it does not help now... sorry :(

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

I've found the cause of why the Web UI is slow. It happens when I switch to using ldap authentication against IBM's bluepages. If I leave it as authenticating against the tomcat_user.xml file, the performance is fine. I'm guessing that when I set to authenticate against bluepages, the result of the logon request is not being cached by tomcat and thus every request to the server to build the Web UI pages results in an under the covers authentication request. Is there a setting on tomcat that I've should be using to prevent this happening so that once the initial logon has been accepted, tomcat does not need to perform further requests against bluepages?

Sadly Tomcat is known to have issues with not caching authentication
credentials when configured to use LDAP. Your alternatives are :

1) Write your own Tomcat LDAP Realm that caches correctly.
2) Don't use Tomcat for the container managed authentication. Configure
something like apache as a proxy and let it do the authentication.
3) Use another Appserver such as WAS where this is not an issue.

Richard
Jazz WebUI and Server Development

tobycorbin wrote:

I've found the cause of why the Web UI is slow. It happens when I
switch to using ldap authentication against IBM's bluepages. If I
leave it as authenticating against the tomcat_user.xml file, the
performance is fine. I'm guessing that when I set to authenticate
against bluepages, the result of the logon request is not being
cached by tomcat and thus every request to the server to build the
Web UI pages results in an under the covers authentication request.
Is there a setting on tomcat that I've should be using to prevent this
happening so that once the initial logon has been accepted, tomcat
does not need to perform further requests against bluepages?

One more thing. What authentication configuration are you using in the
WAR ? Form based or Basic. I know for sure that basic will require an
auth check for every secure request but I would export form based to
only do one auth check for the users session and depend on that from
then on.

Richard
Jazz WebUI and Server Development

Richard Backhouse wrote:

Sadly Tomcat is known to have issues with not caching authentication
credentials when configured to use LDAP. Your alternatives are :

1) Write your own Tomcat LDAP Realm that caches correctly.
2) Don't use Tomcat for the container managed authentication. Configure
something like apache as a proxy and let it do the authentication.
3) Use another Appserver such as WAS where this is not an issue.

Richard
Jazz WebUI and Server Development

tobycorbin wrote:
I've found the cause of why the Web UI is slow. It happens when I
switch to using ldap authentication against IBM's bluepages. If I
leave it as authenticating against the tomcat_user.xml file, the
performance is fine. I'm guessing that when I set to authenticate
against bluepages, the result of the logon request is not being
cached by tomcat and thus every request to the server to build the
Web UI pages results in an under the covers authentication request.
Is there a setting on tomcat that I've should be using to prevent this
happening so that once the initial logon has been accepted, tomcat
does not need to perform further requests against bluepages?

I checked the Tomcat documentation and when Form Based is configured the
Principles will be cached.

http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/authenticator/package-summary.html

Each of the standard implementations extends a common base class
(AuthenticatorBase), which is configured by setting the following
JavaBeans properties (with default values in square brackets):

* cache - Should we cache authenticated Principals (thus avoiding
per-request lookups in our underyling Realm) if this request is part of
an HTTP session?

Richard
Jazz WebUI and Server Development

Richard Backhouse wrote:

One more thing. What authentication configuration are you using in the
WAR ? Form based or Basic. I know for sure that basic will require an
auth check for every secure request but I would export form based to
only do one auth check for the users session and depend on that from
then on.

Richard
Jazz WebUI and Server Development

Richard Backhouse wrote:
Sadly Tomcat is known to have issues with not caching authentication
credentials when configured to use LDAP. Your alternatives are :

1) Write your own Tomcat LDAP Realm that caches correctly.
2) Don't use Tomcat for the container managed authentication.
Configure something like apache as a proxy and let it do the
authentication.
3) Use another Appserver such as WAS where this is not an issue.

Richard
Jazz WebUI and Server Development

tobycorbin wrote:
I've found the cause of why the Web UI is slow. It happens when I
switch to using ldap authentication against IBM's bluepages. If I
leave it as authenticating against the tomcat_user.xml file, the
performance is fine. I'm guessing that when I set to authenticate
against bluepages, the result of the logon request is not being
cached by tomcat and thus every request to the server to build the
Web UI pages results in an under the covers authentication request.
Is there a setting on tomcat that I've should be using to prevent this
happening so that once the initial logon has been accepted, tomcat
does not need to perform further requests against bluepages?