MS2 - need to manage MiServer Sessions

[woody]

Greetings, Brian.

I know we've discussed the topic of managing MiServer (v2.x) sessions before... however, I need to explore this again.

I am planning on keeping a central list of all MiServer Sessions (req.Session.ID in V2.x).

Every time a user visits my Dyalog APL v15 + MiServer 2.x I will see and record their Session ID in a central list.

If the user remains "active" ... then, of course, I want to keep their MiServer Session active as well.

But, if a user becomes inactive ... I want to KILL their MS Session.

So.. I need a way to QUERY MiServer to determine ALL ACTIVE SESSIONS (returning a vector of Session IDs.

I can compare those session IDs with my central LIST of sessions ... and determine the sessions that are inactive (no activity after "X" seconds / minutes) ...

and then I can KILL (close) any inactive sessions.

The reason I need this is I am preparing to launch a web site that I expect to be popular and receive hundreds of visits per hour.

Since MiServer consumes about 40 MB per Session ... 100 sessions x 40MB = 4GB of RAM memory.

This might be OK ... but my current testing seems to indicate that MiServer 2.0 is NOT ending any sessions ... even after 30 minutes ... and further, I see the use of the Windows Server RAM increasing ... 5 to 10MB every minute ...

I see a total memory consumed of about 1.5GB of RAM ... when I believe this is only 1 continuous session (mine).

So, how can I validate the number of active sessions ?

It would help to know that I have 'N' number of active MiServer Sessions .... eating the 1.5GB of RAM ...

or, perhaps it is just 1 runnaway MiServer Session ... eating all of the 1.5GB of RAM.

Please advise.

Thanks!

//W

[woody]

OK.. regarding the runnaway workspace usage ...

I have APL v15 set to 1500M workspace size ...

And... as the workspace is used by MiServer ...

The workspace USED continues to GROW and GROW .. until it reaches 1.5GB (1500M) bytes.

I assume that APL will perform any needed garbage cleanup at that point... keeping the max RAM used at the target 1500M bytes.

However ... I found that if I include a simple R←⎕WA in the MiPage ... APL will perform garbage cleanup at that point of the call for ⎕WA.

This forces the workspace size (and RAM used on Server) to remain at the expected size of about 40MB per APL+MiServer session.

So, I'm satisfied that APL will just use up the amount that I've allocated ... and will perform its own garbage collection, when it needs.

I'm not sure how much of this used APL workspace is SMART CACHE ... to help with overall MiServer performance ... vs. just garbage that does not add any value to performance.

This part of the question has been resolved.

However, I still need to know how to SEE the current active MiServer Sessions (e.g. list of SessionIDs) ... and have the option to KILL that session.

BUT WAIT ...

I am getting the picture.

There is only one APL Workspace running for a given instance of MiServer.

And, I assume that EACH User Session ... simply replaces some objects in the main MildServer namespace ... and/or replaces objects in any specified namespaces.

So... the actual "RAM" (memory) used for a given instances of MiServer should be very low for each Session ... only the bytes used in the workspace that are stored in that sessions' namespace.

So, with the ⎕WA garbage collection method of reducing un-used RAM (Memory) ... it now becomes much less of an issue.

Can we have 100 active MiServer Sessions running all within about 50MB of RAM TOTAL ?
How about 1000 active MiServer Sessions ... all sharing a single allocation of 50MB RAM?

Brian: Can you please comment on MiServer (V2.0 and V3.0) active sessions and use of Memory for APL for multiple Sessions?

Thanks!