Update README.md
Costa Tsaousis committed
Oct 7, 2023 at 23:06 UTC
d766977fbb0c317abe60adc25d6fd4ce0ed44fde
1 file changed
+19
-8
collectors/systemd-journal.plugin/README.md
+19
-8
@@ -197,16 +197,27 @@ of the files into memory, to satisfy each query.
197
198
On logs aggregation servers, the performance of the queries depend on the following factors:
199
200
-1. The number of files involved in each query. This is why we suggest to select a source when possible.
201
-2. The speed of the disks hosting the journal files. Journal files perform a lot of reading while querying, so the fastest the disks, the faster the query will finish.
202
-3. The memory available for caching parts of the files. Increased memory will help the kernel cache the most frequently used parts of the journal files, avoiding disk I/O and speeding up queries.
203
-4. The number of filters applied. Queries are significantly faster when just a few filters are selected.
200
+1. The **number of files** involved in each query.
201
205
-In general, for a faster experience, keep a low number of rows within the visible timeframe.
202
+ This is why we suggest to select a source when possible.
203
+
204
+2. The **speed of the disks** hosting the journal files.
205
207
-Even on long timeframes, selecting a couple of filters that will result in a few dozen thousand log entries
208
-will provide fast / rapid responses, usually less than a second. To the contrary, viewing timeframes with millions
209
-of entries may result in longer delays.
206
+ Journal files perform a lot of reading while querying, so the fastest the disks, the faster the query will finish.
207
+
208
+3. The **memory available** for caching parts of the files.
209
+
210
+ Increased memory will help the kernel cache the most frequently used parts of the journal files, avoiding disk I/O and speeding up queries.
211
+
212
+4. The **number of filters** applied.
213
+
214
+ Queries are significantly faster when just a few filters are selected.
215
+
216
+In general, for a faster experience, **keep a low number of rows within the visible timeframe**.
217
+
218
+Even on long timeframes, selecting a couple of filters that will result in a **few dozen thousand** log entries
219
+will provide fast / rapid responses, usually less than a second. To the contrary, viewing timeframes with **millions
220
+of entries** may result in longer delays.
221
222
The plugin aborts journal queries when your browser cancels inflight requests. This allows you to work on the UI
223
while there are background queries running.