[GLPI 11.0.8] Improve performance - samlSSO plugin 1.3.1

Hello!

I have a GLPI 11 instance that experiences intermittent spikes of extreme slowness. GLPI itself, the server, and the VM are all well optimized and have ample resources. Upon closer investigation, I discovered that the issue stems from the samlsso plugin. I found it striking that when running `top` on the VM, MariaDB was consuming 100% or more of the CPU, even though no other applications or background scripts were running.

By debugging the code and analyzing real-time queries during these periods of extreme slowness, I observed that for **every** load of the login page for an unauthenticated user, the response time (TTFB) was 3.11 seconds, and 8,084 SQL queries were executed.

The most repeated query patterns in that single request was:
5922 × SELECT * FROM glpi_plugin_samlsso_configs WHERE id = 1
381 × SELECT * FROM glpi_plugins WHERE id = X
308 × SELECT id FROM glpi_plugins WHERE directory = X
252 × SELECT id FROM glpi_forms_questions WHERE uuid = X
252 × SELECT * FROM glpi_forms_questions WHERE id = X
140 × SELECT id FROM glpi_plugins WHERE directory = X
140 × SELECT * FROM glpi_configs WHERE context = X AND name IN (X)

The root cause that appears to be driving the extreme slowness in environments where multiple users access GLPI (typically Production) is as follows:

The samlSSO plugin re-reads the configuration table (`glpi_plugin_samlsso_configs`) nearly 6,000 times in a single request, without caching the result in memory. Each access to the configuration—via the static getters in `src/Config.php` (`getHideLoginFields`, `getIsEnforced`, `getIsOnlyOneConfig`, `getConfigIdByEmailDomain`) and each instantiation of `src/Config/ConfigEntity.php` (constructor → `getFromDB()`, line 211)—triggers a full `SELECT` query on the table. Because these are called within loops during authentication evaluation (the `post_init` hook) and the construction of the login screen, the same query is repeated approximately 5,900 times.

Since the database is in a separate Docker container (GLPI also runs in a Docker container), each query involves a network round-trip; approximately 8,000 trivial queries add up to about 3 seconds per page load. The database responds to each query in 0 seconds; the issue is the **volume**, not the speed of individual queries.

For this reason, it is difficult to detect this slowness at first glance or during tests in local environments where few users are utilizing GLPI.

My suggested fix:

Cache the configuration for the duration of the request: load the `ConfigEntity` only once (using a static property cached by ID, or GLPI's caching layer) and reuse the instance. This would reduce the number of queries from approximately 5,900 to 1.

Environment: GLPI 11.0.8 on Docker Compose · PHP 8.4 · MariaDB 10.6 · samlSSO 1.3.1

Thanks in advance!

Start by reading src/Config.php, especially getHideLoginFields, getIsEnforced, getIsOnlyOneConfig, and getConfigIdByEmailDomain, then inspect src/Config/ConfigEntity.php around the constructor and getFromDB() at line 211. Trace their use during the post_init hook and login-screen construction, and measure queries for an unauthenticated login request. Done means the configuration is loaded once per request, repeated queries are removed, and authentication behavior remains unchanged.

Written by the indexing model from the issue text.