verantwoordelijkheid... bij server of PHP-code?
Sommige functionaliteit/wensen kun je op de server configureren/installeren, maar ook in je PHP-code.
Bijvoorbeeld. Er zijn diverse "ini" settings die je op de server via php.ini kunt regelen, maar die je ook in de PHP-code kunt regelen via ini-set(). Een ander voorbeeld, je kunt een yaml parser op de server installeren, maar je kunt ook gebruik maken van een bestaande PHP class/library.
Nu is mijn vraag waar jullie voorkeur ligt. In het algemeen kun je (denk ik) stellen dat alles wat je via de server regelt, snelheidsvoordeel oplevert. Dus dat is wel een heel interessant voordeel. De andere kant van het verhaal is dat je een gedeelte van je functionaliteit/configuratie overdraagt aan de server. Dat betekent dat wanneer je van server wisselt, of een wat groter server update uitvoert je mogelijk alles opnieuw moet configureren en installeren.
Beide opties hebben dus voors en tegen. Ik ben benieuwd wat jullie voorkeur heeft.
Ik denk dat er uiteindelijk maar één antwoord de doorslag geeft: kosten. Wat kost het om een server in te richten conform de systeemvereisten? En wat kost het aan extra programmeerwerk (tijd is geld) om de systeemvereisten te verlagen?
Onlangs had ik dat met cURL. Een klant had zijn site verhuist naar een server waarop cURL ontbrak. Daardoor werkte een onderdeel dat ik had geprogrammeerd op basis van cURL niet meer. Op dat moment staat de klant precies voor diezelfde keuze: betaal ik de host voor het installeren van cURL of betaal ik de developer om het geheel werkend te krijgen zonder cURL?
Dergelijke kosten heb je zelfs als je puur voor jezelf een eigen server inricht. Vandaag twee uur meer tijd investeren in je code is zinvol als je daarmee in de toekomst twee keer een halve dag werk bespaart en zinloos als je dat later slechts vijf minuten bespaart.
Ward van der Put op 07/10/2014 09:05:53:
Interessante vraag!
Ik denk dat er uiteindelijk maar één antwoord de doorslag geeft: kosten. Wat kost het om een server in te richten conform de systeemvereisten? En wat kost het aan extra programmeerwerk (tijd is geld) om de systeemvereisten te verlagen?
Onlangs had ik dat met cURL. Een klant had zijn site verhuist naar een server waarop cURL ontbrak. Daardoor werkte een onderdeel dat ik had geprogrammeerd op basis van cURL niet meer. Op dat moment staat de klant precies voor diezelfde keuze: betaal ik de host voor het installeren van cURL of betaal ik de developer om het geheel werkend te krijgen zonder cURL?
Dergelijke kosten heb je zelfs als je puur voor jezelf een eigen server inricht. Vandaag twee uur meer tijd investeren in je code is zinvol als je daarmee in de toekomst twee keer een halve dag werk bespaart en zinloos als je dat later slechts vijf minuten bespaart.
Ik denk dat er uiteindelijk maar één antwoord de doorslag geeft: kosten. Wat kost het om een server in te richten conform de systeemvereisten? En wat kost het aan extra programmeerwerk (tijd is geld) om de systeemvereisten te verlagen?
Onlangs had ik dat met cURL. Een klant had zijn site verhuist naar een server waarop cURL ontbrak. Daardoor werkte een onderdeel dat ik had geprogrammeerd op basis van cURL niet meer. Op dat moment staat de klant precies voor diezelfde keuze: betaal ik de host voor het installeren van cURL of betaal ik de developer om het geheel werkend te krijgen zonder cURL?
Dergelijke kosten heb je zelfs als je puur voor jezelf een eigen server inricht. Vandaag twee uur meer tijd investeren in je code is zinvol als je daarmee in de toekomst twee keer een halve dag werk bespaart en zinloos als je dat later slechts vijf minuten bespaart.
Ik ben het hier niet mee eens. In je cURL voorbeeld vind ik dat je cURL moet laten installeren op je server. Dit is echt maar maximaal 30 minuten werk. Daarnaast zijn er genoeg gevallen wanneer je niet om een server installatie heen kan. ini_set() gebruiken is nooit de beste oplossing.
Zoek een goede hosting partij waarbij je deze dingen kunt laten installeren of waar deze reeds geïnstalleerd zijn.
Ik kan ze in principe zelf installeren, en de ini instellingen kan ik ook zelf doen. Het kosten/tijd aspect kan interessant zijn, maar aangezien het in dit geval om mijn eigen server gaat is het wat minder relevant.
Laat ik 2 vrij concrete voorbeelden geven en dan ben ik benieuwd wat jullie zouden doen.
1)
Stel, ik heb 20 "ini" settings die ik wil wijzigen. Dit kan ik doen via mijn panel (bijv. Plesk of cPanel) en die past dan php.ini aan. Deze settings staan nu dus op de server. Stel, ik ben op een gegeven moment niet meer tevreden over mijn server, of ik wil Apache upgraden naar een nieuwere versie, dan moet ik deze settings opnieuw instellen. Het voordeel is wel dat wanneer de settings zijn doorgevoerd, ze slechts 1x te hoeven worden ingelezen.
Wat ik dus ook kan doen, is via ini_set() die 20 settings in de PHP-code plaatsen. Als ik dan verhuis van server, of Apache upgrade naar een nieuwere versie, dan blijft de PHP-code - en dus ook de ini settings - gehandhaafd. Anders gezegd, ik hoef er dus nooit meer iets aan te doen.
Als ik de ini settings in de PHP-code plaats, betekent dit wel, dat bij ieder request de settings opnieuw moeten worden ingesteld, terwijl als ik het op serverniveau regel dit slechts eenmalig hoeft te gebeuren. Vanuit performance-oogpunt is het regelen op server-niveau dus iets gunstiger, hoewel het via de PHP-code wel heel erg (vrijwel verwaarloosbaar) snel gaat.
2)
Stel, ik wil gebruik maken van een yaml parser. Die kan ik op de server installeren via zo'n pecl module. Dan heb je de snelst mogelijke yaml parser. Ik kan ook een PHP yaml class/library gebruiken. Deze is wel een tikkie langzamer. Het voordeel van de pecl module is dus dat deze erg snel is. Het nadeel is dat je 'm altijd zult moeten installeren op de server. Je PHP-code wordt dus afhankelijk van de geinstalleerde module, en je zult dus op iedere server die module moeten installeren. Het voordeel van een yaml class/library is dat deze altijd aanwezig is, maar hij is wel langzamer.
Dus... ik ben benieuwd. Wat zouden jullie doen... en waarom?
Gewijzigd op 07/10/2014 12:22:23 door Ozzie PHP
Ozzie PHP op 07/10/2014 12:20:17:
Als ik de ini settings in de PHP-code plaats, betekent dit wel, dat bij ieder request de settings opnieuw moeten worden ingesteld, terwijl als ik het op serverniveau regel dit slechts eenmalig hoeft te gebeuren. Vanuit performance-oogpunt is het regelen op server-niveau dus iets gunstiger, hoewel het via de PHP-code wel heel erg (vrijwel verwaarloosbaar) snel gaat.
Zodra PHP aan het werk wordt gezet, wordt php.ini verwerkt. Je zou volgens de performance-argumentatie bijvoorbeeld een wachtwoord voor je MySQL-server dus beter in php.ini kunnen zetten, want dan heb je geen PHP-code en geheugen meer nodig voor het instellen en verwerken van de constante met het wachtwoord.
Wat je ook zou kunnen zeggen, is dat die PHP-constante in script dubbelop is, omdat het in wezen een lokale overwrite is van iets dat al globally in php.ini is gedefinieerd.
Met dergelijke redeneringen kom je er echter niet helemaal, want php.ini regelt slechts de configuratie van PHP, niet die van je applicaties. Met andere woorden: "de configuratie" bestaat niet, want er zijn altijd minstens twee configuraties.
Vraag wordt dan meer wat je zelf overzichtelijker vindt: op twee plaatsen twee configuraties in twee talen bijhouden of alles in één taal in één config.php (of één YAML-bestand) zetten?
Dit snap ik even niet. Volgens mij wordt php.ini slechts 1x ingelezen (op het moment dat de apache server wordt opgestart) en dus niet telkens als PHP aan het werk wordt gezet. Of vergis ik me?
Wat zou jij zelf doen Ward? Want dat was eigenlijk mijn vraag :)
Laten we een voorbeeldje nemen. Stel ik wil al mijn sessie-bestanden opslaan in 'var/www/session'. Dit pad kun je in je PHP-code instellen via ini_set(), of je stelt het in je php.ini in. Uit deze 2 opties, welke optie zou jij dan kiezen, en waarom?
>> Laten we een voorbeeldje nemen. Stel ik wil al mijn sessie-bestanden opslaan in 'var/www/session'. Dit pad kun je in je PHP-code instellen via ini_set(), of je stelt het in je php.ini in. Uit deze 2 opties, welke optie zou jij dan kiezen, en waarom?
Idem dito. Als ik een server inricht, regel ik dat zelf in php.ini. Maar als ik iets bouw dat in gebruik genomen moet kunnen worden met even unzippen en uploaden, dan regelt een installatiescript of de library dat. Je wilt meestal niet iets opleveren met een installatiehandleiding die allerlei handmatige ingrepen in php.ini voorschrijft.
In dat opzicht ben ik het wel met Jr Melgert eens: een ini_set() in PHP-script gebruiken is geen goede oplossing en iets dat erop lijkt evenmin.
Je zou je framework natuurlijk kunnen uitrusten met een kopie van php.ini die je zó kunt overzetten. Dan is het inregelen een fluitje van een cent.
Oké, thanks. Helder. Dat is inderdaad Wel een goede.
>> Je zou je framework natuurlijk kunnen uitrusten met een kopie van php.ini die je zó kunt overzetten. Dan is het inregelen een fluitje van een cent.
Ware het niet dat dat wanneer je een panel gebruikt weer net wat anders gaat (tenminste bij cPanel). Maar dan zal ik gewoon even de aangepaste settings moeten documenteren. Op zich ook niet zo'n probleem.
En wat betreft de Yaml reader... instellen op de server of als PHP class/library? Ik noem hier nu een Yaml reader als voorbeeld, maar er zijn natuurlijk veel meer modules die beschikbaar zijn als een server "plugin", maar ook als PHP class. Hoe is jouw visie daarop? De server plugins zullen over het algemeen veel sneller werken en misschien ook wel wat stabieler zijn, maar die moet je dan wel telkens installeren op de server.
Gewijzigd op 07/10/2014 14:26:46 door Ward van der Put
Dat maakt voor mijn vraag eigenlijk niet zoveel uit. Er zijn natuurlijk verschillende yaml versies als je daarop doelt. Maar het gaat mij meer om de vraag in het algemeen. Als een vergelijkbare functionaliteit zowel beschikbaar is als module op server-niveau en als PHP class/library, wat is dan de meest voor de hand liggende keuze?
Het houdt ook een keer op, hè, anders kun je beter alle klassen voor de core van je framework rechtstreeks in C++ programmeren en als modules op je VPS parkeren.
Uiteraard praten we hier over bestaande classes, en zoals ik al eerder zei... met vergelijkbare functionaliteit. Als de een meer functionaliteit heeft dan de ander, dan wordt het een makkelijkere keuze. Maar wat doe je in gelijke gevallen...
Het feit dat je een framework bouwt waarmee je uiteenlopende sites wilt kunnen bouwen, mag wel meewegen. Ergens is "het framework werkt out-of-the-box op elke server die PHP 5.3 ondersteunt" namelijk ook wel een pluspunt. En dan zijn we weer bij een eerder argument: dat gaat niet vanzelf en kost je op zijn minst tijd.
Dit gezegd hebbende... dat geldt ook voor je ini-settings. Als ik bijv. in m'n php.ini instel waar de sessies moeten worden opgeslagen, dan heb je hetzelfde verhaal.
Door dus iets op de server te regelen, creëer je altijd een bepaalde afhankelijkheid tussen server en code. Is dat oké?
Wat je wel kunt doen (en in de praktijk vaak onbewust gebeurt), is doen of de configuratie niet bestaat door deze doodleuk te negeren. Maar dan nog wordt php.ini gewoon gebruikt, zelfs als je zelf nooit in het bestand hebt gekeken.
Het gaat hier ook niet om de relatie tussen de server en jouw code, maar om de relatie tussen de server en de engine die de code uitvoert. Subtiel maar belangrijk verschil: PHP configureer je met php.ini, de PHP-applicaties configureer je elders.
Voor applicaties die een andere PHP-configuratie vereisen, maak je logischerwijs een uitzondering: dan hoort die instelling in de applicatie, niet in de algemene instellingen van PHP.
Kijk maar naar de constructor van MySQLi. Alle parameters zijn optioneel en gaan, met uitzondering van $dbname, uit van een ini_get().