[mapguide-users] RE: Mapguide 2.2 Performance issue

Wed Sep 1 15:41:58 EDT 2010

To compare the performance what if you uploaded the SDF to the database and tried the join as a view? I know 2000 records isn't a lot, but I'm curious if it would be faster from the DB.

Dave

From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Devadoss, Bala (US)
Sent: Monday, August 30, 2010 3:56 PM
To: MapGuide Users Mail List
Subject: [mapguide-users] RE: Mapguide 2.2 Performance issue

Hi Dave,

Thanks for your insight on the some of the items that we can look in to.

What is the largest number of records involved in the joins and are they 1-1 or 1-many relationships?
We have close to 2000 records in one of the join in 1-many relationships.

Regards,
Bala
From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Dave Wilson
Sent: Thursday, August 26, 2010 6:11 PM
To: MapGuide Users Mail List
Subject: [mapguide-users] RE: Mapguide 2.2 Performance issue

Thanks for the details. That makes it much easier to provide some insight in to the issues.

I suspect that depending on the number of records involved in each of your joins, the joins are the likely culprit causing performance problems.

Having the SDF files on another server is also a big performance decrease.

The SDF files should be on a drive local to the Server install, especially since you are trying joins. whether or not the Repository is on a different drive from the SDF files may or may not make a difference as at some point the data may be cached by Windows, but if you have more than 4GB of data then that won't be the case. Separating a Data drive from the Repository would be a good idea.

To be honest I suspect if you were to upload your SDF data to SQL Server and create a view in SQL Server you would see much better performance and more consistent results than by using joins.

What is the largest number of records involved in the joins and are they 1-1 or 1-many relationships?

Regards,
Dave

From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Devadoss, Bala (US)
Sent: Thursday, August 26, 2010 4:40 PM
To: MapGuide Users Mail List
Subject: [mapguide-users] RE: Mapguide 2.2 Performance issue

Hi Dave,

Sorry for being vague in the first place. I am still a rookie to the Mapguide Open Source world.

Please find the response below for your questions.

What configuration are you using? .NET, APACHE etc..

We are using .NET with IIS7 on Windows 2008 Server 64 bit

Are you using Basic or Flexible Web Layouts? What kind of data/providers are you using?

We are using Basic Layout embedded in an aspx page.  We are using DWF and SDF files for the graphics with many of the SDF joined via the ODBC provider for dynamic access to tables in the database as the database is updated regularly.  There is 1 SDF layer, 4 DWF layers, 13 themed SDF/ODBC joined layers, and 8 labeled SDF/ODBC point layers.  The map xml is generated dynamically based on a user picked value from an aspx page.

Are you using raster imagery and if so what format?
No raster

Yes the 64 connection limit has been removed, but other components including the Berkeley database and physical disk I/O for example will limit the number of concurrent connections?
We have followed the criteria for optimized settings based on the webconfig/serverconfig document that Trevor published.

What is your hardware? How many CPUs/cores? Is everything running on the same box?
Two Virtual machines load balanced using F5 Load Balancer running MG and the .net code.  Both machines have Intel Xeon CPU 2.6ghz 2 processor with 4 GB of RAM.  SQL Server 2008 runs on a separate machine and currently the SDF files are stored on a separate machine although this was done recently to try and reduce disk IO on the server.

What are your users doing at the time things lock up?
We start at the initial screen and pick a value to load the map.  Two or perhaps three may get the map loaded, all others will sit and wait until the server ultimately fails.

Hope this will give you some information on what we did.

I appreciate your help on this.

Thanks,
Bala

From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Dave Wilson
Sent: Wednesday, August 25, 2010 4:09 PM
To: MapGuide Users Mail List
Subject: [mapguide-users] RE: Mapguide 2.2 Performance issue

You will need to provide a lot more detail than "it doesn't work" to get a useful response :)

What configuration are you using? .NET, APACHE etc..

Are you using Basic or Flexible Web Layouts? What kind of data/providers are you using?

Are you using raster imagery and if so what format?

Yes the 64 connection limit has been removed, but other components including the Berkeley database and physical disk I/O for example will limit the number of concurrent connections?

What is your hardware? How many CPUs/cores? Is everything running on the same box?

What are your users doing at the time things lock up?

Regards,
Dave

From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Devadoss, Bala (US)
Sent: Wednesday, August 25, 2010 3:02 PM
To: mapguide-users at lists.osgeo.org
Subject: [mapguide-users] Mapguide 2.2 Performance issue

Hi,

We just started testing 64 bit MGO 2.2 on windows 2008R2. When we load tested our site with 10 simultaneous users, the Mapguide service stops responding and we had to restart the service.

I thought MGO2.2 is fixed to handle around 500 connections at the same time compared to 64 connections in MGO2.1.

Please throw some ideas for the performance issue.

Thanks,
Bala

This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. The information contained in this communication may be confidential and may be subject to the attorney-client privilege. If you are the intended recipient and you do not wish to receive similar electronic messages from us in the future then please respond to the sender to this effect.

This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. The information contained in this communication may be confidential and may be subject to the attorney-client privilege. If you are the intended recipient and you do not wish to receive similar electronic messages from us in the future then please respond to the sender to this effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20100901/638ba0d2/attachment.html