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.
Related
I am building a website on Django hosted at Heroku. I think at the peak time about 500-600 users can use it simultaneously. I can't figure out what is the best postgres plan.
According to this: https://elements.heroku.com/addons/heroku-postgresql#details
heroku-postgresql:standard-0 has a connection limit of 120, and
heroku-postgresql:standard-2 has a connection limit of 400.
Is it enough to have connections of 120 for about 500 users? Or it is entirely irrelevant?
Is it enough to have connections of 120 for about 500 users?
This isn't something that can be answered with certainty by anyone other than you but there's some general understanding that might be helpful here.
In most cases for basic web applications, one user on your website != one connection used for as long as they're using the app. For instance, that user might need a connection while they log in and load their profile, but not while they're simply viewing the content. While they're idling on a page, those database connections can service other users. With sensible defaults and connection pooling, 120 connections should be plenty for 500 concurrent users.
All that being said, it's on the application developer to manage database connections and pooling to ensure that this behavior is enforced. Also, this position only represents an average web app and there are certainly apps out there whose users require longer-lived connections.
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.
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
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.
I have a .NET 1.1 application hosted on two different servers, but on one of them whenever the application pool is recycled, all sessions are dropped.
Both applications are using “StateServer” session mode and as far as I could tell, both servers have exactly the same configuration and have the “ASP .NET State Server” service running.
This is a particularly troublesome issue, due to the fact that this application pool is recycling every 2-3 hours (that’s another issue that I have to solve).
Does anyone have any idea of might be causing this?
Thanks in advance,
Zeon
Monitor the number of active user sessions in each State Server instance with the perfom counter "State Server Sessions Active" to (a) ensure that both servers are using STate Server and (b) see that this really is caused by the app pool recycling.
It's a bit umclear from your question if these two apps share session state, or if they are two different applications, that could be important for the solution.