Query.php performance issues.

[Tómas Guðmundsson]

Some javascript/style in this post has been disabled (why?)

Hi all.

 

I was wandering if you guys could give me some tips. It is quite a lot and we are trying to find out where

the bottleneck for Query.php is resulting in 8-10 seconds replies from the Server. This

happens when a single ´parcel´or property in the map is selected. I did see in the php file

that it is using an XML reader and parsing every layer is a lot slower than querying a

database. Is it feasible to pump all the data from the map into a sql server and query that

instead? I would like to point out that querying Sheboygan map takes about 1-2 seconds

when selecting a feature in the map and I personally believe tha tit should never take

more than 1 or 2 seconds, else the user will be eery and annoyed.

 

Regards,

Tómas

_______________________________________________
fusion-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-users

[zspitzer]

>Is it feasible to pump all the data from the map into a sql server
> and query that instead?

yep, I think that SDF's don't have indexes and involve a full table
scan where as your db server does

z


--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
fusion-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-users

[Tómas Guðmundsson]

Hi zac.

Ok. But the thing I found that slowed things down was that Query was in fact executed 30 times. It has a HUGE for loop that reads and parses xml for every layer and is in my opinion poorly constructed. If it is the only way then we must take another route. One way is by NOT selecting every layer as is done in Select.js, options.layers parameter for the query remains null and results in unintuitive behavior.

If I click on a house on my map, the land / property underneath it get's selected as well. What we have realized is that it is completely redundant searching for a feature and selecting it when it is obvious there is no layer beneath it. Why would I want to spend resources searching in a layer called "streets" when I click on an area that looks like "water"?

Pseudo code like this needs to be implemented:

 Have point P where clicked
  What layers exist on this point.
   Which of them are selectable.
    Which of them are visible.
     What one is hierarchically the topmost one.
        Select that one.

It is kind of a weird thing just selecting everything once a point is clicked. I think it would benefit the whole Fusion community if this would be solved and we here in Snertill are working on it as we speak, hopefully finding a solution.

Kind regards,
Tómas.

-----Original Message-----
From: Zac Spitzer [mailto:[hidden email]]
Sent: 14. júlí 2008 10:43
To: Tómas Guðmundsson
Cc: [hidden email]
Subject: Re: [fusion-users] Query.php performance issues.

>Is it feasible to pump all the data from the map into a sql server
> and query that instead?

yep, I think that SDF's don't have indexes and involve a full table
scan where as your db server does

z


--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
fusion-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-users