Import tuning
Five settings bound what an import run may do. All five are set installation-wide in the Extension Configuration, Admin Tools > Settings > Extension Configuration > thuecat. The fields are pre-filled with the shipped defaults, so the values in effect are visible.
Two of them, run and fetch, can also be set per import configuration
record (see Common settings). They are judgements about
one import: how long it may take and how fresh its data has to be. The HTTP settings —
read, connect and max — are Extension Configuration only; they are
a property of the installation's network, not of an import.
None of them is a site setting: they bound a run, and a run belongs to an import configuration, not to a site.
The precedence for each setting is:
- the import configuration record, where the setting exists there and is set;
- the Extension Configuration value, when set;
- the shipped default.
0 and empty both count as "not set" at every level, so a field cleared in the backend returns to
the fallback rather than meaning "unlimited".
The values are described in detail at Import tuning values.
Note
The defaults are deliberately generous rather than tuned, and the run most of all.
Upstream latency is high enough that a strict budget would abort healthy runs, so the budget is a
backstop against a hung run, not a performance target. Installations with large configurations
should expect to raise it rather than assume the default fits.
Recovered retries
A request that failed and then succeeded on a later attempt costs time but loses nothing, so it is easy to miss: the run completes, imports everything and reports success. A run against a struggling upstream then looks exactly like a healthy one.
Each run that had any such request therefore writes a single retries entry to its
import log, stating how many requests recovered and how many extra attempts they cost. It is a
notice — below warning — so it never changes whether the run is considered successful, and
the command still exits 0.
A run in which every request succeeded first time writes no entry, so the presence of one is the signal. Repeated appearances, or a rising attempt count, indicate the API is degrading.
Fetch cache
Fetched API responses are cached in the database (
cache_) for
fetch seconds, so a run that aborts part-way does not re-fetch everything when it
is started again.
To run against fresh data, bypass the cache:
vendor/bin/typo3 thuecat:importviaconfiguration <uid> --freshA bypassing run still writes what it fetches, so later runs benefit from it; only reading is skipped. Bypassing changes where responses come from, never what is imported.
An installation that configures this cache itself keeps its own backend and lifetime — the defaults apply only where nothing is configured:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['thuecat_fetchdata']