December 2012

Increasing G/Netviewer performance

Note: The monitoring and tests are done on G/Netviewer 9.4 environment. But I think it is also applicable for version 10.

After some in-depth monitoring of our G/Netviewer webserver for some days/weeks. We found a performance enhancement for G/Netviewer webserver. Our server has 4 cores and 8GB memory. On our environment there are 25 to 30 concurrent users working with G/Netviewer. When we measured the CPU time in the working hours, the statistics shown that the average CPU time was round 35% and users are complaining about performance. When we monitored the server, there are on average 5 mapserver.exe running and we specified that there can be 10 maximum, but it never reaches 10.

Also our statistics show there is almost no paralleled processing of the mapserver.exe. The data shows that mapservers are randomly fired after the other process is done. Mapserver1 processing something, then mapserver2, then mapserver1 again, then mapserver3, etc.  You should expect when there are 4 mapservers.exe, those executables will fire all at once if 4 users doing a Zoom-action within G/Netviewer, but it doesn’t. Sometime we do see that 2 mapserver.exe do simultaneously fire. Or when a extra new mapserver.exe is starting then it will process the modificationlog table in parallel processing. So the server can upscale to 10 mapservers and we would expect 80% CPU time, but that is not what happening.

In our environment we do have two G/Netviewer groups (Database users) specified in the G3E_loginmapping table. (In G/Tech 10 this table is not used anymore and everything is stored in IAM database) A quarter of the total users is specified in the g3e_loginmapping table and are mapped to an advanced usergroup. All other users are mapped to default usergroup. So we have only two usergroups and two mapserver.exe processing parallel….hmm. What if we created more usergroups, would G/Netviewer do more parallel processing. The answer is YES.

The G/Netviewer webserver processing does work like a supermarket. The GNWebMgr.exe is the store manager, Mapserver.exe is a checkout lane and the a netviewer group is the cashier. In our situation we had only two cashiers working on two lanes. When the shop got more busier, the queue are getting larger and the manager opens another lane. But there are no extra cashiers, so the cashiers need to switch between lanes.  When you define more groups in the g3e_loginmapping table you get more cashiers, so more parallel processing.

What you have to do is specify all frequent users in the g3e_loginmapping table and map those users to different groups. In the webcc.web_user table you van get information which users are logged in. But every time they login the Last_license_access date will be overwritten. So you can monitor this for example once per day, for one/two weeks. To get most frequent users and divide them over different groups.

Debugging G/Technology 10.2 with Visual Studio

In an earlier post Stephan mentions that it was not possible to debug G/Technology 10.2 in “edit and continue” mode. You could only attach Visual Studio to the G3E.exe and debug. But you cannot break the code and then make a small change. For every change you need to close G3E.exe, compile your project, start G3E.exe and attach Visual Studio again. When you try to start-up the 10.2 G3E.exe in debugging mode from Visual Studio we got the following error message:

Exception start debugging g3e.exe from visualstudio

But here is the way to do that. The first thing you have to do is adjust the G3E.exe.config located in the \GTechnology\Program directory. You should add the following three lines  after the <configuration> tag.

<?xml version="1.0?" encoding="utf-8" ?>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v2.0.50727"/>

After that you must adjust the Path-variable. Or check if the path is already set in you system settings. The following path needs to exist in the path variable for a 64bit environment it is: C:\Program Files (x86)\Common Files\Intergraph. If you are using a 32bit environment you should lose the (x86) part.

Set the path variable

After setting the path, it is important to reboot the machine! Now you can fully debug your applications in Visual Studio.

If you are not an administrator on you machine and cannot change the path variable for some reason, you could also add the path to your working folder in Visual Studio. But if you have multiple projects defined in Visual Studio, you should change this for all projects.

Debug, without admin rights