Archief - nginx traag (windows)

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

bealzebub

Legacy Member
demon326 zei:
Nginx is voornamelijk goed als ge veel static files hebt, die dus zonder overhead afgeleverd kunnen worden... Op zijn site zie ik voornamelijk dynamische pagina's, dan lijkt het me beter daar een cache voor te zien... APC maakte op mijn board en site toch aanzienlijk verschil in snelheid.. nadeel is dat het geheugen kost:p

Elke webserver is op z'n best bij het serven van static content, dan moeten ze immers het genereren van de pagina niet doorgeven naar één of andere module of proxy.

De combinatie Nginx + PHP-FPM + APC is wel een goeie stack (eigenlijk DE stack als je PHP apps wil serven). Zelfs in een Apache omgeving kan je PHP-FPM ipv mod_php gebruiken om sneller en efficiënter PHP te serven.

De vraag is of Windows dan wel de manier waarop de web stack opgezet is de oorzaak is van het traag zijn. Eerlijk gezegd kan k mij nie inbeelden dat het Windows is, zelfs al is de Windows versie van nginx momenteel meer het debiele broertje van z'n Linux tegenhanger.
Da kan je natuurlijk makkelijk te weten komen door het eens in een virtuele Linux omgeving te draaien. En als je slim bent, gebruik je Chef of Puppet om je server setup te doen, dan kan je veel makkelijker aanpassingen in je production environment op een identieke lokale test VM uitproberen. Der zijn trouwens al klaargemaakte recipes voor Chef die gans de nginx+php stack getest voor je installeren, google it ;)

Nginx is wa moeilijker in setup dan Apache of IIS, maar eens ie der staat is alles gewoon zoveel aangenamer. Elke keer als k iets min of meer exotisch (en geloof me, exotisch bij ons is exotisch) moet doen in een Apache conf is m'n dag al verpest voor k eraan begin.

h0us3cat

Legacy Member
bealzebub zei:
Elke webserver is op z'n best bij het serven van static content, dan moeten ze immers het genereren van de pagina niet doorgeven naar één of andere module of proxy.

De combinatie Nginx + PHP-FPM + APC is wel een goeie stack (eigenlijk DE stack als je PHP apps wil serven). Zelfs in een Apache omgeving kan je PHP-FPM ipv mod_php gebruiken om sneller en efficiënter PHP te serven.

De vraag is of Windows dan wel de manier waarop de web stack opgezet is de oorzaak is van het traag zijn. Eerlijk gezegd kan k mij nie inbeelden dat het Windows is, zelfs al is de Windows versie van nginx momenteel meer het debiele broertje van z'n Linux tegenhanger.
Da kan je natuurlijk makkelijk te weten komen door het eens in een virtuele Linux omgeving te draaien. En als je slim bent, gebruik je Chef of Puppet om je server setup te doen, dan kan je veel makkelijker aanpassingen in je production environment op een identieke lokale test VM uitproberen. Der zijn trouwens al klaargemaakte recipes voor Chef die gans de nginx+php stack getest voor je installeren, google it ;)

Nginx is wa moeilijker in setup dan Apache of IIS, maar eens ie der staat is alles gewoon zoveel aangenamer. Elke keer als k iets min of meer exotisch (en geloof me, exotisch bij ons is exotisch) moet doen in een Apache conf is m'n dag al verpest voor k eraan begin.

Het probleem is fastcgi die maar op 1 worker werkt, tot nu toe lijkt niemand te weten of je meer workers kan geven. Ben maar terug naar apache gegaan...

dJeez

Legacy Member
h0us3cat zei:
Het probleem is fastcgi die maar op 1 worker werkt, tot nu toe lijkt niemand te weten of je meer workers kan geven. Ben maar terug naar apache gegaan...
Je kan bij FPM verschillende pools definiëren (specifieke user/group enz. - PHP: Configuration - Manual). Al onze PHP sites draaien op die manier (ook met APC trouwens) achter Apache (elke site met een eigen pool en specifieke settings, zo goed als fully automated deploys). Nginx bekijken staat op de planning, maar is nog niet echt nodig geweest aangezien we de drukkere sites sowieso via Varnish cachen (met dynamische onderdelen gerendered via ESI).

h0us3cat

Legacy Member
dJeez zei:
Je kan bij FPM verschillende pools definiëren (specifieke user/group enz. - PHP: Configuration - Manual). Al onze PHP sites draaien op die manier (ook met APC trouwens) achter Apache (elke site met een eigen pool en specifieke settings, zo goed als fully automated deploys). Nginx bekijken staat op de planning, maar is nog niet echt nodig geweest aangezien we de drukkere sites sowieso via Varnish cachen (met dynamische onderdelen gerendered via ESI).

fpm werkt niet op windows.

bealzebub

Legacy Member
h0us3cat zei:
fpm werkt niet op windows.

Tjah…*K wist dat het met Windows webserving (gow, alles dat niet Mickeysoft-related is) slecht gesteld was, maar dit slaat toch alles. Apache mod_php is eigenlijk al nie veel beter é, die gaat gewoon ieder keer nen volledige interpreter met alle aanhangsels gaan spawnen om em daarachter weer af te sluiten. Maar goe, als je nie anders kan…

Misschien toch eens overwegen om een Linux VM binnen Windows te gebruiken. Qua performance verlies je daarmee quasi nix en je zal het met de betere setup toch gegarandeerd terugwinnen.

h0us3cat

Legacy Member
dJeez zei:
Tjah, gebruik dan een echt OS hé :p.

Het enige alternatief dat ik zo direct kan bedenken is verschillende FastCGI processen laten draaien, elk op hun eigen poort.

Dit kan dan misschien nog van pas komen : Multiple FastCgi PHP Servers Nginx Load Balancing « Hone Watson Bookmarks
bealzebub zei:
Tjah…*K wist dat het met Windows webserving (gow, alles dat niet Mickeysoft-related is) slecht gesteld was, maar dit slaat toch alles. Apache mod_php is eigenlijk al nie veel beter é, die gaat gewoon ieder keer nen volledige interpreter met alle aanhangsels gaan spawnen om em daarachter weer af te sluiten. Maar goe, als je nie anders kan…

Misschien toch eens overwegen om een Linux VM binnen Windows te gebruiken. Qua performance verlies je daarmee quasi nix en je zal het met de betere setup toch gegarandeerd terugwinnen.



En zeg me nu is wat er mis is met windows?
Kom niet af met dingen zoals stabieler of neemt minder resources in.

bealzebub

Legacy Member
h0us3cat zei:
En zeg me nu is wat er mis is met windows?
Kom niet af met dingen zoals stabieler of neemt minder resources in.

Wel raar dat je vraagt waarom iets beter of slechter is dan iets anders en dan twee van de belangrijkste aspecten van webhosting niet wil horen (misschien omdat je weet wat daar het verdict al is). Stabiliteit is trouwens iets wat redelijk in de handen van de sysop ligt. De twee andere zaken die voor mij belangrijk zijn, zijn prijs en performance. Ook daar ga k maar geen uitspraak over doen want het zou in het verkeerde keelgat kunnen schieten.

Windows is blijkbaar goed in staat alles wat Microsoft-related is te draaien onder IIS (bv alles .NET related) en Java is ook goed te doen (omdat dat toch binnen z'n eigen VM al draait). Neem gelijk welke andere omgeving en het valt redelijk plat op z'n buik. NodeJS… het werkt… soms. Ruby…*het werkt… heel soms. Python…*dikwijls problematisch. PHP… het werkt…*maar tot op een bepaald niveau.

Deze thread alleen al bewijst dat er hier mensen zitten die duidelijk de omgeving kennen en je de sleutel tot succes, zowel voor een Apache omgeving als een nginx omgeving, hebben aangereikt. Het feit dat er geen alternatief bestaat voor FPM op Windows is gewoon omwille van het feit dat er niemand is die er tijd wil insteken. Bovendien weet ik heel zeker dat dJeez, demon326 en ikzelf ooit Apache + mod_php stacks gehad hebben en maar al te goed weten dat je daar op een bepaald moment in de problemen komt en moet gaan optimaliseren. Dat kan op heel wat verschillende manieren, waarbij je kan beginnen met een aantal zaken vóór je interpreter te gaan plaatsen, maar uiteindelijk blijft je rendering stack traag. De extra resources die mod_php neemt zijn op dat moment het minste van je zorgen, het gaat hem over de spinup time zelf. Dat daar dan eens grappend over een beter OS gesproken wordt (met dan nog een ferme smiley erachter) is om het toch een beetje luchtig te houden. Als ik zei van een Linux VM binnen je Windows omgeving te booten, dan was het ook alleen maar omdat je de vergelijking zou kunnen maken zonder daarvoor direct helemaal op waarschijnlijk voor jou volledig nieuw terrein te moeten beginnen. VMs hebben trouwens heel wat meer voordelen dan dat alleen. Wij gebruiken ze constant, zelfs in een full Linux omgeving.

Als je mijn postgeschiedenis bekijkt, dan merk je dat ik zonder al te veel vooroordelen hier mensen probeer te helpen. Ik krijg zelfs regelmatig eens heel technische vragen via PMs, waar ik dikwijls uren tijd na mijn werkuren in steek om de best mogelijke oplossing te kunnen geven. En het rare is… meestal kan ik dat dan nog ook. Ik moet dat niet doen. Bovendien lijken de meeste thread posters mijn inbreng best te appreciëren.

Dus…*vóór je zo in de verdediging schiet en denkt dat het hier alleen maar over Windows bashing gaat, probeer het eens in de context te zien van je originele vraag.
Je wou weten waarom je PHP onder nginx zo traag was, we hebben je de oplossing gegeven. Je mag daar zelfs nginx uit de vergelijking wegnemen, het verhaal gaat nog steeds op. Ik ben al een tijdje weg uit de Windows omgeving in m'n professionele omgeving (voor gaming is wat anders) na heel wat WTF ervaringen en de nodige frustraties, maar had verwacht dat na zoveel jaar er toch verbetering zou zijn en dat is dus duidelijk niet het geval. Het verschil is wel dat ik op zoek ga naar de beste oplossing en als dat wil zeggen dat ik daarvoor een ander OS onder de knie moet krijgen, so be it.
Ik zou bv. ook niemand aanraden om MacOS X in een webserver omgeving te draaien puur omwille van het feit dat de I/O nog altijd pakken trager is dan onder Linux, niettegenstaande dat er daar ook een UNIX omgeving onder draait. Als ontwikkelomgeving zou ik echter niets anders willen, het houdt mij enorm productief.

Nu goed, dit is dan ook de laatste reply in deze thread, want een flamewar starten is zeker m'n ambitie niet en de originele vraag is duidelijk beantwoord. Ik hou me liever bezig met nuttige inbreng waar ik ze kan geven.

Shaddix

Legacy Member
h0us3cat zei:
En zeg me nu is wat er mis is met windows?
Kom niet af met dingen zoals stabieler of neemt minder resources in.

Het is niet voor niets dat Linux distro's een monopoly hebben op servers die PHP draaien.

h0us3cat

Legacy Member
bealzebub zei:
Wel raar dat je vraagt waarom iets beter of slechter is dan iets anders en dan twee van de belangrijkste aspecten van webhosting niet wil horen (misschien omdat je weet wat daar het verdict al is). Stabiliteit is trouwens iets wat redelijk in de handen van de sysop ligt. De twee andere zaken die voor mij belangrijk zijn, zijn prijs en performance. Ook daar ga k maar geen uitspraak over doen want het zou in het verkeerde keelgat kunnen schieten.

Windows is blijkbaar goed in staat alles wat Microsoft-related is te draaien onder IIS (bv alles .NET related) en Java is ook goed te doen (omdat dat toch binnen z'n eigen VM al draait). Neem gelijk welke andere omgeving en het valt redelijk plat op z'n buik. NodeJS… het werkt… soms. Ruby…*het werkt… heel soms. Python…*dikwijls problematisch. PHP… het werkt…*maar tot op een bepaald niveau.

Deze thread alleen al bewijst dat er hier mensen zitten die duidelijk de omgeving kennen en je de sleutel tot succes, zowel voor een Apache omgeving als een nginx omgeving, hebben aangereikt. Het feit dat er geen alternatief bestaat voor FPM op Windows is gewoon omwille van het feit dat er niemand is die er tijd wil insteken. Bovendien weet ik heel zeker dat dJeez, demon326 en ikzelf ooit Apache + mod_php stacks gehad hebben en maar al te goed weten dat je daar op een bepaald moment in de problemen komt en moet gaan optimaliseren. Dat kan op heel wat verschillende manieren, waarbij je kan beginnen met een aantal zaken vóór je interpreter te gaan plaatsen, maar uiteindelijk blijft je rendering stack traag. De extra resources die mod_php neemt zijn op dat moment het minste van je zorgen, het gaat hem over de spinup time zelf. Dat daar dan eens grappend over een beter OS gesproken wordt (met dan nog een ferme smiley erachter) is om het toch een beetje luchtig te houden. Als ik zei van een Linux VM binnen je Windows omgeving te booten, dan was het ook alleen maar omdat je de vergelijking zou kunnen maken zonder daarvoor direct helemaal op waarschijnlijk voor jou volledig nieuw terrein te moeten beginnen. VMs hebben trouwens heel wat meer voordelen dan dat alleen. Wij gebruiken ze constant, zelfs in een full Linux omgeving.

Als je mijn postgeschiedenis bekijkt, dan merk je dat ik zonder al te veel vooroordelen hier mensen probeer te helpen. Ik krijg zelfs regelmatig eens heel technische vragen via PMs, waar ik dikwijls uren tijd na mijn werkuren in steek om de best mogelijke oplossing te kunnen geven. En het rare is… meestal kan ik dat dan nog ook. Ik moet dat niet doen. Bovendien lijken de meeste thread posters mijn inbreng best te appreciëren.

Dus…*vóór je zo in de verdediging schiet en denkt dat het hier alleen maar over Windows bashing gaat, probeer het eens in de context te zien van je originele vraag.
Je wou weten waarom je PHP onder nginx zo traag was, we hebben je de oplossing gegeven. Je mag daar zelfs nginx uit de vergelijking wegnemen, het verhaal gaat nog steeds op. Ik ben al een tijdje weg uit de Windows omgeving in m'n professionele omgeving (voor gaming is wat anders) na heel wat WTF ervaringen en de nodige frustraties, maar had verwacht dat na zoveel jaar er toch verbetering zou zijn en dat is dus duidelijk niet het geval. Het verschil is wel dat ik op zoek ga naar de beste oplossing en als dat wil zeggen dat ik daarvoor een ander OS onder de knie moet krijgen, so be it.
Ik zou bv. ook niemand aanraden om MacOS X in een webserver omgeving te draaien puur omwille van het feit dat de I/O nog altijd pakken trager is dan onder Linux, niettegenstaande dat er daar ook een UNIX omgeving onder draait. Als ontwikkelomgeving zou ik echter niets anders willen, het houdt mij enorm productief.

Nu goed, dit is dan ook de laatste reply in deze thread, want een flamewar starten is zeker m'n ambitie niet en de originele vraag is duidelijk beantwoord. Ik hou me liever bezig met nuttige inbreng waar ik ze kan geven.

Lees onderstaande, lijkt me duidelijk hoe dat klinkt, "oh windows da is zowiezo slecht"
demon326 zei:
Daar zit het probleem dan.... Windows;)

dJeez zei:
Tjah, gebruik dan een echt OS hé :p.

Het enige alternatief dat ik zo direct kan bedenken is verschillende FastCGI processen laten draaien, elk op hun eigen poort.

Dit kan dan misschien nog van pas komen : Multiple FastCgi PHP Servers Nginx Load Balancing « Hone Watson Bookmarks

dJeez

Legacy Member
h0us3cat zei:
Lees onderstaande, lijkt me duidelijk hoe dat klinkt, "oh windows da is zowiezo slecht"
Tjah, als een grapje al niet meer mag... En dat er net daaronder een potentiële oplossing voor je probleem staat is je dan blijkbaar ook maar ineens ontgaan.

Maar om PHP te hosten (zoals je dat wil) is Windows idd niet echt aan te raden. Elk OS heeft zijn eigen sterke en zwakke punten, daarover beginnen zeuren brengt geen zoden aan de dijk. Microsoft is nu eenmaal een slechtere speler als het op web serving aankomt (December 2012 Web Server Survey | Netcraft). Wat niet wegneemt dat het op bepaalde punten ook zijn voordelen heeft uiteraard, voor .NET hosting zou ik sowieso eerder voor Windows opteren ipv het flauwe Mono afkooksel op Linux te draaien (tenzij de klant er specifiek om vraagt natuurlijk).
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan