PS 8.1 e problemi di timeout con server SiteGround basic

[Aenzima]

Buongiorno, ho aggiornato PS alla versione 8.1 o meglio reinstallato ex novo, seguendo tutte le richieste del caso, ho utilizzato phppsinfo che mi ha confermato la tranquilla convivenza sul server (PHP 8.1.31).

Purtroppo sin da subito ho avuto problemi di timeout server dopo 2 o 3 cambiamenti elementari da backoffice (aggiunta lingue, impostato spedizioni) il sito restava raggiungibile ma il back office dava errore 500.

Ora l'assistenza del server mi indica giustamente di verificare se qualche modulo dà problemi, ma in pratica non ce ne sono (se non quelli nativi). Questa la risposta dell'assistenza:

"I problemi che stai affrontando sono relativi a un timeout e non è garantito che un aggiornamento risolva il problema.
Un errore di timeout 504 Gateway indica che uno script impiega troppo tempo per gestire le sue attività e completare le query necessarie per la sua funzione. Per garantire che nessun singolo processo possa consumare tutte le risorse disponibili, ci sono valori di timeout preimpostati e se uno script li supera senza restituire l'output (verbosità) al servizio web, il server "si arrende" in attesa e termina il processo, risultando nell'errore sopra menzionato.

Molto spesso i timeout si verificano a causa di conflitti tra plug-in, codice danneggiato di un plug-in (script di loop ecc.) O semplicemente un processo troppo pesante per il server da elaborare nel tempo indicato.

È altamente possibile che uno dei moduli che stai utilizzando sia semplicemente malfunzionante."

 

E qui parte il dubbio per me (utente principiante/base): in debug non viene evidenziato nessun problema, come faccio ad individuare il problema? Mettiamo caso che ci sia uno script errato o un loop magari nel modulo pagamenti, come possibile se è un installazione pulita ?

Grazie a chi mi darà anche un minimo supporto morale (ho il sito fermo da 5 giorni per questo problema)

[Fabry]

Salve,

spesso sono problemi di config del server e soprattutto Apache/Nginx e alcune volte c'é da aggiungere direttive nei due servers.Poi c'é la config base dei parametri dentro al php.ini...per es il max_execution_time puó alterarlo e inserire 300 come valore. Errore 500 é generico. Se é un Presta 8.1.x vergine deve partire al volo appena configurato nel back....la pagina piú "pesante" spesso é quella dei moduli o delle posizione dei moduli ecco li a volte escono errori e dipendono da direttive sul server.

[Aenzima]

  On 2/13/2025 at 3:31 PM, Fabry said:

Salve,

spesso sono problemi di config del server e soprattutto Apache/Nginx e alcune volte c'é da aggiungere direttive nei due servers.Poi c'é la config base dei parametri dentro al php.ini...per es il max_execution_time puó alterarlo e inserire 300 come valore. Errore 500 é generico. Se é un Presta 8.1.x vergine deve partire al volo appena configurato nel back....la pagina piú "pesante" spesso é quella dei moduli o delle posizione dei moduli ecco li a volte escono errori e dipendono da direttive sul server.

Expand  

grazie della risposta. Dove trovo un esempio o guida da seguire, studiare. Testando il sito i rallentamenti evidenti arrivano nell' acquisto, spesso risolti aggiornando la pagina, ma va da sé che qualunque cliente non è preso positivamente da questi problemi. Aggiornare già alla 8.2 mi porterebbe migliorie?

[Fabry]

Ciao,

non serve aggiornare. Presta 8.1 é giá veloce soprattutto nel Back. Sul front tutto dipende da quali moduli intervengono nelle varie pagine e soprattutto quale tema sta utilizzando. C'é da capire quante queries vengono lanciate sulle varie pagine e cosa le lancia...impossibile dire cosa non va senza vedere il sito e controllare il server...per es il minimo consigliato sulla memoria nel php.ini dovrebbe essere 256 Mb..ma dovrebbe avere un valore maggiore se utilizza moduli terzi

 

https://devdocs.prestashop-project.org/8/basics/installation/system-requirements/

[Aenzima]

adesso l'assistenza SiteGround mi segnala questo problema:

Attualmente, la cache dinamica è automaticamente disabilitata per il sito perché qualcosa sta aggiungendo un cookie alle richieste, ad esempio:

v@~$ curl --resolve MIOSITO.net:443:33.222.222.17 -sSLIX GET https://MIOSITO.net/it/ HTTP/2 503 server: nginx date: Sat, 15 Feb 2025 14:56:28 GMT content-type: text/html; charset=utf-8 retry-after: 3600 set-cookie: PrestaShop-cd042e0c7bf2878e7b343176986c2497=def50200f1db6d0bbd49131fcd8e45651c38fbff91022de0a8561257428671d65d29c0a0a3e543764990da615edb14c9e234bf9809259420f496fc0c0ef70bf0a8909a7ee70d323027a7eb561ce566b506310ecc5c29b8291ea64ac088dd96765cce31d8bc50cd9ff921cf405386555df0bb370f9210b8d7b4c9c650a9d0ad525682833a94aabe4ee61bf83456d3af802237fd020ed867254095baa4ff3dcaa70f804118e280bd972f83d915b5be834844e868984b3328bdd5d629823467085b079ca8990a8f0e953ea9f8b1d86b2c0262d56c88cd74546e1d; expires=Fri, 07-Mar-2025 14:56:28 GMT; Max-Age=1728000; path=/; domain=MIOSITO.net; HttpOnly; SameSite=Lax set-cookie: PrestaShop-59b26638df305f2b59d3542b181ab6e9=def50200bb4169e2e81dbdf9169de9dd236d192b8a15cb32fa6d3e815c2deb266d19a584436b5f7df83e100a23a0e6d82eb5e82fe918784b20f39c689c31b7cbd83537cf146a1f5a2b5bc4bea587fbfebc41f884ca232fe5d0b7964fa409e32c27643a569bbe954652a3ec25736ceb75fb66f6ea6eb9e63c7271823221d29a42ac318d80255b2a3c90f40e873a76d78f3459e395887ca523d4bd739cbecee2f641d32797566b6dfaa16f02deac547b1946d5b9cfb1158d0d4c2bafc9925b02cc369c338778be8566e6f9dff79923c79106ba4780d8; expires=Fri, 07-Mar-2025 14:56:28 GMT; Max-Age=1728000; path=/; domain=MIOSITO.net; secure; HttpOnly; SameSite=Lax x-httpd: 1 host-header: 6b7412fb82ca5edfd0917e3957f05d89 x-proxy-cache: MISS x-proxy-cache-info: d NC:000000 UP:SKIP_CACHE_SET_COOKIE x-cdn-c: static v@~$

 

di cosa si tratta?