[Nepomuk] Review Request 108982: Reduce number of virtuoso server threads
Vishesh Handa
me at vhanda.in
Sat Feb 16 19:31:59 UTC 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108982/#review27554
-----------------------------------------------------------
I'm not too sure if 10 threads is enough. We have currently 3 ways of accessing the storage service, each of which spawns a new thread -
* QueryService
* Data Management functions
* Soprano stuff
The QueryService and DataMangagementFunctions are each allocated from a different thread pool of 10 threads. The DataManagement thread pool is never cleaned up (look at datamanagementadpator.cpp). Just these two bring us up to a total of 20 threads. Now there is the fact that each application connects to Nepomuk via the local socket which will also spawn a new thread.
Maybe 30 is a decent number?
For 4.11, we need to combine all these 3 different ways of connecting into 1. I think it would be best if we rolled our own Server/Client code instead of relying on Soprano's which is a little hard to configure according to our needs.
- Vishesh Handa
On Feb. 16, 2013, 3:43 p.m., Simeon Bird wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108982/
> -----------------------------------------------------------
>
> (Updated Feb. 16, 2013, 3:43 p.m.)
>
>
> Review request for Nepomuk and Vishesh Handa.
>
>
> Description
> -------
>
> Since soprano no longer creates a separate connection to the database for every thread, we can safely use fewer ServerThreads in virtuoso, saving memory.
>
>
> Diffs
> -----
>
> services/storage/repository.cpp 6a1d004446021b005d8e1d0ab3e70f2cf16de956
>
> Diff: http://git.reviewboard.kde.org/r/108982/diff/
>
>
> Testing
> -------
>
> Re-indexed some files, less memory is used, nothing seems to break.
>
>
> Thanks,
>
> Simeon Bird
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130216/f5097708/attachment-0001.html>
More information about the Nepomuk
mailing list