-
-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read legend JSON file from file system #4521
Comments
hi @lucadelu, one thing you can do to speed up loading is to store the PHP session data cache in a database (e.g. Redis or other). By default PHP stores the session in a file and each request can access this file one at a time, making the application "synchronous". This means that each request is not processed in parallel, but serially since each of them must access the file where the session data is stored. Storing the session cache in a DB allows to process the request in parallel. Of course this will NOT reduce the time consumption of each request but the application loads asynchronously and became "usable". In particular, |
hi @mind84,
ok, how can I set it, just changing the php.ini ?
ok, so why not read it from a file? It is a small file less than 1MB for hundred layer but it takes time |
This seems a reasonable request/solution for a problem that affects the platform since it moved to use the legend in JSON format rather than png as it did before, if I understand well the problem. I guess that the really issue is the longer time that QGIS Server takes to generate the JSON, still the suggestion seems a good solution to "solve" the problem from the LMWC side of things. Is there any room for discussion about how LMWC could help making it happen? |
From version 3.6 to 3.7 lizmap, the application's ability to satisfy the needs of public administrations that need to overlap a lot of structured technical information has disappeared. The time could be reset if the legend was created together with the project and the conf file. |
The legend depends on different things : user rights(group visibility for a layer) for the current logged user, scale visibility for rule based renderer etc It would be interesting to first compare the GetLegendGraphic in image format, in JSON format (both without Lizmap server plugin), image and JSON format again but with the plugin A server cache would make more sense than generating static files IMHO, so it's automatic, |
@Gustry Yeah, I understand that would be the ideal solution, or may be even better would be to make QGIS Server quicker. Still I think here there is really an issue for many. Maybe the plugin solution could help mitigate it on the short term; as the plugin now talks with the server, maybe it could be made smart enough to generate all the necessary legends depending on rights for groups, etc. (just rumbling here). Either way... I'm available to support any type of effort that would make possible to move on from 3.6. |
yes this is true, however you could add all layer to the json file and filter it later on the client
I tested the single request without JSON format is really faster, the mail problem I think is the base64 conversion, it is cool but take a lot of time to be done
Yeah this could be a solution too (however I think that json file is the better one because the json could change within the project) |
@Gustry seen you have added the sponsor needed label, which is great. What would be the plan? Patch QGIS Server? Cache the legends? Create static legends with the LM plugin? |
I think we could at least use etags for the |
Legends may change when you update the project, in style, in order, and when new layers are added. It would be great if the getLegendGraphic request to be cached is generated when the cfg file is saved together with the project, considering a warning when saving the project having modified the layer tree. |
@lucadelu Do you have a project to reproduce the issue? We don't have this slowness problem with clients hosted on 3Liz servers. |
Can you have some QGIS logs (with verbosity) for the |
27s / 167 nodes = 160ms per node With another test where I just take 10 nodes : 5s / 10 nodes = 500 ms per node There is something wrong server side but you'll need to monitor/benchmark as we don't have those values on our servers. |
Any help : either technically on the source code (some debug would be nice, to first check where is the bottleneck, adding some verbosity in logs, doing a "profiling" to see where the time is spent in the process) or financially if it's really an issue. We have more customers on 3.7 than 3.6 now, we didn't experience this issue so far, with such big delay. |
waiting @lucadelu for the log file, I checked the getLegendGraphic request for each layer and put the results into a CSV As you can see, the categorized and rule-categorized layers are the most time-consuming. I also noticed that when the user load is high the average request time increases |
Sorry for delay, here you are a log file when people access to the project (it is repeated twice) Responding also to @nboisteault our system is based on this compose-file, the server is quite powerfull more than 100GB ram 12 cpu and the server load is really low, I never seen it more the 5. I also customized postgresql, nginx and pyqgis-server adding more capabilities but this only mitigated a little bit but it not solved the problem. Thanks a lot |
@Gustry can you help me to provide any good profile? However if you think the creation of json file in the plugin could be a solution, I can work on the plugin side if someone will work on the lizmap client side... |
Hi there, I just clicked the link and could open your map in one second ! How did you fix your issue ? |
Dear @SecondGIS we solved the problem changing the QGIS container we switch from the py-qgis-server released from 3liz to a normal QGIS server container and everything came back to normality, so the problem seems more related to py-qgis-server than lizmap it self. |
Hum, strange... @lucadelu You are not using Py-QGIS-Server anymore ? We are going to release/promote https://github.com/3liz/py-qgis-server2 It has been totally rewritten. CC @dmarteau |
@lucadelu Please copy/paste your versions by doing a right click step on your server. (even with the actual QGIS container) |
Or @SecondGIS or @mind84 for your versions. |
@Gustry here are the versions I'm using :
Should I change py-qgis-server to the version mentioned above ? Can I change this component only and how to do it ? |
We got a lot of bottlenecks with the duo QGIS 3.28 and LWC 3.7. Lizmap Web Client >= 3.7 is better served with QGIS Server 3.34 now. |
@Gustry thanks for your advice.
@lucadelu thank you too for answering ; any tip on how to switch to normal QGis container instead of py-qgis if it is the only solution before downgrading ? |
Plz, look at the logs of the py-qgis-server container and check the response time directly from py-qgis-server. Another good way to debug issues is to send your requests directly to the py-qgis-server (as regular OWS request) and check logs and response. |
@dmarteau thanks for your answer. I am still trying to locate py-qgis-server log files. I could find |
py-qgis-server log on stderr, if your are using a Docker container inspect the container logs.
Depends on your configuration, if you are using a container: publish the port on your host and send request to this port with curl or from any browser - (the map-server container expose the port 8080 internally) |
Here is a sample of the qgis-server container log (I cannot redirect those logs to a file for now, permission issue ?) :
This part is repeated as many times as I have layers in my legend, taking a very long time in the end (this specific one was only 207ms but it can be up to 1200ms at least for other layers from what I could see). |
If I understand well, a request is sent for each layers ?
This is a rather long time of processing but this come from the Qgis internal processing of the request: i.e Qgis takes 207ms to process the request. Take care that the first time, the project need to be loaded and that may takes some time. I suspect a misconfiguration or a plugin issue. Can you run the py-qgis-server without any plugins and check for response time ? |
And send the request directly to the qgis server, don't go through Lizmap. |
Here is the result to the GetCapabilities request sent directly to qgis-server with curl (from the host where the container is running, I didn't "unplug" plugins) :
I don't know if it helps, until now I could not reproduce the whole process of the GetLegend request with curl. |
This is a specific problem with GetLendGraphic. Can you test with FORMAT=image/png instead of application/json ? |
Here is the GetLegendGraphic for one specific LAYER with FORMAT=application/json :
And now same LAYER with FORMAT=image/png :
I didn't include LIZMAP_USER and LIZMAP_USER_GROUPS parameters I guess it doesn't really matter here |
Ok, we have 1165ms for application/json and 44ms for image/png (not sure if there is some caching involved). |
FYI:
We need to investigate why Qgis has so much hard time to process application/json response |
Thanks for your attention and help. |
Can you provide the py-qgis-server image used ? (at least the version of py-qgis-server and QGIS |
command returns 3.34.8-1.8.8 |
I have no any instance running now so I cannot tell you the problem, but I had with qgis version 3.28 and 3.34 and with several py-qgis-server versions |
Issue not solved and confirmed today with steps easy to reproduce : see #4750 for more details. |
Is your feature request related to a problem? Please describe
The problem is that the getLegend request to get the icons for the legend is really time consuming (depending on layers number and style complexity it can arrive to take more than 30 seconds) and it is blocking the entire website
Describe the solution you'd like
Create the JSON file within the plugin and save the file with the .qgs and .cfg file and read from it
Describe alternatives you've considered
Put a "loader" that not permit to use the client and set a sentence like "we are loading layer and styles for a better experience" until the getlegend request
The text was updated successfully, but these errors were encountered: