Improve LogProcessingWorker._fetch_events() performances about python-logstash-async HOT 2 OPEN

Thanks for the detailed analysis and ideas.
Some comments:

• aiosqlite might only solve the problems partially. It seems to bundle open connections in a seperated thread to not open multiple connections to the database. This helps but might not be enough on high load and especially on poor IO or multiprocessing. In the end SQLite is not that ideal for high load but for most use cases of this library a good trade-off between performance, easy to use/availability and available and resilience to errors.
  Is using the in-memory database an option for your use case?
• using seperate threads for processing, storing and transmitting events might help but probably requires quite some efforts to implement properly and might still suffer from Python's Global Interpreter Lock (all threads running on the same CPU core)
• PriorityQueue was introduced in #73 to workaround high memory usage of CPython's Queue implementation. Though if there is another similar queue implementation which supports getting items in batches, that would probably help
• to address the problem that the queue never raises the Empty exception on high load and so the events from the database won't get transmitted, we could set a maximum size on the queue, use .put(block=False) and then handle the Full exception to force flushing pending events.

I think I will work soon on the last item to give the queue a maxsize and handle a full queue accordingly as this might improve the overall behavior.

Though for the other options it's unlikely I will be able to spend much time on this, as it would probably also require refactoring lots of code for a maybe only special use case.
I'd suggest to think about using the in-memory database or at least test whether it will improve the overall performance. If you like, feel free to try to port the code to aiosqlite, this sounds like relatively trivial and might already help a bit.

from python-logstash-async.