How many webspeed users per agent
- Thread starter jerrys
- Start date
You probably need some session manegement to make a legitimate guess....
We store session id, time of the request date or hte request in a session table. So by reading that table we know approximaltely how many users are on-line. I say approximately because it is impossible to tell wether a user will press the button again or not. So a sessions becomes only idle after some time which you decide....
During that time, the user can already have closed the browser, but you will only know the session becomes idle if the idle-time has been reached.....
Why you want to know? Is it for licensing issues?
A webspeed agent can handle on average maximal approximately 12 requests per second. ( all depends on request time, but hey, I just make a guess
).
HTH,
Casper.
We store session id, time of the request date or hte request in a session table. So by reading that table we know approximaltely how many users are on-line. I say approximately because it is impossible to tell wether a user will press the button again or not. So a sessions becomes only idle after some time which you decide....
During that time, the user can already have closed the browser, but you will only know the session becomes idle if the idle-time has been reached.....
Why you want to know? Is it for licensing issues?
A webspeed agent can handle on average maximal approximately 12 requests per second. ( all depends on request time, but hey, I just make a guess
).HTH,
Casper.
How do I count sessions for Webspeed users?
Your right Casper, it is for licensing issues, but not for Progress products. The licensing issue is for the application Progress is embedded into. The product provider licenses their product by concurrent users, including users accessing the application via the web. Now, knowing that all connections through Webspeed is through Agents, We have questioned their "utility" that counts users as we have proven it does "NOT" work. However, being good citizens of the Progress community, we want to be sure that we do not violate their license so how can we legitimately "count" connections through the web as concurrent users. I looked at the connections but they do not count each user, only connections to the database. Here is a snip of the code. What "sessions" are you talking about?
for each _connect no-lock
where _connect-disconnect <> ? and
(_connect-type = "REMC" or _connect-type = "SELF").
cnt = cnt + 1.
display stream logfile
_connect-Name
_connect-Device format "x(15)"
_connect-Usr
_connect-Type
_connect-time
_connect-Pid
with frame a down .
end.
put stream itocnt cnt.
display stream logfile
Your right Casper, it is for licensing issues, but not for Progress products. The licensing issue is for the application Progress is embedded into. The product provider licenses their product by concurrent users, including users accessing the application via the web. Now, knowing that all connections through Webspeed is through Agents, We have questioned their "utility" that counts users as we have proven it does "NOT" work. However, being good citizens of the Progress community, we want to be sure that we do not violate their license so how can we legitimately "count" connections through the web as concurrent users. I looked at the connections but they do not count each user, only connections to the database. Here is a snip of the code. What "sessions" are you talking about?
for each _connect no-lock
where _connect-disconnect <> ? and
(_connect-type = "REMC" or _connect-type = "SELF").
cnt = cnt + 1.
display stream logfile
_connect-Name
_connect-Device format "x(15)"
_connect-Usr
_connect-Type
_connect-time
_connect-Pid
with frame a down .
end.
put stream itocnt cnt.
display stream logfile
Hi jerrys,
In the _connect you find the actual connections to the database. But since webspeed is running stateless (I assume, otherwise you wouldn't have a problem) each agent (luckily ) doesn't represent a 'connected' user.
An agent connected can handle some 12 requests per second (well that's what progress says in OE10 for licensing purposes, but that is a whole different story) so 5 agent can represent at max 60 concurrent users.
What I mean with session is that we keep an internal table (progress tables) which handles the sessions from the internet. For each session a record is made and with each request the request time and date is updated. So in the product we have, you can say for instance idle time = 900 sec. Which means if after 15 min (900sec) the users didn't do a request the sessions becomes idle. In practice it means the user has to log in again and the session is cleaned up.
With a situation like that, you can estimate the number of concurrent users:
For each <sessiontable) where requesttime < time -idle-time:
count the records.
end.
Again I say estimate because a user could have closed the browser with the famous little cross at the right top of the page.....
If you don't have session tables then it's virtual impossible to guess the number of concurrent users since the webspeed agents doesn't know (or care) where the request came from. (well that's not totally true but true enough).
Otherwise you have to guess by looking how many agents are running and why they are running. I mean are there many agents because of long requests or because of many requests from many users....
There is no good way with web applications to determine the session has ended unless the users uses the log off button, but most time the little cross at the top of the page is much more interesting to push.
There utility has to consist of some session table mechanism as I described I suppose... So maybe you can find the tables and do the math yourselfs?
HTH,
Casper.
In the _connect you find the actual connections to the database. But since webspeed is running stateless (I assume, otherwise you wouldn't have a problem) each agent (luckily
) doesn't represent a 'connected' user. An agent connected can handle some 12 requests per second (well that's what progress says in OE10 for licensing purposes, but that is a whole different story) so 5 agent can represent at max 60 concurrent users.
What I mean with session is that we keep an internal table (progress tables) which handles the sessions from the internet. For each session a record is made and with each request the request time and date is updated. So in the product we have, you can say for instance idle time = 900 sec. Which means if after 15 min (900sec) the users didn't do a request the sessions becomes idle. In practice it means the user has to log in again and the session is cleaned up.
With a situation like that, you can estimate the number of concurrent users:
For each <sessiontable) where requesttime < time -idle-time:
count the records.
end.
Again I say estimate because a user could have closed the browser with the famous little cross at the right top of the page.....
If you don't have session tables then it's virtual impossible to guess the number of concurrent users since the webspeed agents doesn't know (or care) where the request came from. (well that's not totally true but true enough).
Otherwise you have to guess by looking how many agents are running and why they are running. I mean are there many agents because of long requests or because of many requests from many users....
There is no good way with web applications to determine the session has ended unless the users uses the log off button, but most time the little cross at the top of the page is much more interesting to push.
There utility has to consist of some session table mechanism as I described I suppose... So maybe you can find the tables and do the math yourselfs?
HTH,
Casper.
Your right about the session table. They have one, but unfortunately we have tested their "login / logout" scenario and true enough, if a user presses the interesting crosshairs in the corner, their session monitor knows nothing out it. ARG!!! Having done this Progress stuff for nearly 20 years, this is the only thing I have found I can't do with Progress. Too bad some Application providers don't follow Progresses licensing scheme like the rest of the market... Thanks Casper. points assigned.
Well,
One thing about that. Progress handles in OE10 webspeed license the same as appserver license since they are one and the same mechanism (well in fact it's the same license). The construct of named users however can be a problem then...... (considering how many internet connections there are).
So in OE10 you have to make arrangmenets with Progress regarding those licenses....
You should be glad that the company didn't use the concept of named users......
Casper.
(Note to self: Buy 3,000,000,000 licenses :awink: )
One thing about that. Progress handles in OE10 webspeed license the same as appserver license since they are one and the same mechanism (well in fact it's the same license). The construct of named users however can be a problem then...... (considering how many internet connections there are).
So in OE10 you have to make arrangmenets with Progress regarding those licenses....
You should be glad that the company didn't use the concept of named users......
Casper.
(Note to self: Buy 3,000,000,000 licenses :awink: )