We have a clustered WebSphere environment and have 4 nodes in the cluster. I am trying to find number of concurrent users that use the application. I have turned ON Performance Monitoring Infrastructure (PMI) in WAS for Servlet, JVM and Thread Pool. When I monitor using Tivoli Performance Viewer, I believe I need to look at "LiveCount" under the "Servlet Session Manager". But the count seem to be VERY high, more than what I was expecting (LiveCount shows as 80-100).
Is this the Metric to look at when trying to find the total number of concurrent users?
Does it keep true login count or is it keeping track of number of sessions?
I was told the underlying application creates only 1 session per login until it gets timeout. At which point, the user will have to login again. So to me concurrent user count = session count = this Servlet Session Live Count.
Can anyone help me here and let me know which metric I should look in PMI to get the concurrent user count? We are are WebSphere 7.x.
I believe I need to count this metric value for all 4 nodes to come up with the total concurrent users.
You may consider logged on users vs concurrent users, depending what you are really looking for.
The logged on users would be successfully authenticated and having valid session in the application, but... they may currently do nothing in your application, or abandoned your application but not logged out.
They will be represented by LiveCount - The total number of sessions that are currently live.
The concurrent users would be users simultaneously access your application. They will be represented by ActiveCount - The total number of sessions that are currently accessed by requests.
And yes, you have to sum this from all your app servers.
See also:
Servlet session counters
Related
My application currently polls database every n seconds to see if there are any new records.
To reduce network round trips, and CPU cycles of this polling i was thinking to replace it with CQN based approach where database will itself update subscribed application if there is any Commit to database.
The only problem is what if Oracle was NOT able to notify application due to any connection issue between oracle and subscribed application or if the application was crashed or killed due to any reason? ... Is there a way to know if application have missed any CQN notification?
Is polling database via application code itself the only way for mission critical applications?
You didn't say whether every 'n' seconds means you're expecting data every few seconds, or you just need your "staleness" to as low as that. That has an impact on the choice of CQN, because as per docs, https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adfns/cqn.html#GUID-98FB4276-0827-4A50-9506-E5C1CA0B7778
"Good candidates for CQN are applications that cache the result sets of queries on infrequently changed objects in the middle tier, to avoid network round trips to the database. These applications can use CQN to register the queries to be cached. When such an application receives a notification, it can refresh its cache by rerunning the registered queries"
However, you have control over how persistent you want the notifcations to be:
"Reliable Option:
By default, a CQN registration is stored in shared memory. To store it in a persistent database queue instead—that is, to generate reliable notifications—specify QOS_RELIABLE in the QOSFLAGS attribute of the CQ_NOTIFICATION$_REG_INFO object.
The advantage of reliable notifications is that if the database fails after generating them, it can still deliver them after it restarts. In an Oracle RAC environment, a surviving database instance can deliver them.
The disadvantage of reliable notifications is that they have higher CPU and I/O costs than default notifications do."
I just took over a project and noticed that they are using a DB profile as such for service accounts used for connection caching
ALTER PROFILE APP_PROF LIMIT
SESSIONS_PER_USER 100
CONNECT_TIME 640
IDLE_TIME 15
...
I believe that is why we are sometimes getting stale connections, and the "ORA-02399: exceeded maximum connect time, you are being logged off".
My question will be: For middle-tiered applications where connections are cached, are there any good reasons why such a profile would be used for service accounts with such limits ?
Personally, I'd be hard-pressed to imagine a situation where I'd want to have a middle tier service account with a connect_time or idle_time set. I suppose it's possible that someone somewhere has a reasonable reason to use such a configuration-- maybe forcing connections to be frequently recycled is the least painful way to quickly put a band-aid on a resource leak, for example, while you looked to fix the underlying code issue. But those would certainly be settings I'd look at carefully.
I've seen and heard of cases where someone wanted to set sessions_per_user for a middle tier service account where the relationships between the middle tier app server admins and the database admins were strained. Normally, the middle tier admins set a cap for the size of the connection pool in the middle tier in consultation with the DBA team that makes sure that the database can handle connection_pool_max * number_of_app_servers connections. If the middle tier admins have a history of spinning up new app server farms or bumping up the number of allowed connections in the connection pool without talking to the DBA team, the DBA team may want to set their own limit to protect the database. I'd much rather solve the communication problem than have a separate database limit.
Pardon me for my limited knowledge of Oracle Database.
following is scenario
I am currently working on application where my web application is deployed on 4 profiles of Websphere application server. these 4 profiles can together handle load of 600 users.
all these 4 profiles are pointing to single Oracle Database. in normal scenario we observe that on an average nearly 100 inactive sessions exists(yes i am aware of inactive session =sessions which are not performing any activity at that moment) but in certain scenarios we observed that these inactive session count goes up more than 150 and users are complaining slowness.
i would like to appreciate if someone help me by providing pointers for following queries
1]how to calculate require oracle session count based on connection pools considering above scenario of 4 profiles
2]how to ensure even if my oracle inactive session count reach beyond peak limit (in this case 150) application will not have any impact from slowness point of view.
In a normal enterprise application, there just one user (set in hibernate.xml or other config) and multi concurrent connection/multi concurrent session (cos its multi threaded application).
so, will those ONE user's multi session interfare each other?
Depends what you mean by "interfere".
Your middle tier connection pool will open a number of physical connections to the database. Sessions in the middle tier will request a connection from the pool, do some work, and return the connection to the pool. Assuming that your connection pool is large enough to handle the number of simultaneous calls being made from your application (based on the number of sessions, the length of time each session needs a logical connection, and the fraction of "think time" to "action time" in each session), you won't experience contention due to opening connections.
Oracle is perfectly happy to run queries in multiple sessions simultaneously. Obviously, though, there is the potential for one session to contend with another session for resources. Two sessions might contend for the same row-level lock if they are both trying to update the same row. If you have enough sessions, you might end up in a situation where CPU or RAM or I/O is being overtaxed and the load that one session creates causes performance issues in another session. Oracle doesn't care which Oracle user(s) are involved in this sort of contention-- you'd have the same potential for interference with 10 sessions all running as 1 user as you would if there were 10 sessions running as 10 different users assuming the sessions were doing the same things.
any easy to use utility/tool/profiler/benchmark that able to test what is the maximum users a web application able to support by analyzing session size , cpu speed, memory size..etc and 'PREDICT' when server is overpacked/overloaded?
Apache JMeter is a simple-to-use system that fires requests to your web server. You can try different numbers of users (i.e. sessions) with different numbers or types of requests. You could try increasing the number of users until the latency/speed of your system is unsatisfactorily slow.