Just my 5 cents ..

In my opinion, we should think about where the bottlenecks are and how we can improve the situation. The attempts to use an asynchronous model for the core have not yet shown the desired results.

Modern Python's asynchronous features can significantly improve performance for I/O-bound tasks on a single thread.

Aspect performance: the bottleneck are the response times when querying the origin engines

This means we don't have to spin up many workers to serve a public instance (since a worker uses ~150MiB memory on its own, this will quickly escalate to a scalability issue).

Aspect footprint: we have components in the core that we could outsource to separate services ... I can think of two topics off the top of my head (there will certainly be more).

• https://github.com/searxng/fasttext-predict
• https://github.com/searxng/searxng/blob/master/searx/data/engine_descriptions.json

Engine descriptions can be placed in the redis DB and for fasttext-predict a local service can be installed.

Aspect performance: catchphrase "lazy evaluation" .. by example "engine description" is needed only rare.

These are a few topics that come to my mind spontaneously ... without having done any deeper analysis ... but I think it would be important that we think in this somewhat differentiated direction, because I believe that we will not find the holy grail that will solve all our problems.

async is slow in Python; the HTTP/2 protocol is complex to the point where the CPU usage starts to be a problem with the image proxy (yes, with async code. Actually I think sync code might be faster). I've made numerous attempts to speed up the thing without success (for example, dalf/hpack_nghttp2 , and another attempts using Cython, mypyc, etc...)

Shall we offload the image proxy to Morty and ditch the built-in image_proxy entirely? In my opinion, Python is not the best fit for this scenario.

async is cooperative multitasking: if an engine is CPU intensive, everything will slow down. To avoid this, some shenanigan are required, like use a threadpool to call lxml for large document (I remember it improved the response time).

lxml uses libxml & libxslt under the hood, which is a rather advanced XML toolkit. Since we are only doing queries, we could potentially switch to a faster XML parsing library like https://github.com/zeux/pugixml which is 3-5x faster in general.

Regarding memory footprint: #2633

Is there any prior profiling work on this? I'm relatively new to this codebase, so I would appreciate it if somebody could point me out, thanks!

lxml uses libxml & libxslt under the hood, which is a rather advanced XML toolkit. Since we are only doing queries, we could potentially switch to a faster XML parsing library like https://github.com/zeux/pugixml which is 3-5x faster in general.

why not / but what's the gain? ..

the bottleneck are the response times when querying the origin engines

Shall we offload the image proxy to Morty and ditch the built-in image_proxy entirely?

There were multiple issues with the setup of Morty, that's why a good enough solution was embedded.

In my opinion, Python is not the best fit for this scenario.

Even if I guess the answer, may I ask why?

Since we are only doing queries, we could potentially switch to a faster XML parsing library like https://github.com/zeux/pugixml which is 3-5x faster in general.

I don't know pugixml, however HTML5 does not seems to be supported: zeux/pugixml#116 (comment)

Is there any prior profiling work on this? I'm relatively new to this codebase, so I would appreciate it if somebody could point me out, thanks!

I've done some profiling with tracemalloc but I haven't published them. As far I remember, the 150Mo split into:

• translations (60Mo)
• data from searx.data (actually, the huge datasets can be stored as SQLite files)
• other stuff

The relevant part of the code to check: