Hi,
since upgrading to 2.3.0.3, the restore browser in the web UI has become extremely slow. „Fetching path information…" takes well over 3 minutes before the version list appears, and selecting a different version triggers another multi-minute wait. This worked without noticeable delay before the upgrade.
I have already ruled out the usual causes one by one:
-
Backend: local USB 3.0 hard disk — so no network/cloud latency involved.
-
Local job database: located on an internal SSD (not on the USB disk).
-
Versions: only 6 in total, so this is not a “too many versions” situation.
-
Database state: I just ran a full Recreate (delete and repair). It took ~11 minutes, and afterwards the very next “Fetching path information” still took 3 minutes 15 seconds. A second attempt was not meaningfully faster, so it is not just a cold-cache first run.
Profiling shows that the time is not spent in the big aggregate query (that one takes ~1 second), but almost entirely in a trivial read from a temporary table:
ExecuteReaderEnumerableAsync: SELECT "Path" FROM "Filenames-137BC2FBD94A6149AB2ECC3DEE900E14" took 0:00:02:15.098
For comparison, the larger query with multiple JOINs over FilesetEntry/File/Blockset completes in about a second:
ExecuteReader: SELECT DISTINCT "A"."FilesetID", ... ORDER BY "A"."Timestamp" DESC took 0:00:00:01.021
A plain unfiltered SELECT "Path" from a temp table taking 2m15s on an SSD with only 6 versions looks like a regression in how this temporary browse table is built or read, rather than a configuration issue. Has anyone else seen this after upgrading?
Regards,
Onurbi