PHP-FPM- ի օպտիմիզացումը բարձր արդյունավետության համար

PHP- ն ամենուրեք է, և, հավանաբար, այն լեզուն է, որն առավել լայն տարածում է գտել Ինտերնետային ցանցում.


Այնուամենայնիվ, այն այնքան էլ հայտնի չէ բարձր կատարողականության հնարավորություններով, մանավանդ, երբ խոսքը վերաբերում է խիստ զուգահեռ համակարգերին: Եվ դա է պատճառը, որ նման մասնագիտացված օգտագործման դեպքերի դեպքում այնպիսի լեզուներ, ինչպիսիք են Node- ը (այո, ես գիտեմ, որ այն լեզուն չէ), Go- ը և Elixir- ը ստանձնում են.

Այսինքն ՝ կա մի շատ բան, որը կարող եք անել ՝ բարելավելու համար PHP- ի աշխատանքը ձեր սերվերում: Այս հոդվածը կենտրոնանում է իրերի php-fpm կողմի վրա, ինչը ձեր սերվերի կազմաձևման բնական միջոցն է, եթե դուք օգտագործում եք Nginx.

Եթե ​​դուք գիտեք, թե որն է php-fpm- ը, ազատ զգալ `օպտիմալացման բաժին ցատկել.

Ինչ է php-fpm?

Ոչ շատ մշակողներ հետաքրքրված չեն դրանով DevOps իրերի կողմը և նույնիսկ նրանց, ովքեր անում են, քչերը գիտեն, թե ինչ է կատարվում գլխարկի տակ: Հետաքրքիր է, որ երբ զննարկիչը հարցում է ուղարկում մի PHP- ով աշխատող սերվերին, այն PHP չէ, որը ստեղծում է առաջին շփման կետը. Փոխարենը, դա HTTP սերվեր է, որի հիմնական մասը `Apache և Nginx: Այս «վեբ սերվերները», այնուհետև պետք է որոշեն, թե ինչպես միանալ PHP- ին և փոխանցել հարցման տեսակը, տվյալները և դրա վերնագրերը.

Հայցադիմումի ցիկլը PHP- ի դեպքում (պատկերի կրեդիտ. ProinerTech)

Ժամանակակից PHP դիմումներում վերը նշված «գտնել ֆայլը» index.php- ն է, որը սերվերը կազմաձևված է բոլոր հարցումները պատվիրելու համար.

Հիմա, թե ինչպես է ճիշտ վեբ սերվերը միանում PHP- ին, զարգացել է, և այս հոդվածը երկարությամբ պայթելու է, եթե մենք մտնեինք բոլոր խիտ գորշությունը: Բայց կոպիտ ասած, այն ժամանակ, երբ Apache- ն գերակշռում էր որպես ընտրության վեբ սերվեր, PHP- ն սերվեր էր, որը ներառված էր սերվերի ներսում.

Այսպիսով, երբ հայցադիմում ստացվի, սերվերը կսկսի նոր գործընթաց, որը ավտոմատ կերպով կներառի PHP- ն և կկատարի այն կատարված: Այս մեթոդը կոչվում էր mod_php, կարճ ՝ «php- ն որպես մոդուլ»: Այս մոտեցումն ուներ իր սահմանափակումները, որոնք Nginx- ը հաղթահարեց php-fpm- ով.

Php-fpm- ում PHP- ի կառավարման պարտականությունն է, գործընթացները սերվերի ներսում գտնվող PHP ծրագրի հետ են: Այլ կերպ ասած, վեբ սերվերը (Nginx, մեր դեպքում) չի հետաքրքրում, թե որտեղ է գտնվում PHP- ն և ինչպես է այն բեռնված, քանի դեռ գիտի, թե ինչպես ուղարկել և ստանալ տվյալներ դրանից: Եթե ​​ցանկանում եք, այս դեպքում կարող եք մտածել PHP- ի մասին, որպես ինքնուրույն այլ սերվեր, որը կառավարում է որոշ PHP գործընթացներ մուտքային դիմումների համար (ուստի, մենք ունենք խնդրանք, որը հասնում է սերվերի, որը ստացվել է սերվերի կողմից և փոխանցվել սերվերին: – բավականին խենթ. :-P).

Եթե ​​դուք արել եք Nginx- ի որևէ պարամետրեր կամ նույնիսկ պարզապես նրանց հպարտացել եք, նման բանի նման եք հանդիպելու.

գտնվելու վայրը \ .php $
try_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix` /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
ներառեք fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

Մեզ հետաքրքրող գիծը հետևյալն է. Fastcgi_pass unix: /run/php/php7.2-fpm.sock ;, որը Nginx- ին ասում է, որ հաղորդակցվի PHP գործընթացի հետ php7.2-fpm.sock անունով վարդակից: Այսպիսով, յուրաքանչյուր մուտքային խնդրանքի համար Nginx- ը տվյալները գրում է այս ֆայլի միջոցով, իսկ արդյունքը ստանալուն պես, այն ուղարկում է զննարկիչ.

Եվս մեկ անգամ պետք է շեշտեմ, որ սա ամենալավ կամ ճշգրիտ պատկերը չէ, թե ինչ է կատարվում, բայց այն լիովին ճշգրիտ է DevOps- ի մեծ թվով առաջադրանքների համար.

Մի կողմ, եկեք արձանագրենք այն, ինչ մինչ այժմ սովորել ենք.

  • PHP- ն ուղղակիորեն չի ստանում բրաուզերների կողմից ուղարկված հարցումները: Nginx- ի նման վեբ սերվերներն առաջին հերթին ընդհատում են դրանք.
  • Վեբ-սերվերը գիտի, թե ինչպես կարելի է միանալ PHP գործընթացին և հարցման բոլոր տվյալները փոխանցում է (բառացիորեն կպցնում է ամեն ինչ) PHP- ին:.
  • Երբ PHP- ն ավարտեց իր մասը կատարելը, պատասխանը հետ է ուղարկում վեբ սերվերին, որը այն ուղարկում է հաճախորդին (կամ զննարկիչը, շատ դեպքերում):.

Կամ գրաֆիկական:

Ինչպե՞ս են աշխատում PHP- ն և Nginx- ը (Image վարկ. DataDog)

Հրաշալի է մինչ այժմ, բայց հիմա գալիս է միլիոնավոր դոլարների հարցը. Որն է իրականում PHP-FPM- ն?

PHP- ի «FPM» մասը նշանակում է «Արագ գործընթաց մենեջեր», որը պարզապես ֆանտաստիկ ձև է այն բանի համար, որ սերվերի վրա աշխատող PHP- ն ոչ թե մեկ գործընթաց է, այլ PHP- ի մի շարք գործընթացներ, որոնք spawned, վերահսկիչ և սպանված են: այս FPM գործընթացների կառավարչի կողմից: Հենց այս գործընթացի կառավարիչն է, որ վեբ սերվերը փոխանցում է հարցումները.

PHP-FPM- ն իրոք նապաստակի մի ամբողջ փոս է, այնպես որ ցանկանաք ազատ ուսումնասիրել, եթե ցանկանաք, բայց մեր նպատակների համար այս շատ բացատրությունը կանի: ��

Ինչու օպտիմալացնել php-fpm?

Ուրեմն ինչու՞ անհանգստանալ այս ամբողջ պարից, երբ ամեն ինչ նորմալ է ընթանում: Ինչու ոչ միայն թողնել իրերն այնպես, ինչպես կան.

Զարմանալի է, որ դա հենց այն խորհուրդն է, որը ես տալիս եմ առավելագույն օգտագործման դեպքերի համար: Եթե ​​ձեր կարգավորումը լավ է աշխատում և արտառոց օգտագործման դեպքեր չունեք, օգտագործեք կանխադրված կանխավճարները: Այնուամենայնիվ, եթե ցանկանում եք մասշտաբով մեկ մեքենայից դուրս գալ, ապա առավելագույնը մեկից սեղմելը անհրաժեշտ է, քանի որ այն կարող է կրճատել սերվերի հաշիվները կիսով չափ (կամ նույնիսկ ավելին):.

Մեկ այլ բան պետք է գիտակցել, որ Nginx- ը կառուցվել է հսկայական ծանրաբեռնվածություն բեռնաթափելու համար: Այն ունակ է միաժամանակ կարգավորել հազարավոր կապեր, բայց եթե նույնը չի համապատասխանում ձեր PHP- ի կարգավորմանը, ապա դուք պարզապես պատրաստվում եք վատնել ռեսուրսները, քանի որ Nginx- ը ստիպված կլինի սպասել, որ PHP- ն ավարտի ընթացիկ գործընթացը և ընդունի Հաջորդը ՝ միանշանակ բացասական, այն առավելությունները, որոնք կառուցվել է Nginx- ը!

Այնպես որ, դրանից դուրս, եկեք նայենք, թե կոնկրետ ինչ ենք փոխելու, երբ փորձում ենք օպտիմալացնել php-fpm.

Ինչպես օպտիմալացնել PHP-FPM?

Php-fpm- ի կազմաձևման ֆայլի գտնվելու վայրը կարող է տարբեր լինել սերվերի վրա, ուստի այն գտնելու համար անհրաժեշտ է կատարել որոշակի հետազոտություն: Դուք կարող եք օգտագործել find հրամանը, եթե UNIX- ում է: Իմ Ուբունտուի վրա ճանապարհը /etc/php/7.2/fpm/php-fpm.conf է: 7.2-ը, իհարկե, PHP- ի տարբերակն է, որը ես վարում եմ.

Ահա, թե ինչպես են այս ֆայլի առաջին մի քանի տողերը.

;;;;;;;;;;;;;;;;;;
; FPM կազմաձևում;
;;;;;;;;;;;;;;;;;;

; Այս կազմաձևման ֆայլի բոլոր հարաբերական ուղիները համեմատելի են PHP- ի տեղադրմանը
; նախածանց (/ usr): Այս նախածանցը կարող է դինամիկ փոփոխվել `օգտագործելով the
; ‘-p’ փաստարկը հրամանի տողից.

;;;;;;;;;;;;;;;;;;
; Համաշխարհային ընտրանքներ;
;;;;;;;;;;;;;;;;;;

[համաշխարհային]
; Pid ֆայլ
; Նշում. Լռելյայն նախածանցը / var է
; Լռելյայն արժեք. Ոչ մեկը
pid = /run/php/php7.2-fpm.pid

; Սխալ գրանցման ֆայլ
; Եթե ​​այն դրված է "syslog", տեղեկամատյանն ուղարկվում է syslogd- ին `գրելու փոխարեն
; տեղական ֆայլի մեջ.
; Նշում. Լռելյայն նախածանցը / var է
; Լռելյայն արժեք ՝ log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

Մի քանի բան պետք է անհապաղ ակնհայտ լինի. Տողը pid = /run/php/php7.2-fpm.pid- ը մեզ ասում է, թե որ ֆայլը պարունակում է php-fpm գործընթացի գործընթացի ID- ն:.

Մենք նաև տեսնում ենք, որ /var/log/php7.2-fpm.log- ն է, որտեղ php-fpm- ը պատրաստվում է պահել իր տեղեկամատյանները.

Այս ֆայլի ներսում ավելացնել ևս երեք փոփոխական, ինչպիսիք են.

emer_restart_threshold 10
emer_restart_interval 1 մ
process_control_timeout 10s

Առաջին երկու պարամետրերը զգուշավոր են և php-fpm գործընթացին ասում են, որ եթե տասը երեխայի գործընթացները մեկ րոպեի ընթացքում ձախողվեն, ապա հիմնական php-fpm գործընթացը պետք է վերագործարկվի իրեն.

Սա գուցե ուժեղ չի թվում, բայց PHP- ն կարճատև գործընթաց է, որն արտահոսում է հիշողությունը, ուստի բարձր գործընթացը ձախողելու դեպքում հիմնական գործընթացը վերսկսելը կարող է լուծել բազմաթիվ խնդիրներ.

Երրորդ տարբերակը ՝ process_control_timeout- ը, պատմում է, որ երեխան գործընթացներին սպասի այս շատ ժամանակ, նախքան ծնողական գործընթացից ստացված ազդանշանը գործարկելը: Սա օգտակար է այն դեպքերում, երբ երեխայի գործընթացները գտնվում են ինչ-որ բանի մեջտեղում, երբ ծնողական գործընթացները, օրինակ, ուղարկում են KILL ազդանշան: Ձեռք բերելով տասը վայրկյան, նրանք ավելի լավ հնարավորություն կունենան ավարտելու իրենց առջև դրված խնդիրները և բարեհամբույր դուրս գալ.

Զարմանալի է, որ սա php-fpm կոնֆիգուրացիայի միս չէ: Դա այն պատճառով է, որ վեբ դիմումները սպասարկելու համար php-fpm ստեղծում է գործընթացների նոր բաղկացուցիչ, որը կունենա առանձին կազմաձևում: Իմ դեպքում, լողավազանի անունը պարզվեց ՝ www, և այն ֆայլը, որը ես ցանկանում էի խմբագրել, /etc/php/7.2/fpm/pool.d/www.conf.

Տեսնենք, թե ինչպես է սկսվում այս ֆայլը.

; Սկսեք «www» անունով նոր լողավազան.
; փոփոխական $ լողավազան կարող է օգտագործվել ցանկացած հրահանգում և կփոխարինվի դրանով
; լողավազան անվանում («այստեղ www»)
[www]

; Լողավազան նախածանցով
; Այն վերաբերում է միայն հետևյալ հրահանգներին.
; – ‘մուտք.լոգ’
; – «դանդաղաշարժ»
; – ‘լսել’ (unixsocket)
; – «խրոխտ»
; – ‘chdir’
; – ‘php_values’
; – ‘php_admin_values’
; Երբ սահմանված չէ, դրա փոխարեն կիրառվում է համաշխարհային նախածանց (կամ / usr).
; Նշում. Այս հրահանգը կարող է նաև հարաբերական լինել համաշխարհային նախածանցի հետ.
; Լռելյայն արժեք. Ոչ մեկը
; նախածանց = / ուղի / դեպի / լողավազան / $ լողավազան

; Unix օգտվող / գործընթացների խումբ
; Նշում. Օգտագործողը պարտադիր է: Եթե ​​խումբը սահմանված չէ, կանխադրված օգտվողի խումբը
; կօգտագործվի.
օգտվող = www-տվյալներ
խումբ = www-տվյալներ

Վերևի հատվածի ավարտին արագ դիտելը լուծում է հանելուկը, թե ինչու է սերվերի գործընթացը գործում որպես www- տվյալներ: Եթե ​​ձեր վեբ կայքի ստեղծման ժամանակ բախվել եք ֆայլերի թույլտվության հետ կապված խնդիրներ, դուք, ամենայն հավանականությամբ, փոխել եք գրացուցակի սեփականատերը կամ գրացուցակի խումբը դեպի տվյալների տվյալների ՝ այսպիսով թույլ տալով, որ PHP գործընթացը կարողանա մուտք գործել մուտք ֆայլեր և վերբեռնել փաստաթղթեր և այլն:.

Վերջապես, մենք հասնում ենք հարցի աղբյուրին ՝ գործընթացների կառավարչի (երեկոյան) կայացմանը: Ընդհանրապես, կանխավարկածները կտեսնեք այսպիսի նման բան.

երեկո = դինամիկ
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Այսպիսով, ի՞նչ է նշանակումդինամիկ«Այստեղ նկատի ունեք Կարծում եմ, որ պաշտոնական փաստաթղթերը դա ամենալավն են բացատրում (նկատի ունեմ, որ սա արդեն պետք է լինի այն խմբագրման մի մասը, որը դուք խմբագրում եք, բայց ես այն վերարտադրել եմ այստեղ հենց այն դեպքում, եթե դա այդպես չէ):

; Ընտրեք, թե ինչպես է գործընթացը ղեկավարը վերահսկելու երեխաների գործընթացների քանակը.
; Հնարավոր արժեքներ.
; ստատիկ – մանկական գործընթացների ֆիքսված համար (pm.max_children);
; դինամիկ. երեխաների պրոցեսների քանակը դինամիկորեն սահմանվում է
; հետևյալ հրահանգներին: Այս գործընթացի կառավարմամբ, կլինեն
; միշտ առնվազն 1 երեխա.
; pm.max_children – առավելագույն թվով երեխաներ, որոնք կարող են
; միևնույն ժամանակ կենդանի եղեք.
; pm.start_servers – գործարկման ժամանակ ստեղծված երեխաների քանակը.
; pm.min_spare_servers. «պարապ» երեխաների նվազագույն քանակը
; պետություն (սպասում է մշակման): Եթե ​​համարը
; «պարապ» գործընթացներից սա պակաս է
; համարը, ապա կստեղծվեն որոշ երեխաներ.
; pm.max_spare_servers. «պարապ» երեխաների առավելագույն քանակը
; պետություն (սպասում է մշակման): Եթե ​​համարը
; «պարապ» գործընթացներից սա ավելին է
; համարը, ապա որոշ երեխաներ կսպանվեն.
; ondemand – ի սկզբանե ոչ մի երեխա չի ստեղծվում: Երբ երեխաները կդիմակարդվեն, երբ
; նոր հարցումները կմիանան: Օգտագործվում է հետևյալ պարամետրը.
; pm.max_children – երեխաների առավելագույն քանակը, որ
; կարող է միաժամանակ կենդանի լինել.
; pm.process_idle_timeout – Դրանից հետո վայրկյանների քանակը
; պարապ գործընթաց կսպանվի.
; Նշում. Այս արժեքը պարտադիր է.

Այսպիսով, մենք տեսնում ենք, որ կան երեք հնարավոր արժեքներ.

  • ՍտատիկPHP գործընթացների ֆիքսված թիվ կպահպանվի ՝ անկախ նրանից.
  • ԴինամիկՄենք պետք է նշենք այն նվազագույն և առավելագույն քանակը պրոցեսների, որոնք php-fpm կպահպանվեն ցանկացած պահի.
  • բողոքարկելԳործընթացները ստեղծվում և ոչնչացվում են, պահանջարկից ելնելով.

Այսպիսով, ինչպե՞ս են կարևոր այս պարամետրերը?

Պարզ խոսքով, եթե ունեք ցածր երթևեկություն ունեցող կայք, «դինամիկ» պարամետրը ժամանակի մեծ մասի վատնում է: Ենթադրելով, որ դուք ունեք pm.min_spare_servers- ը դրված 3-ի, PHP- ի երեք գործընթաց կստեղծվի և կպահպանվի նույնիսկ այն դեպքում, երբ կայքում երթևեկություն չկա: Նման դեպքերում «ondemand» – ը ավելի լավ տարբերակ է `թույլ տալով, որ համակարգը որոշի, թե երբ է սկսվելու նոր գործընթացները.

Մյուս կողմից, վեբ կայքերը, որոնք կառավարում են մեծ քանակությամբ երթևեկություն կամ պետք է արագ արձագանքեն, պատժվում են այս պարամետրում: PHP- ի նոր գործընթաց ստեղծելը, լողավազանի մաս դարձնելը և դրա մոնիտորինգը կատարելը լրացուցիչ գերհագեցում է, որից առավելագույնս խուսափվում է.

Օգտագործելով pm = ստատիկը ամրագրում է երեխաների գործընթացների քանակը ՝ թույլ տալով, որ առավելագույն համակարգային ռեսուրսները օգտագործվեն խնդրանքները կատարելիս, այլ ոչ թե PHP- ի կառավարման մեջ: Եթե ​​գնում եք այս ճանապարհով, զգուշացեք, որ այն ունի իր ուղեցույցները և որոգայթները: Դրա մասին բավականին խիտ, բայց շատ օգտակար հոդված է այստեղ.

Վերջնական բառերը

Քանի որ համացանցային գործունեության մասին հոդվածները կարող են պատերազմներ հարուցել կամ մարդկանց շփոթելուն ծառայել, ես կարծում եմ, որ մի քանի բառ կարգի են գալիս, նախքան այս հոդվածը փակելը: Ներկայացման թյունինգը նույնն է գուշակությունների և մութ արվեստների մասին, որքան համակարգային գիտելիքները.

Նույնիսկ եթե դուք գիտեք php-fpm- ի բոլոր պարամետրերը սրտանց, հաջողությունը երաշխավորված չէ: Եթե ​​php-fpm- ի գոյության մասին որևէ տեղեկություն չունեիք, ապա հարկ չկա ժամանակ վատնել դրա մասին անհանգստանալու մասին: Պարզապես շարունակեք անել այն, ինչ արդեն անում եք և շարունակեք.

Միևնույն ժամանակ, խուսափեք կատարողական ջունկեր լինելու ավարտից: Այո, դուք կարող եք ավելի լավ կատարողականություն ունենալ ՝ վերամշակելով PHP- ն զրոյից և հանելով ձեր օգտագործած բոլոր մոդուլները, բայց արտադրության միջավայրում այդ մոտեցումը այնքան էլ լավ չէ: Ինչ-որ բան օպտիմիզացնելու ամբողջ գաղափարն այն է, հաշվի առնել, թե արդյոք ձեր կարիքները տարբերվում են կանխավճարներից (ինչը նրանք հազվադեպ են անում): և անհրաժեշտության դեպքում փոքր փոփոխություններ կատարել:.

Եթե ​​պատրաստ չեք ժամանակ ծախսել ձեր PHP սերվերների օպտիմիզացման վրա, ապա գուցե մտածեք հուսալի պլատֆորմի կիրառումը Կինստա ովքեր հոգ են տանում կատարողականի օպտիմիզացման և անվտանգության մասին.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map