On Thu, Dec 22, 2016 at 5:20 PM, Matthias Kuhn <[email protected]> wrote:
> On 12/22/2016 05:06 PM, Alessandro Pasotti wrote: > > On Thu, Dec 22, 2016 at 4:10 PM, Matthias Kuhn <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Alessandro > > > > > > > > In Lyon we also talked about how to share caches between different > > > server processes, do you think that the shared memory segment > would be > > > appropriate in that case? > > > > What are the caches used for? > > > > > > mainly per-project capabilities. > > > > With QGIS 3 refactoring the QgsProject class will probably hold all the > > information we need instead of parsing the project XML like we are doing > > now, I think that we'll need to cache the QgsProject instance itself if > > we want scalability by spawning multiple server processes without the > > need to re-parse the project file, this in case we need to serve > > multiple projects of course. > > Is there some profiling information available about what's the slow part > (parsing, loading of layers, loading of print composers...)? > I think Patrick was working on profiling. BTW, the thing are probably going to change significantly after the refactoring that will use the new QgsProject. > > Saving a whole project including layers etc. in a shared memory sounds > like a challenge. > It's possibly easier to identify which parts are slow and cache them on > some backend. > If this mechanism is abstract enough to work with a file based format > like sqlite or memcached/redis, that would be awesome because QGIS > desktop could also benefit and depolyment on a server will probably be > easier if it does not depend on additional services. > -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ 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
