Hi,
I don't know the server code very well, so I may be wrong, but I think
that making the server multithreaded rendering (MTR) capable should be
possible. And while it is certainly often possible to increase the
performance with filtering, rules and caching there are certainly also
situations where MTR can help a server to generate quick responses (many
layers, few requests).
As far as I can see, the main task would be porting the code from
QgsMapRenderer to QgsMapRendererJob and QgsMapSettings. A first step
into this direction can be found in a recently closed pull request [1],
in particular this commit [2].
Concerning parallel DB connection, there's no difference between server
and desktop use. This code is already in production use and should be
fairly robust already.
I hope I didn't base this message on wrong assumptions and hope someone
of the server developers can shed more light onto this.
Regards
Matthias
[1] https://github.com/qgis/QGIS/pull/2989/files
[2]
https://github.com/qgis/QGIS/pull/2989/commits/4cba6393544aeb23569d6c15f19e67f4ff8bf19c
On 22/04/16 17:00, Andrea Peri wrote:
I guess a more time consuming parameter is the number of vertex in the
feature involved in the map rather than the layer numbers.
A.
Il 22 apr 2016 3:27 PM, "Jörg Habenicht" <[email protected]
<mailto:[email protected]>> ha scritto:
Hi Andreas, dear list,
sorry for the warm up of this old topic.
There is in deed a need to enable multi threading in Qgis-Server.
In our company we use around 60 different layer to lay some topics on
the map. This may be an extreme example to read, but quite common
in our
environment, i.e. we can not lower this number significantly.
A warmed up QGis-Server process which already read and cached the
Configuration file qgis-xy.conf still needs around 20 seconds to
calculate the complete resulting map picture.
During this calculation there is only one thread working, serializing
the DB-requests, calculation the layer picture and mapping the picture
on the resulting picture.
The process is running on a multi core server. If we can utilize the
idle cores to do useful work, this can be an easy example to speed up
the process (significant).
I'd like to share my developing experience to do this change, but I
would need further information and some support to do some useful
patches.
I have scanned the git-Qgis sources (commit
81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable
multithreading
entry. Found QgsMapRenderer::render() because of the line "while (
li.hasPrevious() )". It seems in this loop the layers are painted in
serial onto the resulting picture.
If I can build an auto parallel computing with QtConcurrent in this
place there seems to be the most gain. I mean to parallelize the loop
with concurrent DB requests, concurrent painting in separate pictures
and in serial map the single pictures onto the result picture.
Right now I don't know if I can do DB requests in parallel, or
where the
code for database requests is buried.
And how about the calls inside the loop, are there side effects
preventing multi threading?
Do you got hints, flames or suggestions?
cu
Jörg
Am 23.02.2016 um 16:39 schrieb Neumann, Andreas:
> Hi Régis,
>
> QGIS server is single-threaded. You can't simply turn on
multi-threaded
> rendering in QGIS server. The other issue is that each Apache FCGI
> process has it's own set of cache. So if you have 5-10 parallel
Apache
> threads or processes each thread/process has it's own cache. If your
> client hits a thread that has the cache unititialized you will
have wait
> longer until this cache is fillled.
>
> I once asked Marco whether one could
>
> a) have a shared cache for all Apache threads or processes
There is no shared cache, because Apache spawns QGis-Processes
with its
own memory layout. these Processes know nothing about its
neighbor, and
you have a hard time to exchange data between all processes.
How about a scheduler, which assigns requests to warmed up
Qgis-processes?
>
> b) support multi-threaded rendering
>
> But he said it would be very complicated to implement a) and b),
if not
> impossible. Maybe other devs have other views. Note that was about 2
> years ago, when I last discussed this with Marco.
>
> ---------------------
>
> Nevertheless I believe there would be room for performance
improvements
> in QGIS server - if interested parties share their efforts (be
it dev
> time or financial resources).
>
[snip]
>
> Andreas
>
[snip]
>
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> [email protected]
<mailto:[email protected]>
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
mWerk GmbH
Dipl.-Ing. Jörg Habenicht
Landwehrstr. 76
30519 Hannover
(T) +49 511 9999 8033 <tel:%2B49%20511%209999%208033>
(F) +49 511 9999 8041 <tel:%2B49%20511%209999%208041>
(E) [email protected] <mailto:[email protected]>
Amtsgericht Hannover HRB 206522
Geschäftsführer
Reiner Brachvogel
Dennis Kornehl
_______________________________________________
Qgis-developer mailing list
[email protected] <mailto:[email protected]>
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
