<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi<br>
      <br>
      Yes, rendering multithreaded in the server is possible (but needs
      some work of course). <br>
      <br>
      What I said was that the effect is probably not that big, because
      the fcgi module already distributes concurrent requests to
      different processes. In the special case of very rare requests to
      the server, it might have a considerable effect. But even then it
      is very unlikely that a 20sec request will render in 1-2 sec (what
      you need for interactive web maps).<br>
      <br>
      Regards,<br>
      Marco<br>
      <br>
      On 22.04.2016 17:20, Matthias Kuhn wrote:<br>
    </div>
    <blockquote cite="mid:571A4135.3000205@opengis.ch" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi,<br>
      <br>
      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).<br>
      <br>
      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].<br>
      <br>
      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.<br>
      <br>
      I hope I didn't base this message on wrong assumptions and hope
      someone of the server developers can shed more light onto this.<br>
      <br>
      Regards<br>
      Matthias<br>
      <br>
      [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://github.com/qgis/QGIS/pull/2989/files">https://github.com/qgis/QGIS/pull/2989/files</a><br>
      [2]
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/qgis/QGIS/pull/2989/commits/4cba6393544aeb23569d6c15f19e67f4ff8bf19c">https://github.com/qgis/QGIS/pull/2989/commits/4cba6393544aeb23569d6c15f19e67f4ff8bf19c</a><br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 22/04/16 17:00, Andrea Peri wrote:<br>
      </div>
      <blockquote
cite="mid:CABqTJk9ZjHc7q5d7khni+yCpiwjvJ+UMGE_P3xEfQs_gfE-vBA@mail.gmail.com"
        type="cite">
        <p dir="ltr">I guess a more time consuming parameter is the
          number of vertex in the feature involved in the map rather
          than the layer numbers.</p>
        <p dir="ltr">A.<br>
        </p>
        <div class="gmail_quote">Il 22 apr 2016 3:27 PM, "Jörg
          Habenicht" <<a moz-do-not-send="true"
            href="mailto:jh@mwerk.net">jh@mwerk.net</a>> ha scritto:<br
            type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
            Andreas, dear list,<br>
            <br>
            sorry for the warm up of this old topic.<br>
            <br>
            There is in deed a need to enable multi threading in
            Qgis-Server.<br>
            <br>
            In our company we use around 60 different layer to lay some
            topics on<br>
            the map. This may be an extreme example to read, but quite
            common in our<br>
            environment, i.e. we can not lower this number
            significantly.<br>
            <br>
            A warmed up QGis-Server process which already read and
            cached the<br>
            Configuration file qgis-xy.conf still needs around 20
            seconds to<br>
            calculate the complete resulting map picture.<br>
            <br>
            During this calculation there is only one thread working,
            serializing<br>
            the DB-requests, calculation the layer picture and mapping
            the picture<br>
            on the resulting picture.<br>
            The process is running on a multi core server. If we can
            utilize the<br>
            idle cores to do useful work, this can be an easy example to
            speed up<br>
            the process (significant).<br>
            <br>
            I'd like to share my developing experience to do this
            change, but I<br>
            would need further information and some support to do some
            useful patches.<br>
            <br>
            I have scanned the git-Qgis sources (commit<br>
            81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable
            multithreading<br>
            entry. Found QgsMapRenderer::render() because of the line
            "while (<br>
            li.hasPrevious() )". It seems in this loop the layers are
            painted in<br>
            serial onto the resulting picture.<br>
            If I can build an auto parallel computing with QtConcurrent
            in this<br>
            place there seems to be the most gain. I mean to parallelize
            the loop<br>
            with concurrent DB requests, concurrent painting in separate
            pictures<br>
            and in serial map the single pictures onto the result
            picture.<br>
            <br>
            Right now I don't know if I can do DB requests in parallel,
            or where the<br>
            code for database requests is buried.<br>
            And how about the calls inside the loop, are there side
            effects<br>
            preventing multi threading?<br>
            <br>
            <br>
            Do you got hints, flames or suggestions?<br>
            <br>
            <br>
            cu<br>
            Jörg<br>
            <br>
            <br>
            Am 23.02.2016 um 16:39 schrieb Neumann, Andreas:<br>
            > Hi Régis,<br>
            ><br>
            > QGIS server is single-threaded. You can't simply turn
            on multi-threaded<br>
            > rendering in QGIS server. The other issue is that each
            Apache FCGI<br>
            > process has it's own set of cache. So if you have 5-10
            parallel Apache<br>
            > threads or processes each thread/process has it's own
            cache. If your<br>
            > client hits a thread that has the cache unititialized
            you will have wait<br>
            > longer until this cache is fillled.<br>
            ><br>
            > I once asked Marco whether one could<br>
            ><br>
            > a) have a shared cache for all Apache threads or
            processes<br>
            <br>
            There is no shared cache, because Apache spawns
            QGis-Processes with its<br>
            own memory layout. these Processes know nothing about its
            neighbor, and<br>
            you have a hard time to exchange data between all processes.<br>
            How about a scheduler, which assigns requests to warmed up
            Qgis-processes?<br>
            <br>
            ><br>
            > b) support multi-threaded rendering<br>
            ><br>
            > But he said it would be very complicated to implement
            a) and b), if not<br>
            > impossible. Maybe other devs have other views. Note
            that was about 2<br>
            > years ago, when I last discussed this with Marco.<br>
            ><br>
            > ---------------------<br>
            ><br>
            > Nevertheless I believe there would be room for
            performance improvements<br>
            > in QGIS server - if interested parties share their
            efforts (be it dev<br>
            > time or financial resources).<br>
            ><br>
            [snip]<br>
            ><br>
            > Andreas<br>
            ><br>
            [snip]<br>
            ><br>
            ><br>
            ><br>
            ><br>
            > _______________________________________________<br>
            > Qgis-developer mailing list<br>
            > <a moz-do-not-send="true"
              href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
            > List info: <a moz-do-not-send="true"
              href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
              rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
            > Unsubscribe: <a moz-do-not-send="true"
              href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
              rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
            ><br>
            <br>
            --<br>
            <br>
            mWerk GmbH<br>
            Dipl.-Ing. Jörg Habenicht<br>
            Landwehrstr. 76<br>
            30519 Hannover<br>
            (T) <a moz-do-not-send="true"
              href="tel:%2B49%20511%209999%208033"
              value="+4951199998033">+49 511 9999 8033</a><br>
            (F) <a moz-do-not-send="true"
              href="tel:%2B49%20511%209999%208041"
              value="+4951199998041">+49 511 9999 8041</a><br>
            (E) <a moz-do-not-send="true" href="mailto:jh@mwerk.net">jh@mwerk.net</a><br>
            Amtsgericht Hannover HRB 206522<br>
            Geschäftsführer<br>
            Reiner Brachvogel<br>
            Dennis Kornehl<br>
            _______________________________________________<br>
            Qgis-developer mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
            List info: <a moz-do-not-send="true"
              href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
              rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
            Unsubscribe: <a moz-do-not-send="true"
              href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
              rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Qgis-developer mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
List info: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Qgis-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a class="moz-txt-link-abbreviated" href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a class="moz-txt-link-freetext" href="http://www.sourcepole.ch">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
  </body>
</html>