503 enkel op NAS
ik heb een backup en restore script lopen. dit werkt zonder problemen op wamp(meerdere PC's). maar op Synology krijg ik na ±1 minuut een 503 melding. Indien ik het bestand verklein lukt het (soms).
Nu heb ik in webstation al een paar instellingen gewijzigd echter tot nog toe met geen succes.
gewijzigd:
max_execution_time ==> 2400
max_input_time ==> 6000
max_input_Vars ==> 100000
memory_limit ==> 1024M
post_size ==> 2000M
upload_max_FileSize ==> 2000M
Wat zou ik nog kunnen wijzigen en naar welke waarde om mijn script normaal werkend te krijgen?
Jan
Toevoeging op 14/08/2017 08:59:45:
De nas werkt met apache 2.4 en php 7.0
Misschien staat er iets in je error log?
En wat is je Apache configuratie? PHP en Apache moeten *beide* voldoende hoog afgesteld worden om uploads goed te laten werken. Overigens, waar is een max_execution_time van 2400 goed voor? Dat gaat niets uithalen en leidt vroeg of laat tot problemen. Ook is het post_max_size en niet post_size.
PHP Maarten op 14/08/2017 09:40:45:
Misschien staat er iets in je error log?
als ik deze maar eens kon vinden :(
Toevoeging op 14/08/2017 18:04:23:
Ben van Velzen op 14/08/2017 10:41:47:
En wat is je Apache configuratie?
Geen idee
Ben van Velzen op 14/08/2017 10:41:47:
waar is een max_execution_time van 2400 goed voor?
ik moet toch iets proberen.
Ben van Velzen op 14/08/2017 10:41:47:
Ook is het post_max_size en niet post_size.
gewoon te snel geschreven.
Aan de hand van documentatie misschien, en niet uit de losse pols. Als je niet begrijpt waar instellingen voor zijn of wat voor effect ze hebben heeft het geen enkele zin om maar wat te proberen.
>> Geen idee
En daar heb je het al. Zoek dat eerst eens uit, dan weet je ook meteen waar je error logs zich bevinden.
Gezien het script na 60" afbreekt is het voor mij logisch dat ik dat verhoog.
PHP config vind ik. apache config zoek ik al tijden naar
Er is afbreken en er in afbreken. Als je over de max_input_time heen gaat zal max_execution_time niets uithalen. Zet voor de grap ook eens display_errors aan en error_reporting op E_ALL. Dat vertelt je op zijn minst *waarom* het script een timeout geeft. Boven 60 seconden *execution time* uit komen is erg knap, en als het je gebeurt los je dat op door je script te versnellen, of waarschijnlijker, door je oneindige lus te repareren. Niet door de execution time te verhogen. Immers; max execution time is de executietijd zonder externe toegangen. Databasetoegang, sockets e.d. tellen hier dus niet in mee.
Ben van Velzen op 14/08/2017 18:57:31:
Er is afbreken en er in afbreken. Als je over de max_input_time heen gaat zal max_execution_time niets uithalen. Zet voor de grap ook eens display_errors aan en error_reporting op E_ALL. Dat vertelt je op zijn minst *waarom* het script een timeout geeft. Boven 60 seconden *execution time* uit komen is erg knap, en als het je gebeurt los je dat op door je script te versnellen, of waarschijnlijker, door je oneindige lus te repareren. Niet door de execution time te verhogen. Immers; max execution time is de executietijd zonder externe toegangen. Databasetoegang, sockets e.d. tellen hier dus niet in mee.
error reporting staat op all
er is maar 1 lus en het is geen oneindige
Als dat zo is en display_errors staat ook gaan krijg je geen 503 tenzij het aan de Apache configuratie ligt. Daar kan ook een timeout plaatsvinden immers. Nogmaals: hoe luidt de Apache configuratie, en als je geen idee hebt, ga dan eens op zoek.