Skip to Content

How to Limit the Number of Users Logged on to your Portal / WAS

One of the common issues many portal projects have is to limit the number of users who can be logged on to the portal / WebAS (e.g. for WebDynpro) at any one time.  This is normally due to the fact that the hardware can cope with normal everyday load, but is unable to cope with extreme peaks, such as input of timesheets or viewing of payslips.  First of all I will explain how the Java Web Application Server works in a normal scenario.  When a user first logs on, your network switch should identify that the user does not have an existing session and load balance them to a WAS java dispatcher.  The dispatcher will then load balance the new user session to one of it’s server nodes.  For future requests (within the same session), the network switch should identify that you have an existing session and pass it to the same dispatcher (known as stickiness).  The dispatcher will in turn pass it to the same server node.  So in theory once you have a session, you should be sent to the same server node.  A service running on each server node is the Security Provider Service.  When you use the Visual Administrator tool, go into Server -> Services -> Security Provider.  In here it is possible to see the login sessions for that server node.  It is possible to set properties of the Security Provider.  To limit the number of users, we use two properties, MaxUsersCount and SessionExpirationPeriod.  MaxUsersCount sets the number of users per server node, not per system.  So simply divide the total number of users by the number of server nodes you are using.  SessionExpirationPeriod sets how long a user session remains on the server node if the user does not log off correctly (i.e. they click on X and DSM does not work correctly).  It is very important that this is set else you will get ‘user creep’, i.e. the number of users reported to be logged on in the security provider is more than the actual number, so the limit will be reached early.  This parameter is set in seconds and as default (on 640) is around 28 hours.  So this must be reduced to 12 hours or less.  More information on these parameters can be found on So What Happens When The Limit is Reached? When the limit is reached it returns the portal / WAS logon page.  Unfortunately, there is currently a bug where it does not display an error message (due to be fixed in a later SPS).  So if you enter a correct user id and password, it will just return the logon page again.  I would recommend changing the logon screen a bit to have some sort of message to users (there are lots of blogs / forum messages explaining how to do this).  Users who have a current session will not be affected as they already have a session on the server node.  Obviously the fact that it is just returns the logon page (including when using SSO on to the portal when using SPNego) is not ideal, but the opposite is that the system crashes due to too many users.  Another recommendation is to have one instance separate from the network switch load balancing (e.g. the central instance).  The reason for this is so that administrators can still log on to this when all other instances are busy.  It is not the perfect solution, but does the job.  A neater solution could possibly be done by writing your own login module.  So I hope this helps all of you who have busy portals and Java WAS systems which need to be protected.
You must be Logged on to comment or reply to a post.
    • This is what I saw in to control the Max Number of user connections :

      You can limit the maximum number of user connections below the number that the system has calculated. To do so, proceed as follows:
      Start the J2EE Engine Visual Administrator.
      Choose Dispatcher ® Kernel ® Connections Manipulator ® Properties tab.
      Modify the value of the MaxParallelUsers property.

      So what is the diferrence in changing the values in Dispatcher rather than in the Server Node

      Jonu Joy

      • Jonu,

        I’ve spoken to my collegues regarding this as it turns out they tested it.  Unfotunately when the limit of MaxParallelUsers is hit it in effect causes a DoS effect for ALL users as it queues up all connections.  So the user experience is even worse.  The method in the blog only blocks new users.


  • Nice Blog with Thanks.

    I have the similar situation.

    For MaxUsersCount: e.g. 100 users, and to pop up a Warning Message that Max Users Reached and Pls try again later.

    Wonder, if SAP or anyone could provide small patch or java codes or advance correction to the logon module while waiting for next SP ???

    Appreciate that, since it could be a simple codes.

    Steven Cheong

    • We managed to write some advance correction in sps9 to achieve that.

      Beside that, would like to update that a possible site effects of high phantom sessions or maxuserscount reached at night time (in fact, low VPN users) which can be resolve as below and the RTC generate some phantom sessions. Thks.

      1) Disabling the Application Sharing Server (RTC) 
      2) Note 864801 – Removing RTC pars

      Steven Cheong

  • I have a question on how this all works. I was under the impression from researching the portal activity reports that the portal only knows when someone logs in, not who’s logged in right now nor when someone logs out.


    “The portal doesn’t know how many people are currently logged on. It is stateless, and although it knows you have logged on, it can’t tell if you’ve logged off.”

    Does this mean that each server node does know how many users there are? Is there any way to pass that info to the portal for monitoring?

    • Well – it knows if you have a session as you create one when you log on.  If you go to the security provider (in Visual Admin) and then login sessions, it has a list of sessions.  However, this relies on the DSM (also known as Session Release Agent SRA) logging you off.  This is a little bit problematic at times.  You can monitor that list of sessions though and see users log on and log off.