2 minuten? Da's wel erg kort. En waar blijkt dit uit? Zorgt dit voor problemen? Wat voor OS wordt daar gebruikt? Windows of Linux?
Ben benieuwd naar de redenatie van deze host.
EDIT: trouwens bijna alle sessie-instellingen zijn in principe overal instelbaar (PHP_INI_ALL) dus ze moeten wel een erg goede reden hebben waarom je hier niet aan zou mogen komen...
Bijvoorbeeld iemand logt in, gaat naar een HTML formulier om een nieuwsbericht te typen. 2 minuten is dan niet heel lang, drukt op opslaan en men is al uitgelogd. Het bericht wordt dan opgeslagen zonder dat er bekend is welke gebruiker het heeft gemaakt.
Ik vind het ook heel vreemd. Heb het bij andere hosts nog nooit meegemaakt zo.
Dit is de reactie van ze toen ik vroeg of ik de instelling aan kan passen:
Beste Ramon,
Onze server ondersteunt deze optie niet, wij beheren deze instellingen zelf voor onze klanten. U kunt in dit geval geen invloed op deze timeout uitoefenen. In het verleden bleven scripts namelijk onnodig lang draaien, wat voor overlast en instabiliteit zorgde. Daarom hebben we ervoor gekozen om deze optie te wijzigen en zelf voor onze klanten te gaan beheren.
Als ik nog iets voor u kan doen, laat het me dan gerust weten
Toevoeging op 13/04/2016 10:05:33:
Heb al aangegeven dat een php sessie in mijn ogen niet echt een 'script' is wat volgens hen lang zou kunnen blijven draaien.
Technisch heeft de provider wel een punt. Een van mijn sites heeft een supergrote cache per sessie: ongeveer 1 MiB. Bij grotere bezoekersaantallen zaten we daardoor soms zonder schijfruimte, waardoor er vervolgens helemaal geen sessie meer konden worden opgeslagen. We hebben dat toen opgelost door een paar gigabyte opslag bij te huren, door de garbage collector anders te configureren én door de sessieduur te verkorten tot 6 minuten. (Bij het doorspitten van de sitestatistieken zagen we dat 99,99% van de bezoekers altijd binnen 6 minuten een volgend request verzendt, dus zo kwamen we op die sessieduur.)
Maar, maar, maar ... dat is wel typisch iets dat je als developer liefst zelf in de hand wilt hebben. Als je site gaat lijden ander het gedrag van andere sites op dezelfde server en de provider daarom op eigen houtje dit soort kunsten gaat uithalen, wordt het tijd om op zoek te gaan naar een andere provider.
Wil je toch niet verhuizen, dan zou je het sessiebeheer kunnen aanpakken: gebruik niet het standaard sessiebeheer van PHP, maar bouw zelf een vergelijkbare oplossing.
Hm, is het mogelijk om mensen onder water "door te loggen" mocht een sessietimeout optreden tijdens het invullen van een formulier of is dit om praktische redenen niet mogelijk (omdat je bijvoorbeeld dan je hele systeem/gebruikte pakket ondersteboven zou moeten keren)?
Je zegt "opeens", dus dit is een recente wijziging? Zonder inspraak/aankondiging? Ook niet erg netjes.
Dan die reactie, wat een gel...euter. Die redenatie ook:
In het verleden bleven scripts namelijk onnodig lang draaien, wat voor overlast en instabiliteit zorgde. Daarom hebben we ervoor gekozen om deze optie te wijzigen en zelf voor onze klanten te gaan beheren.
Dus omdat er ooit problemen waren wordt iedereen nu in een onpraktisch keurslijf gedwongen? lol. En inderdaad, sessie-functionaliteit heeft in principe niets van doen met lang draaiende, inefficiënte scripts. Klinkt alsof ze het probleem op de verkeerde manier aan het oplossen zijn?
Zit je op shared hosting? Zou dan gelijk controleren of je niet in een gezamenlijke directory je sessie-bestanden parkeert :).
Het klinkt niet alsof ze hun zaken erg goed voor elkaar hebben en/of hun klanten willen opvoeden/aanspreken op baggerscripts. Toch met klem verzoeken om timeouts weer terug aan te passen omdat je anders niet met redelijk fatsoen je eigen programmatuur kunt draaien (daarnaast is het een eenzijdig doorgevoerde, en nogal rigoreuze, actie) en als ze dat niet willen doen dan maar verhuizen :/.
@Ivo; in dat geval geef ik ze inderdaad groot gelijk om je in elk geval de keuze te geven; of zij beperken iets of je huurt ruimte bij. Bij deze sites gaat het om enkele bytes. Bij 1 site zelfs alleen een gebruikers_ID. Niet heel spannend dus.
@Thomas; het is inderdaad shared hosting. Het geeft de laatste tijd pas problemen, ik verwacht dus (maar kan ik niet bewijzen) dat het pas de laatste tijd zonder aankondiging aangepast is.
Iets met onder water doorgeven zou uiteraard kunnen. Maar het gaat me nu ook wel om het principe. Deze klanten heb ik destijds vooral naar deze hostingpartij gestuurd omdat het een degelijk bedrijf is/was. Door dit opeens zo aan te passen, krijgt de klant niet waarvoor ze betaalt.
Erg vreemd dus. Gelukkig heb ik die mening dus niet alleen gezien jullie reacties.
maar wordt hier niet de levensduur van een session bestand verward met de max-run-time van een script?
Een script dat 2 minuten draait: dat is inderdaad rijkelijk lang. 30 seconden, of hooguit een minuut zou voor de meeste situaties voldoende moeten zijn.
Mogelijk als je een flinke pdf samenstelt of een groot excelsheet niet.
Maar ik vraag me af wat de session lifetime daaraan bijdraagt.
Ja inderdaad Ivo. Ik vraag om de php sessie tijd / lifetime, maar ze blijft terug komen op dat scripts lang bleven draaien vandaar dat deze instelling niet aangepast kan worden en op 2 minuten staat.
Opmerkelijk zou ik het wel willen noemen. Als er meerdere websites op die shared host draaien met een login dan krijgen ze meer klanten op hun nek. Dat kan niet missen. Ik zou nog een poging wagen en het verschil tussen runtime script en sessie proberen uit te leggen. Direct zeggen dat je gedwongen wordt op op te zeggen en te verhuizen naar een andere host die het verschil wel kent. En dan maar hopen op een positief antwoord.
Of natuurlijk verwijzen naar dit topic, uiteraard. Want zoals gezegd: de session lifetime heeft nog minder dan niets te maken met de max execution time.
Ik heb het meerdere malen uitgelegd en ook verwezen naar dit topic... Helaas snapt Argeweb het niet of wil het niet snappen
Toevoeging op 13/04/2016 21:46:44:
In elk geval erg vreemd
Toevoeging op 14/04/2016 09:01:13:
Ze hebben gelukkig een 'oplossing' gevonden:
Ik heb het voor de zekerheid nog even nagevraagd en het blijkt dat de timeout geen twee, maar drie minuten is. Sessies mogen dus gedurende 180 seconden lopen alvorens deze door onze server worden afgebroken. Op een gedeeld webhostingplatform zijn er helaas limieten waar u als gebruiker tegenaan kunt lopen.
Alternatief zou u een VPS kunnen overwegen waar u de server volledig zelf kunt configureren en dergelijke instellingen zelf kunt beheren. Hier ondervindt u niet de limieten welke op een gedeeld platform zijn ingesteld.
Mijn oplossing is om de verhuiscodes maar aan te vragen... Bedankt voor jullie ideeen allemaal!
