When switching parts (either by the keyboard or mouse)
LoKit sends a notification of the current part and
invalidates tiles. As a reaction to that the client
cancels its tiles and requests new tiles for the
new part.
Since the response to setpart is a large number
of tile cancellation and new requests, the
cost of setpart is significant (esp. with large
number of clients). To avoid that, we de-duplicate
setpart entries from the client queues so there
would be only at most one setpart (the last)
queued to be sent to the client. This minimizes
the unnecessary noise when the part changes
faster than the server and/or network can
keep up.
Change-Id: I87578004203acc63d43e6d398ca04e37f766d9ba
Reviewed-on: https://gerrit.libreoffice.org/36597
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
While message emplacement happens in the DocumentBroker poll, we
can be sure that the next iteration of the poll will call
hasQueuedWrites before polling.
To avoid degrading performance for everyone
because of a single slow/bad connection, we
send data to clients each in its own thread.
Change-Id: I6f980c25a404c4d05bcdb1979849ea3d2776c7b9
Reviewed-on: https://gerrit.libreoffice.org/31984
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The pool is checked for expansion before processing
items from the queue. By tracking the number of idle
thread (i.e. not currently sending data) we ensure
that there is at least one idle thread before
we invoke the socket.
If there is not enough idle threads at that point,
a new thread is spawned, so long as we're below the
limit. This guarantees that even if all the active
threads block on the socket, we'd always have one
more to process new data (until we reach the limit,
which is as many client connections as we have).
Technically, a single slow connection could
still monopolize all connections if there are
many messages to be sent to it. For that we'd
need to track and assign one thread per connection,
something we don't currently do.
Change-Id: Ic8b5e064da068b37bcfa773005495b198763c31d
Reviewed-on: https://gerrit.libreoffice.org/31886
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
