HTTP / 2 Hva, hvor, hvorfor og når ?! - Frontend London

Jeg har en Magento-installasjon, som fungerer perfekt fra kundens synspunkt. Når du prøver å gjøre batchoppgaver med administratoren, lukker Nginx imidlertid ofte forbindelsen til nettleseren tidlig, og forårsaker en "tom svar fra server" -feil i nettleseren. Backend-oppgaven fortsetter fortsatt inne i Apache til den er fullført. PHP er konfigurert med Magentos standard max_execution_timeout på 18000 sekunder.

Jeg fant en artikkel som var relatert til dette, og foreslo å bruke "send_timeout" -direktivet i Nginxs konfigurasjon. Så jeg satte det til det samme som max_execution_time på 18000 sekunder. Så opprettet jeg et PHP-skript som bare sover i 65 sekunder (det ser ut til at timeout på 60 sekunder).

Det er ikke bare nettleseren som har problemet. Jeg får:

krøll: (52) Tomt svar fra serveren

fra CURL også. Jeg har ingen andre uklare Nginx-konfigurasjonsregler i HTTP-direktivet. Noen som har noen anelse om hva som kan skje her, og hvordan kan man gå for å stoppe dette? Jeg går litt vill.

Jeg vil foreslå å dele batchoppgaven din i mindre (som 10 sekunder hver) og bruke AJAX for å oppdatere siden og vise fremgang.

Å vente i 60 sekunder på svar er for lang, altfor lang. Jo lenger du opererer, jo større sjanser for feil har du.

Ved å dele inn i mindre grupper, hvis du krasjer, mister du bare en brøkdel.

  • Jeg er enig. Dette er imidlertid hvordan Magento fungerer, og er designet for å fungere. Og mange store netthandelsnettsteder rundt om i verden bruker den samme plattformen, og det er slik den har fungert siden den praktisk talt ble bygget. Jeg har klart å komme meg rundt dette med cron ved å få wget til å kalle det via backend Apache direkte, slik at nginx ikke kutter det av halvveis gjennom en oppgave. For oppgaver som er initiert via administratoren av brukeren, kan jeg imidlertid ikke ta en slik snarvei.

Kontroller fastcgi-tidsavbruddsparametrene dine (/etc/nginx/fastcgi_param.conf).

Eller prøv å støte opp proxy_read_timeout 90; i /etc/nginx.conf.

fungert for deg: Charles Robertson | Ønsker du å kontakte oss?