The time for the bootload is measured and recorded. To have an eye on the
bootload time is motivated by: In [1] it can be seen that the bootload of the
CURRENCIES cache takes about 2/3 of the time required to initialize SearXNG::
6.068 <module> searx/webapp.py:1
└─ 6.068 wrapper pyinstrument/context_manager.py:52
├─ 5.538 init searx/webapp.py:1373
│ ├─ 4.822 initialize searx/search/__init__.py:34
│ │ ├─ 4.631 ProcessorMap.init searx/search/processors/__init__.py:47
│ │ │ ├─ 4.607 OnlineCurrencyProcessor.initialize searx/search/processors/online_currency.py:55
│ │ │ │ └─ 4.607 CurrenciesDB.init searx/data/currencies.py:25
│ │ │ │ ├─ 4.601 CurrenciesDB.load searx/data/currencies.py:34
│ │ │ │ │ ├─ 4.572 ExpireCacheSQLite.set searx/cache.py:334
In the example, the CurrenciesDB.init call takes 4.6 seconds... on my laptop,
CurrenciesDB.init takes only 0.7 seconds. The absolute numerical values depend
on external conditions, where I already find 4-5 seconds very long. Test::
$ rm /tmp/sxng_cache_*.db*
$ make run 2>&1 | grep "searx.data.CURRENCIES"
DEBUG searx.data : init searx.data.CURRENCIES
DEBUG searx.data : init searx.data.CURRENCIES added 9089 items in 0.7623255252838135 sec.
[1] https://github.com/searxng/searxng/issues/5223#issuecomment-3323083411
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Depending on the respective runtime behavior, it could happen that the initial
loading of the DB tables in the cache was performed multiple times and in
parallel. The concurrent accesses then led to the `sqlite3.OperationalError:
database is locked` exception as in #4951.
Since this problem depends significantly on the runtimes (e.g., how long it
takes to retrieve the content for a table), this error could not be observed in
all installations.
Closes: https://github.com/searxng/searxng/issues/4951
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
