Hi, Indeed, 2.14.3 shows a better performance with respect to serving database data, even without yet tuning the database server.
But, I still experience some performance issues. One, I detected when using the print composer, which is very unresponsive if there is a map object with a big database layer and redrawing is needed (without drawing the map, the UI responds fine). Second, the webclient layers load in decent time, even the "big-one". But, trying to use lizmap's "tooltip" feature on the big layer, or trying to access its attribute table is still not possible. I haven't checked the code, but maybe the way the data is being requested in these situations is suboptimal? Regards El 21/06/16 a las 11:08, Daniel Vicente Lühr Sierra escribió: > > Hi Régis, > > > El 21/06/16 a las 10:37, Régis Haubourg escribió: >> Hi, >> please see that thread [0] > Thanks. >> I suggest you first upgrade qgis server to last 2.14.3. > Ok, some weeks ago I decided to stay with 2.8 ltr, until 2.14 was more > tested, it looks like it is time for upgrading. >> Then we still have issues with big relational views, not tables - for >> first getcapabilities generation (ie first load for a session). >> You can also check your postgres logs to look at what queries are >> sent to PG and then tune your pg server based on those queries. > Ok. Although, I still need to learn how to do it ... >> Please keep us informed of how it works, we have the very same concerns. > Sure, thanks again. >> [0] >> http://osgeo-org.1560.x6.nabble.com/Server-performance-questions-td5252233i20.html#a5268188 >> >> 2016-06-21 16:29 GMT+02:00 Daniel Vicente Lühr Sierra <dl...@ieee.org>: >> >> Hi, >> >> It is my first time at setting up a postgres/PostGIS db for >> storing "serious" data (previously, I had only tested if it >> worked, with a couple of small data tables). >> >> When testing the web-client (lizmap) installation I noticed that >> the sample data loaded pretty fast, but when I tried a project >> containing 2 vector layers stored in the database, one very >> small, the second one was originally a ~30Mb shape file, the >> loading process for the 2 layers is noticeable, and reading the >> attribute table of the big vector layer (only 20 rows and 10 >> fields) takes ages (actually, I wasn't able to wait for it to load). >> >> I did some "google" research and found out that there might be >> some performance issues on qgis-server when accessing postgresql >> layer, or it could be that the performance of the db is low (I >> haven't run the tuning utility, yet). >> >> Any ideas on how to hunt down this performance issue? May it be >> an issue with the web-client, also? >> >> Btw, everything is running locally on a VM for now, although the >> final deployment will be on "real" hardware. >> >> Thanks >> >> -- >> Daniel Vicente Lühr Sierra >> IEEE Member >> IEEE Student Branch Counselor - Universidad Austral de Chile >> >> >> _______________________________________________ >> Qgis-user mailing list >> Qgis-user@lists.osgeo.org <mailto:Qgis-user@lists.osgeo.org> >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user >> >> >> >> >> -- >> Régis Haubourg >> >> Attention, changement d'adresse mail! >> Mon adresse principale devient désormais regis.haubourg at gmail.com >> <http://gmail.com> >> >> >> >> _______________________________________________ >> Qgis-user mailing list >> Qgis-user@lists.osgeo.org >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user > > -- > Daniel Vicente Lühr Sierra > IEEE Member > IEEE Student Branch Counselor - Universidad Austral de Chile > -- Daniel Vicente Lühr Sierra IEEE Member IEEE Student Branch Counselor - Universidad Austral de Chile
_______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user