Maximum execution time exceeded ModuleControllerRegisterPass: PrestaShop 9 administravimas neatsidaro

Kas nutiko#

Pirmą kartą atidarant administravimą po įdiegimo, atnaujinimo ar cache išvalymo, PrestaShop sukuria Symfony paslaugų konteinerį ir įrašo jį į var/cache. Vienas šio darbo žingsnių, ModuleControllerRegisterPass, pereina visus įdiegtus modulius ir atidaro kiekvieną juose esantį .php failą, taip pat ir vendor aplankuose, kad rastų modulių administravimo valdiklius.

Failų daug. Mūsų bandomosios PrestaShop 9.2 parduotuvės modules aplanke – apie 27 000 PHP failų, o vienas mokėjimų modulis, pavyzdžiui, ps_checkout, atsineša daugiau nei 2 000.

Įprastame serveryje visa tai užtrunka kelias sekundes: ta pati bandomoji parduotuvė su tuščiu cache administravimą atidarė maždaug per 10 sekundžių. Kai kažkas kiekvieną failo skaitymą sulėtina, užklausa pasiekia max_execution_time, PHP sustoja konteinerio kūrimo viduryje su šiuo pranešimu, o kita užklausa viską pradeda iš naujo. Administravimas taip ir neatsidaro.

max_execution_time didinimas padeda tik tada, kai kūrimas tik šiek tiek per lėtas. Skaičius pranešime rodo tikrai pritaikytą ribą. Jei ten jau 180 ar 600 sekundžių, o klaida lieka, ieškokite, kas lėtina failų skaitymą.

Dažniausios priežastys#

• Parduotuvė yra OneDrive sinchronizuojamame aplanke. Windows kompiuteryje toks dažnai būna Dokumentų ar Darbalaukio aplankas. Failai, kurie „pasiekiami tik internete“, atsisiunčiami kaskart juos atidarant. Perkelkite parduotuvę į vietinės aplinkos svetainių aplanką, pavyzdžiui, C:\MAMP\htdocs ar C:\wamp64\www.
• Antivirusas tikrina kiekvieną PHP atidaromą failą. Bandymo metu įtraukite parduotuvės aplanką į išimtis: Windows sauga > Apsauga nuo virusų ir grėsmių > Tvarkyti parametrus > Išimtys.
• Įjungtas Xdebug. Jis gerokai sulėtina kiekvieną PHP užklausą. Jei phpinfo rodo Xdebug skiltį, šiai PHP versijai jį išjunkite.

Sprendimas: sukurkite cache komandine eilute#

Komandinėje eilutėje PHP neturi laiko ribos, o bin/console ją bet kuriuo atveju išjungia pats. Parduotuvės šakniniame aplanke:

php bin/console cache:warmup --no-optional-warmers

Su MAMP Windows kompiuteryje PHP kvieskite pilnu keliu (versijos aplanką pasitaisykite):

C:\MAMP\bin\php\php8.5.12\php.exe bin\console cache:warmup --no-optional-warmers

Taip sukuriamas cache derinimo (debug) režimui. Jei debug režimas išjungtas, pridėkite --env=prod. Kai komanda baigs darbą, perkraukite administravimą: konteineris jau paruoštas, todėl puslapiui jo kurti nebereikia.

--no-optional-warmers nepraleiskite. Be jo mūsų bandomojoje 9.2 parduotuvėje komanda dar paruošdavo visus Twig šablonus ir sustojo su Allowed memory size of 536870912 bytes exhausted. Administravimui atidaryti papildomų žingsnių nereikia. Su šiuo parametru konteineris buvo paruoštas maždaug per 10 sekundžių.

Linux serveryje komandą paleiskite kaip svetainės serverio vartotojas (pavyzdžiui, sudo -u www-data php bin/console …). Paleista kaip root, ji palieka cache failus, į kuriuos svetainė negali rašyti, ir administravimas grąžina klaidą 500. Mūsų bandyme taip ir nutiko, o chown -R www-data:www-data var/cache tai sutvarkė.

Kur dar pasitaiko#

Tas pats kūrimas vyksta po kiekvieno cache išvalymo: įdiegus ar atnaujinus modulį, paspaudus Išvalyti cache (Išplėstiniai parametrai > Našumas), po kiekvieno atnaujinimo. Debug režime konteineris dar perkuriamas, kai pasikeičia bet kuris failas, nuo kurio jis priklauso. Jei kaltas OneDrive ar antivirusas, sutvarkykite priežastį, o ne kurkite cache rankomis kiekvieną kartą.

Kurie moduliai atsineša daugiausia failų:

for d in modules/*/; do echo "$(find "$d" -name '*.php' | wc -l) $d"; done | sort -rn | head