This question has been asked and somewhat answered, but not as thoroughly as
I currently need. I am hoping it can be revisited for the benefit of myself
I recognize that a simple method to examine the number of sessions is to
view the contents of /Server/Repositories/Session, but I can also see there
is not a direct 1-1 relationship. During testing, I am able to delete files
in that folder without causing said session to trigger a timeout error, and
my selection changes do not affect the file timestamps. From other reading
it is evident that some session data is stored in memory
or in a dbxml file.
I am running into a problem where the Mapguide server fails to create a new
session during usage with 100+ active sessions, even though the upper limit
on SessionRepositoriesLimit does not appear to be reached (I set it at 500).
Available RAM and CPU have plenty of room as well.
I have implemented suggestions from this blog post
https://themapguyde.blogspot.com/2012/06/thoughts-on-mapguide-scalability.html with some success in the past, but I cannot identify the root cause of the
current problem. Ideally I want the freedom to scale as far as computing
resources can take, but error logs do not yield any helpful information on
improving the Mapguide server stability under the current loads. We are
experiencing MG crashes once or twice a week.
So my question is two-fold:
1.) Is there a method to enumerate the number of active sessions that the
server actually sees? It is performing a sweep to detect session activity
somewhere, but that does not appear to be based on the file timestamps in
/Repositories/Session/. Ideally, a method to display the active session
count is available in the PHP class library.
2.) On the condition that my number of sessions is not the underlying
problem, is there any other insight on scaling Mapguide to accommodate 1,000
or even 10,000 active users on an appropriate server setup? I see
ClientConnections > MaxConnections displays a maximum of 1024 in the
comments, does this represent a hard upper limit for now?
Critical properties of this data are listed below, and can be used to monitor Mapguide's performance and resource limitations. In particular, the "TotalConnectons" appears to correlate with the number of sessions, growing as new sessions are created and reducing as they are destroyed.
Continuing investigations, I can see that the GetInformationProperties()
primarily returns everything already output in the Performance log, and that
the TotalActiveConnections does not actually reduce when sessions are
destroyed. Instead, it appears to be a running tally of all connections made
since the server was last reset.
I noticed that CachedDroppedEntries was a high and ever-increasing number,
so I set CacheSize in serverconfig.ini to 5,000, the maximum outlined in the
comments. Since last reset, the CachedDroppedEntries has remained at 0,
instead of rapidly increasing into the thousands as it has done previously.
However I am still at a loss to access the number of sessions stored in
memory as MapGuide sees it.
If you use Maestro, which I am assuming you do, in the Tools menu you have a
"Server Status" tool which does show an Active Connections property. The
totals are, as you said, since the last server restart. So that can still
give you some live information about what is going on.
In your specific case, it might be worthwhile to use the map profiler in the
administrator to check if perhaps a very specific layer of yours is slow,
which tends to start queuing up operations and slowly degrading
Thanks Benoit, I will look into those tools. We utilize Maestro a great deal
and have built an adjunct resource diagnostics tool as well.
I have narrowed in on a major problem that was hopefully the primary cause
of our server connection faliures.
One of our layers utilizes a WMS feed of externally-hosted raster data. In
my experience, any WMS service is slow and prone to go offline
unpredictably. In this case, the aforementioned WMS server has recently
failed to respond with great frequency.
Whenever an end user was attempting to access that layer, the
TotalActiveConnections would increase, presumably because their request was
not being fulfilled. And even though our SessionRepositoriesLimit was set
high, both our Client> and Site>MaxConnections were still rather low. I
believe that in instances when the WMS was failing, the
TotalActiveConnections was exceeding those serverconfig.ini limits, sand new
connections were refusing.
I removed that WMS layer and also increased our MaxConnections for both
Client and Site to be the maximum listed of 1024. Based on current use, it
looks like around 100 active sessions from our users may utilize around
10-20 active connections at any given point under normal loads. So from this
data alone I might anticipate that MapGuide can accommodate around 5k to 10k
active user sessions before approaching the 1024 MaxConnections limit,
assuming computing resources are sufficient and no other unidentified
I am hopeful that my changes will provide a more stable server map
experience. If so, then these projected upper limits on user sessions will
provide us sufficient room to grow our usage for the foreseeable future.
Hopefully the 1024 MaxConnections maximum can be increased on future
releases of MapGuide.
One other note, the serverconfig property FDOConnectionTimeoutCustom =
OSGeo.WMS:120 means that each of these failed WMS requests was taking 2
minutes to finally timeout. That is actually a reasonable number, but during
those 2 minutes the TotalActiveConnections were likely increasing as zooms
and pans were continuing to occur without any WMS response.