Miks ma leian, et Nginx on praktiliselt parem kui Apache

Netcrafti värskeima veebiserveri uuringu kohaselt, mis viidi läbi 2017. aasta lõpu poole (täpselt novembris), on Apache ja Nginx enim kasutatavad Interneti avatud lähtekoodiga veebiserverid.

Apache on tasuta avatud lähtekoodiga HTTP-server Unixi-laadsete operatsioonisüsteemide ja Windowsi jaoks. See oli loodud turvaliseks, tõhusaks ja laiendatavaks serveriks, mis pakub HTTP-teenuseid sünkroonis kehtivate HTTP-standarditega.

Alustamisest alates on Apache olnud Interneti populaarseim veebiserver alates 1996. aastast. See on veebiserverite de facto standard Linuxi ja avatud lähtekoodiga ökosüsteemis. Uutel Linuxi kasutajatel on seadistamine ja kasutamine tavaliselt lihtsam.

Nginx (hääldatakse ‘Engine-x’) on tasuta avatud lähtekoodiga, suure jõudlusega HTTP-server, vastupidine puhverserver ja IMAP/POP3 puhverserver. Nii nagu Apache, töötab see ka Unixi-laadsetes operatsioonisüsteemides ja Windowsis.

Tuntud oma suure jõudluse, stabiilsuse, lihtsa seadistamise ja vähese ressursikulu poolest, on see aastate jooksul muutunud nii populaarseks ja selle kasutamine Internetis on üha suurem. Nüüd on see valitud veebiserver kogenud süsteemiadministraatorite või tippsaitide veebimeistrite seas.

Mõned hõivatud saidid on varustatud:

• Apache on: PayPal, BBC.com, BBC.co.uk, SSLLABS.com, Apple.com ja palju muud.
• Nginx on: Netflix, Udemy.com, Hulu, Pinterest, CloudFlare, WordPress.com, GitHub, SoundCloud ja paljud teised.

Apache'i ja Nginxi võrdlemise kohta on veebis juba avaldatud arvukalt ressursse (ma mõtlen tegelikult "Apache Vs Nginxi artikleid"), millest paljud selgitavad üksikasjalikult nende peamisi funktsioone ja toiminguid erinevate stsenaariumide korral, sealhulgas laborimõõdikute tulemuslikkuse näitajad . Seetõttu seda siin ei käsitleta.

Jagan lihtsalt järgmises jaotises oma kogemusi ja mõtteid kogu arutelu kohta, olles nüüd proovinud Apache'i ja Nginxit, nii tänapäevaste veebirakenduste majutamise nõuetele tuginevates tootmiskeskkondades.

Põhjused, miks ma leian, et Nginx on praktiliselt parem kui Apache

Järgmised põhjused, miks ma eelistan Nginxi veebiserverit Apache'ile kaasaegse veebisisu edastamiseks:

Nginx on seal üks kergemaid veebiservereid. Selle süsteemil on Apache-ga võrreldes väikesed jalajäljed, mis rakendab rakenduse käitamiseks vajalikku suurt funktsionaalsust.

Kuna Nginx paneb kokku käputäie põhifunktsioone, tugineb see kolmandate osapoolte spetsiaalsetele ülesvoolu veebiserveritele nagu Apache'i taustaprogramm, FastCGI, Memcached, SCGI ja uWSGI serverid või rakendusserver, st keelespetsiifilised serverid nagu Node.js, Tomcat , jne.

Seetõttu sobib selle mälukasutus piiratud ressursside juurutamiseks palju paremini kui Apache.

Erinevalt Apache'i keermestatud või protsessile orienteeritud arhitektuurist (protsess-ühenduse või lõime-ühenduse mudel) kasutab Nginx skaleeritavat, sündmustepõhist (asünkroonset) arhitektuuri. Selles kasutatakse vastutustundlikku protsessimudelit, mis on kohandatud olemasolevate riistvararessursside järgi.

Sellel on põhiprotsess (mis täidab privilegeeritud toiminguid, näiteks konfiguratsiooni lugemine ja portidega sidumine) ja mis loob mitu töötaja ja abistaja protsessi.

Töötaja protsessid saavad igaüks korraga käsitseda tuhandeid HTTP-ühendusi, lugeda ja kirjutada sisu kettale ning suhelda ülesvoolu serveritega. Abiprotsessid (vahemäluhaldur ja vahemälulaadur) saavad hallata kettal oleva sisu vahemällu salvestamise toiminguid.

See muudab selle tegevuse skaleeritavaks ja tulemuseks on kõrge jõudlus. See disaini lähenemine muudab selle veelgi kiireks, soodsaks tänapäevaste rakenduste jaoks. Lisaks saab Nginxi natiivfunktsioonide laiendamiseks kasutada kolmanda osapoole mooduleid.

Nginxil on lihtne konfiguratsioonifailide struktuur, mis muudab selle konfigureerimise ülilihtsaks. See koosneb moodulitest, mida juhitakse konfiguratsioonifailis täpsustatud direktiividega. Lisaks jagunevad direktiivid plokidirektiivideks ja lihtsadirektiivideks.

Blokeerimisdirektiiv määratletakse traksidega ( { ja } ). Kui plokidirektiivil võib sulgudes olla muid direktiive, nimetatakse seda kontekstiks nagu sündmused, http, server ja asukoht.

http {
	server {
		
	}
}

Lihtdirektiiv koosneb tühikutega eraldatud nimest ja parameetritest ning lõpeb semikooloniga (;) .

http {
	server {
		location / {
				
				## this is simple directive called root
			   	root  /var/www/hmtl/example.com/;

		}
		
	}
}

Kohandatud konfiguratsioonifaile saate lisada näiteks kaasamisdirektiivi abil.

http {
	server {

	}
	## examples of including additional config files
	include  /path/to/config/file/*.conf;
	include  /path/to/config/file/ssl.conf;
}

Praktiline näide minu jaoks oli see, kuidas mul õnnestus Nginx hõlpsasti konfigureerida mitmete erinevate PHP versioonidega veebisaitide käitamiseks, mis oli Apache'iga väike väljakutse.

Nginxi üks levinumaid kasutusvaldkondi on selle seadistamine puhverserveriks, sellisel juhul võtab see klientidelt vastu HTTP-päringuid ja edastab need erinevate protokollide kaudu ülalpool mainitud puhverserveritele või ülesvoolu serveritele. Samuti saate muuta puhverserverisse saadetud klienditaotluste päiseid ja konfigureerida puhverserveritest pärinevate vastuste puhverdamist.

Seejärel saab ta vastused puhverserveritelt ja edastab need klientidele. Võrreldes Apache'iga on seda lihtsam puhverserverina konfigureerida, kuna nõutavad moodulid on enamasti vaikimisi lubatud.

Staatiline sisu või failid on tavaliselt serverarvutis kettale salvestatud failid, näiteks CSS-failid, JavaScripti failid või pildid. Vaatleme stsenaariumi, kus kasutate Nginxi (rakendusserveri) eessuunana Nginxit.

Kuigi Nodejs-serveril (täpsemalt Node'i raamistikel) on staatiliste failide käitlemiseks sisseehitatud funktsioonid, ei pea nad mittedünaamilise sisu edastamiseks intensiivselt töötlema, seetõttu on praktiliselt kasulik seadistada veebiserver staatilist sisu otse teenindama klientidele.

Nginx suudab palju paremini töödelda kindla kataloogi staatiliste failide käitlemist ja takistab staatiliste varade taotluste lämmatamist ülesvoolu serveri protsessides. See parandab oluliselt taustaprogrammi serverite üldist jõudlust.

Tänapäevaste veebirakenduste suure jõudluse ja tööaja realiseerimiseks võib vaja minna mitme rakenduse eksemplari käitamist ühes või hajutatud HTTP-serveris. See võib omakorda vajada koormuse tasakaalustamise seadistamist koormuse jaotamiseks teie HTTP-serverite vahel.

Tänapäeval on koormuse tasakaalustamisest saanud laialt kasutatav lähenemisviis operatsioonisüsteemi ressursside kasutamise optimeerimiseks, paindlikkuse maksimeerimiseks, latentsuse vähendamiseks, läbilaskevõime suurendamiseks, koondamise saavutamiseks ja tõrketaluvate konfiguratsioonide loomiseks - mitme rakenduse eksemplari puhul.

Nginx kasutab järgmisi koormuse tasakaalustamise meetodeid:

• round-robin (vaikemeetod) - taotlused eelvoolu serveritele jaotatakse ring-robin viisil (ülesvoolu kuuluvate serverite loendi järjekorras).
• kõige vähem ühendatud - siin on järgmine taotlus puhverserveril, kus on kõige vähem aktiivseid ühendusi.
• ip-hash - siin kasutatakse räsifunktsiooni, et määrata, milline server tuleks järgmise päringu jaoks valida (kliendi IP-aadressi põhjal).
• Üldine räsi - selle meetodi abil määrab süsteemiadministraator räsi (või võtme) koos antud tekstiga, päringu või käituse muutujatega või nende kombinatsiooniga. Näiteks võib võti olla allika IP ja port või URI. Seejärel jaotab Nginx koormuse ülesvoolu serverite vahel, genereerides praeguse päringu jaoks räsi ja asetades selle ülesvoolu serverite vastu.
• Vähim aeg (Nginx Plus) - määrab järgmise päringu eelvooluserverile, kus on kõige vähem praeguseid ühendusi, kuid soosib madalaima keskmise reageerimisajaga servereid.

Lisaks on Nginx väga skaleeritav ja kaasaegsed veebirakendused, eriti ettevõtete rakendused nõuavad tehnoloogiat, mis tagab suure jõudluse ja mastaapsuse.

Üks ettevõte, kes kasutab Nginxi hämmastavaid mastaapsuse funktsioone, on CloudFlare, CloudFare'i asutaja ja tegevdirektor Matthew Prince sõnul on see suutnud oma veebirakendusi laiendada suhteliselt tagasihoidliku infrastruktuuriga enam kui 15 miljardi igakuise lehevaatamise haldamiseks.

Põhjalikuma selgituse saamiseks vaadake seda artiklit Nginxi ajaveebis: NGINX vs Apache: Meie vaade aastakümne vanusele küsimusele.

Nii Apache kui ka Nginxi ei saa üksteisega asendada, neil on oma tugevad ja nõrgad küljed. Nginx pakub aga võimsat, paindlikku, skaleeritavat ja turvalist tehnoloogiat kaasaegsete veebisaitide ja veebirakenduste usaldusväärseks ja tõhusaks toiteks. Mis sa võtad? Andke meile sellest teada allpool oleva tagasisidevormi kaudu.