php.ini-ს მნიშვნელოვანი პარამეტრები და ნაგულისხმევები, რომლებიც უნდა შეიცვალოს

PHP-ს რამდენიმე ასეული დირექტივა მოყვება და მათგან დაახლოებით რვა წყვეტს, იმუშავებს თუ არა შენი საიტი. memory_limit 128 MB-ზე, upload_max_filesize 2 MB-ზე, post_max_size 8 MB-ზე, max_execution_time 30 წამზე და max_input_vars 1,000-ზე - ეს ნაგულისხმევებია იმ შეცდომების უმეტესობის უკან, რომლებსაც ხალხი ჰოსტინგის მხარდაჭერას მიაქვს, და თითოეულს კონკრეტული სიმპტომი აქვს, რომელიც მას ამოიცნობს.

პრობლემის მეორე ნახევარი ისაა, რომ მნიშვნელობის შეცვლა და ეფექტის არქონა ნორმალურია. PHP კითხულობს კონფიგურაციის ფაილს, რომლის მდებარეობა იმაზეა დამოკიდებული, როგორ არის გაშვებული, უგულებელყოფს .htaccess-ის დირექტივებს, თუ Apache-ის მოდულად არ მუშაობს, გაშვების დროს მხოლოდ ზოგიერთი პარამეტრის შეცვლის უფლებას გაძლევს და მას შეიძლება PHP-FPM-ის pool გადაფაროს, რომელიც ყველაფერზე მაღლა დგას. ამიტომ ყველაფერი ფაილის პოვნით იწყება.

რომელ ფაილს კითხულობს PHP სინამდვილეში#

თითო PHP-ის დაყენებაზე ერთი php.ini არსებობს და ერთ მანქანაზე ხშირად რამდენიმე დაყენებაა - ვებ სერვერისა და ბრძანების ხაზისა რეგულარულად განსხვავდება, სწორედ ამიტომ მუშაობს SSH-ით სკრიპტი, რომელიც ბრაუზერში ვარდება. ივარაუდე კი არა, ჰკითხე PHP-ს:

$ php --iniConfiguration File (php.ini) Path: /etc/php/8.2/cliLoaded Configuration File:         /etc/php/8.2/cli/php.iniScan for additional .ini files in: /etc/php/8.2/cli/conf.d

ეს ბრძანების ხაზისაა. იმ მნიშვნელობებისთვის, რომლითაც შენი საიტი მუშაობს, ვებ-ძირში ჩასვი ერთი ფაილი phpinfo();-ით, გახსენი ბრაუზერში, წაიკითხე Loaded Configuration File ხაზი ზემოთ და ფაილი მაშინვე წაშალე - ის შენს გზებს, გაფართოებებსა და გარემოს ყველას უჩვენებს, ვინც URL-ს იპოვის.

მნიშვნელობა ოთხ მექანიზმს შეუძლია დააყენოს და ისინი ამ თანმიმდევრობით მოქმედებს:

ორი შედეგი ხალხს იჭერს. პირველი, .htaccess-ში php_value ხაზები მხოლოდ მაშინ მუშაობს, როცა PHP Apache-ის მოდულად გადის; PHP-FPM-ის ქვეშ, რასაც დღეს თითქმის ყველა იყენებს, ისინი საუკეთესო შემთხვევაში იგნორირდება, უარეს შემთხვევაში კი 500-ს იწვევს. ექვივალენტი იმავე დირექტორიაში .user.ini ფაილია. მეორე, .user.ini-ის ცვლილებები იქეშება - ნაგულისხმევი user_ini.cache_ttl 300 წამია - ამიტომ ხუთი წუთის ლოდინი, სანამ გადაწყვეტ, რომ შენმა ცვლილებამ არაფერი მოიმოქმედა, ბევრ დაბნეულობას გიზოგავს.

ასევე გაითვალისწინე, რომ .user.ini-ს მხოლოდ PHP_INI_PERDIR და PHP_INI_USER კლასის დირექტივების დაყენება შეუძლია. upload_max_filesize ერთ-ერთი მათგანია. ბევრი სხვა არ არის და მათთვის ნამდვილი php.ini ან pool-ის კონფიგურაცია გჭირდება, რაც მართულ ჰოსტინგზე იმას ნიშნავს, რომ ვინც მას უძღვება, იმას უნდა სთხოვო.

memory_limit#

memory_limit ზღუდავს, რამდენი მეხსიერების გამოყოფა შეუძლია ერთ PHP პროცესს ერთი მოთხოვნისთვის. მოწოდებული ნაგულისხმევი 128 MB-ია. როცა მოთხოვნა მას აჭარბებს, PHP ფატალური შეცდომით ჩერდება, რომელიც რიცხვს ზუსტად ასახელებს:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted(tried to allocate 20480 bytes) in /var/www/wp-includes/wp-db.php on line 2056

პატარა WordPress საიტისთვის 128 MB საკმარისია. საიტისთვის, რომელსაც page builder, მაღაზია და ოცდაათი plugin აქვს, რეალისტური ციფრი 256 MB-ია, ხოლო 512 MB ის არის, რაც სურათების დამუშავებას და იმპორტის დავალებებს სურთ. ამაზე მეტი რომ გჭირდება, კოდზე იეჭვე: plugin, რომელიც ყველა პოსტს მასივში ტვირთავს, მეტ მეხსიერებას კი არ საჭიროებს, გასწორება სჭირდება.

memory_limit = 256M

სამი რამ, რაც ღირს იცოდე:

• ეს თითო მოთხოვნაზეა და არა თითო საიტზე. ათ ერთდროულ მოთხოვნას თითო 256 MB-ით 2.5 GB-ის მოთხოვნა შეუძლია. ლიმიტი ერთი პროცესის ჭერია, პროცესების რაოდენობა კი ის არის, რაც მას ამრავლებს - იხილე PHP-FPM-ის ნაწილი ქვემოთ.
• მისი `-1`-ზე დაყენება ვებ სერვერზე ცუდი იდეაა. ულიმიტო ნიშნავს, რომ ერთ გაუკონტროლებელ მოთხოვნას მთელი კონტეინერის მეხსიერების ლიმიტამდე მიყვანა შეუძლია, რასაც შედეგად ყველაფერი კვდება და არა ერთი მოთხოვნა სუფთად ვარდება. ბევრი დისტრიბუცია ბრძანების ხაზის ინტერპრეტატორისთვის მართლაც -1-ს აწვდის, სწორედ ამიტომ მუშაობს გრძელი იმპორტი shell-იდან და ვარდება ბრაუზერში.
• WordPress-ს საკუთარი ლიმიტი აქვს ზემოდან. WP_MEMORY_LIMIT ნაგულისხმევად ფრონტისთვის 40 MB-ია, WP_MAX_MEMORY_LIMIT კი ადმინ გვერდებისთვის 256 MB. WordPress საკუთარ ლიმიტს მხოლოდ იმ ფარგლებში ზრდის, რასაც PHP უშვებს, ამიტომ ორივე სწორი უნდა იყოს. WordPress-ის ხელით დაყენება გვიჩვენებს, სად იწერება ეს კონსტანტები.

კონტეინერზე დაფუძნებულ ჰოსტინგზე მესამე ჭერიც არსებობს: თავად კონტეინერის მეხსიერება. 1 GB-იანი გეგმა და memory_limit 512 MB-ზე ორ მძიმე მოთხოვნას ერთდროულად ატანს, სანამ kernel კონტეინერს გააჩერებს. RE:NODE-ზე კონტეინერის ლიმიტის მიღწევა მას აჩერებს და სუფთად რესტარტავს და არ ტოვებს swap-ში, ამიტომ საიტი სწრაფად ბრუნდება, მაგრამ მიმდინარე მოთხოვნები იკარგება. memory_limit-ის ზომა და worker-ების რაოდენობა გეგმასთან ერთად დაადგინე - რამდენი RAM სჭირდება WordPress-ს არითმეტიკას აკეთებს.

ატვირთვის ზომა: სამი ლიმიტი და არა ერთი#

ატვირთვის ჩავარდნა php.ini-ს ყველაზე გავრცელებული კითხვაა და მას ჩვეულებრივ ერთ პარამეტრს აბრალებენ, როცა სამი-ოთხია ჩართული.

ისინი თანმიმდევრულები უნდა იყვნენ და თანმიმდევრობას მნიშვნელობა აქვს: post_max_size უნდა იყოს upload_max_filesize-ზე დიდი, რადგან მოთხოვნის სხეული შეიცავს ფაილს, მის ფორმის ველებს და multipart-ის ზედმეტ ბაიტებს. გონივრული ნაკრები საიტისთვის, რომელიც 64 MB ატვირთვას იღებს:

upload_max_filesize = 64Mpost_max_size = 72Mmemory_limit = 256Mmax_execution_time = 120

თუ ატვირთვა მაინც PHP-ის შეცდომის ნაცვლად 413-ით ვარდება, ლიმიტი PHP-ის არ არის. წინ მდგომ reverse proxy-ს ან ვებ სერვერს საკუთარი სხეულის ზომის ზღვარი აქვს - nginx-ში ეს client_max_body_size-ია, რომლის ნაგულისხმევიც 1 MB-ია - და ის მოთხოვნას PHP-მდე უარყოფს. მართულ ჰოსტინგზე ამას პირდაპირ ვერ აკონტროლებ, რაც კარგი მიზეზია, რომ ბაზის დიდი dump-ები ნედლი ფაილის ნაცვლად gzip-ით დაარქივებულად შემოიტანო. რას აკეთებს reverse proxy განმარტავს, რომელი ლიმიტი სად ცხოვრობს.

max_execution_time და მის გარშემო მყოფი timeout-ები#

max_execution_time ნაგულისხმევად 30 წამია და ითვლის მხოლოდ იმ დროს, როცა თავად PHP სრულდება - Unix build-ებზე არა ბაზის მოთხოვნაზე ან გარე API-ზე ლოდინის დროს. ბრძანების ხაზის ინტერპრეტატორი მას 0-ზე, ულიმიტოზე ადგენს, რაც კიდევ ერთი მიზეზია, რის გამოც shell სკრიპტები სხვანაირად იქცევა.

გაზარდე კონკრეტული საქმისთვის და არა გლობალურად. 300-წამიანი გლობალური ლიმიტი ნიშნავს, რომ გაჭედილი მოთხოვნა worker-ს ხუთი წუთით იკავებს, ოცი ასეთი კი pool-ს ავსებს. გრძელი სამუშაო იქ დადე, სადაც ეკუთვნის: დაგეგმილ დავალებაში, რიგში ან ბრძანების ხაზზე.

მის გარშემო სამი სხვა timeout დგას, რომელიც მოთხოვნას შეწყვეტს, რასაც PHP არ უნდა ფიქრობდეს:

• `max_input_time` ზღუდავს მოთხოვნის სხეულის დამუშავებას, რაც ნელ ატვირთვებზე მნიშვნელოვანია. ჩაშენებული ნაგულისხმევი -1 ნიშნავს, რომ ის max_execution_time-ზე გადადის, მოწოდებული production ფაილი კი 60 წამს აყენებს.
• PHP-FPM-ის `request_terminate_timeout` worker-ს პირდაპირ კლავს. ის max_execution_time-ს გადაფარავს და PHP-ის შეცდომის ნაცვლად 502-ს იძლევა, ამიტომ მოთხოვნა, რომელიც PHP-ის შეცდომების ლოგში ჩანაწერის გარეშე კვდება, ჩვეულებრივ აქ მოკვდა.
• proxy-ის საკუთარი read timeout, ჩვეულებრივ 60 წამი, რომელიც ვიზიტორს 504-ს უბრუნებს, PHP კი უხილავად აგრძელებს მუშაობას.

plugin-ის იმპორტერი, რომელიც "ყოველთვის 60 პროცენტზე ჩერდება", თითქმის ყოველთვის ბოლო ორიდან ერთია და არა პირველი.

max_input_vars, უხმო პარამეტრი#

max_input_vars ზღუდავს, რამდენი ცვლადის გაგზავნა შეუძლია ერთ მოთხოვნას და ნაგულისხმევი 1,000-ია. ის სიაში ყველაზე მზაკვარი პარამეტრია, რადგან მისი გადაჭარბება არავითარ შეცდომას არ იძლევა: PHP შეყვანას ჭრის და სკრიპტს არასრულ მასივს გადასცემს.

სიმპტომები ისეთია, რომელთაც არავინ აკავშირებს კონფიგურაციის ფაილთან. WordPress-ის მენიუ 120 ელემენტით პირველ 90-ს ინახავს და დანარჩენს კარგავს. თემის პარამეტრების გვერდი ველების ნახევარს აბრუნებს. WooCommerce-ის პროდუქტი ბევრი ვარიაციით შენახვისას მათ კარგავს. მასობრივი რედაქტირება მხოლოდ ზოგიერთ რიგზე მოქმედებს.

max_input_vars = 5000

ყოველი ჩადგმული მასივის ელემენტი ცვლადად ითვლება, ამიტომ დიდი მენიუ ან ცვლადიანი პროდუქტი 1,000-ს რიცხვის მიხედვით ვარაუდზე გაცილებით ადრე აღწევს. 3,000-დან 5,000-მდე გონივრული პარამეტრია; ამაზე ბევრად მაღლა წასვლა იმ ფორმის დამალვაა, რომელიც გვერდებად უნდა დაიყოს.

OPcache და realpath cache#

OPcache-ის გარეშე PHP ყოველ მოთხოვნაზე ყოველ ფაილს ანალიზებს და აკომპილირებს. მასთან დაკომპილირებული opcode-ები გაზიარებულ მეხსიერებაში ინახება და ხელახლა გამოიყენება, რაც ათასობით პატარა ფაილისგან შემდგარ ნებისმიერ აპლიკაციაზე PHP-ის დროის დიდ ნაწილს იძლევა.

opcache.enable = 1opcache.memory_consumption = 192opcache.interned_strings_buffer = 16opcache.max_accelerated_files = 20000opcache.validate_timestamps = 1opcache.revalidate_freq = 2realpath_cache_size = 4096Krealpath_cache_ttl = 600

რას აკეთებს ეს მნიშვნელობები და რატომ არის მოწოდებულები ხშირად ძალიან მცირე:

• `opcache.memory_consumption` 128 MB-ით მოდის. როცა ივსება, OPcache უხმოდ წყვეტს ახალი ფაილების ქეშირებას და საიტი შეცდომის გარეშე ნელდება. შეამოწმე opcache_get_status()-ით used_memory და ქეშირებული გასაღებების რაოდენობა მაქსიმუმთან შედარებით.
• `opcache.max_accelerated_files` 10,000-ით მოდის, რაც დიდ აპლიკაციას ბევრი plugin-ით რეალურად შეუძლია გადააჭარბოს. მნიშვნელობა შიგნით მარტივ რიცხვზე დაფუძნებულ ციფრამდე მრგვალდება, ამიტომ 20,000-ის დაყენება ჩვეულებრივია.
• `opcache.validate_timestamps` 1-ზე ნიშნავს, რომ PHP ფაილის ცვლილების დროს ყოველ revalidate_freq წამში ამოწმებს. 0-ზე დაყენება უფრო სწრაფია და სწორია განთავსებული აპლიკაციისთვის, რომლის PHP-ს ყოველი რელიზის შემდეგ გადატვირთავ. ის არასწორია ყველაფრისთვის, რაც საკუთარ ფაილებს ვებ ინტერფეისიდან ანახლებს, როგორიცაა WordPress, რადგან განახლებები თითქოს არ მოქმედებს, სანამ PHP არ გადაიტვირთება.
• realpath cache გადაწყვეტილ ფაილის გზებს ინახავს. ნაგულისხმევი 4 MB პატარაა framework-ისთვის ღრმა autoload გზებით; მისი გაზრდა და TTL-ის გახანგრძლივება გასაკვირად ბევრ stat გამოძახებას აქრობს.
• JIT ნაგულისხმევად პრაქტიკულად გამორთულია, რადგან opcache.jit_buffer_size 0-ია, სანამ არ დააყენებ. ასე დატოვე ვებ აპლიკაციებისთვის: მოგება რიცხვით და დიდხანს მომუშავე სამუშაოში დევს და არა მოთხოვნისებრ კოდში, რომელიც დროს ბაზაში ხარჯავს. WordPress-ის სიჩქარე და ქეშირება OPcache-ს იმ რამეების თანმიმდევრობაში აყენებს, რომლებიც time to first byte-ს რეალურად ამოძრავებს.

შეცდომები, ლოგები და რასაც ვიზიტორები არასოდეს უნდა ხედავდნენ#

production-ის ნაგულისხმევებს მიზეზი აქვს: ცოცხალ გვერდზე შეცდომის შეტყობინება თავდამსხმელს შენს აბსოლუტურ გზებს, ბაზის სტრუქტურას და ზოგჯერ მონაცემებსაც ამხელს.

display_errors = Offdisplay_startup_errors = Offlog_errors = Onerror_log = /var/log/php/error.logerror_reporting = E_ALL & ~E_DEPRECATEDexpose_php = Off

display_errors გამორთული და log_errors ჩართული მთელი წესია: ბრაუზერს არაფერი, ფაილს ყველაფერი, რომელსაც წაიკითხავ. error_log დააყენე გზაზე, რომელშიც PHP-ს წერა შეუძლია, ან დატოვე დაუყენებელი და შეცდომები ვებ სერვერის ლოგში წავა, სადაც პანელის კონსოლი მათ აჩვენებს. expose_php გამორთული X-Powered-By header-ს შენი PHP-ის ზუსტი ვერსიით აშორებს - წვრილმანია და უფასო.

სატესტო ასლზე ჩართე display_errors და error_reporting დააყენე E_ALL-ზე, deprecation-ების ჩათვლით. deprecation შეტყობინებები გიჩვენებს წინასწარ, რომელი plugin-ები გაფუჭდება PHP-ს შემდეგ ვერსიაზე, რაც განახლების დღეს გაგებაზე გაცილებით უკეთესია.

უსაფრთხოებასთან დაკავშირებული პარამეტრები#

რამდენიმე დირექტივა განზრახ დაყენებად ღირს და რამდენიმე პოპულარულს რეპუტაციაზე ნაკლები ღირებულება აქვს.

• `allow_url_fopen` ნაგულისხმევად ჩართულია და file_get_contents()-ს URL-ის წამოღების საშუალებას აძლევს. მისი გამორთვა server-side request forgery-ის ერთ კლასს ბლოკავს და ტეხავს plugin-ებს, რომლებიც cURL-ის ნაცვლად ამას იყენებენ. გამოსცადე, სანამ დააფიქსირებ. მისი საშიში ნათესავი allow_url_include PHP 7.4-ში deprecated გახდა და 8.0-ში წაიშალა, ამიტომ ეს აღარ არის შენი პრობლემა.
• `disable_functions` შეუძლია exec, shell_exec, passthru, system და proc_open მოხსნას. ეს რეალურად ზღუდავს, რისი გაკეთება შეუძლია ატვირთულ web shell-ს. ის ასევე ტეხავს backup plugin-ებს, რომლებიც mysqldump-ს იძახებენ, და სურათების ინსტრუმენტებს, რომლებიც imagick-ის binary-ებს უძახიან, ამიტომ ჯერ შეამოწმე, რას იყენებს შენი სტეკი.
• სესიის cookie-ები. session.cookie_httponly = 1, session.cookie_secure = 1 HTTPS საიტზე, session.use_strict_mode = 1 და session.cookie_samesite = Lax. framework-ები ჩვეულებრივ საკუთარ სესიის cookie-ებს აყენებენ და ამათ უგულებელყოფენ, მაგრამ ყველაფერი, რაც ნედლ PHP სესიებს იყენებს, სარგებლობს.
• `open_basedir` ზღუდავს, რომელ დირექტორიებს შეხება შეუძლია PHP-ს. სასარგებლოა მანქანაზე, რომელიც რამდენიმე საიტს ერთი PHP პროცესის ქვეშ მასპინძლობს; დიდწილად ზედმეტია, როცა თითო საიტი საკუთარი კონტეინერია, სწორედ ეს არის მოდელი RE:NODE-ზე, სადაც ყოველი სერვერი საკუთარ კონტეინერში მუშაობს იმ CPU-თი და მეხსიერებით, რაც გეგმამ შეიძინა.
• `date.timezone` უსაფრთხოება არ არის, მაგრამ დააყენე UTC-ზე და ყველაფერი UTC-ში შეინახე. დაგეგმილი დავალებებიც და ლოგების შეპირისპირებაც მარტივდება, ზაფხულის დროზე გადასვლა კი წლიური ინციდენტი აღარ არის.

PHP-FPM: პარამეტრები, რომლებიც php.ini-ში არ არის#

pool-ის კონფიგურაცია განსაზღვრავს, რამდენ მოთხოვნას შეუძლია ერთდროულად შესრულება, და ის ცალკე ფაილია - ჩვეულებრივ /etc/php/8.2/fpm/pool.d/www.conf.

pm = dynamicpm.max_children = 12pm.start_servers = 3pm.min_spare_servers = 2pm.max_spare_servers = 6pm.max_requests = 500request_terminate_timeout = 120php_admin_value[memory_limit] = 256M

pm.max_children მთავარია და ის მეხსიერების გამოთვლაა და არა უპირატესობა:

pm.max_children = (memory available to PHP) / (average process size)

WordPress-ის worker ჩვეულებრივ 40-იდან 80 MB-მდე resident მეხსიერებას იკავებს. 1 GB-იან გეგმაზე, ვებ სერვერისა და დანარჩენის შემდეგ, ეს დაახლოებით რვა-თორმეტი შვილობილი პროცესია. მისი 50-ზე დაყენება სიმძლავრეს არ ქმნის; ის ქმნის მანქანას, რომელიც იმ დატვირთვის ქვეშ კვდება, რომელსაც უნდა გადაეტანა. pm = ondemand პატარა საიტს მცირე ტრაფიკით შეესაბამება, რადგან უსაქმო worker-ები გადიან და მეხსიერებას აბრუნებენ.

pm.max_requests ყოველ worker-ს გარკვეული რაოდენობის მოთხოვნის შემდეგ ანახლებს, რაც მესამე მხარის გაფართოებებში ნელ მეხსიერების გაჟონვებს ფარავს. 500-იდან 1,000-მდე ნორმალურია, ფასი კი უმნიშვნელოა.

გაითვალისწინე php_admin_value[memory_limit]: ასე დაყენებულ მნიშვნელობებს კოდში ini_set() ვერ გადაფარავს, რითაც ჰოსტი ლიმიტს ამყარებს. თუ wp-config.php-ში memory_limit-ს ზრდი და არაფერი იცვლება, ჩვეულებრივ ეს არის მიზეზი. პანელის ჰოსტინგზე იგივე იდეა ეძებე, გამოხატული გარემოს ცვლადად ან გაშვების ველად და არა ფაილად, რომელსაც რედაქტირებ - და თუ შენთვის საჭირო პარამეტრს PHP დირექტორიის დონის ფაილით შეცვლის უფლებას არ აძლევს, ეს არის მომენტი, როცა ticket უნდა გახსნა და არ გააგრძელო რედაქტირება. Laravel-ის production-ზე განთავსება იგივე pool-ის პარამეტრებს framework-ის მხრიდან ფარავს.

FAQ#

php.ini შევცვალე და არაფერი მოხდა. რატომ?

ოთხი ჩვეულებრივი მიზეზია: შენ ბრძანების ხაზის ფაილი შეცვალე და არა ვებისა, PHP-FPM შემდეგ არ გადატვირთე, conf.d ფაილი ან pool-ის php_admin_value შენს მნიშვნელობას გადაფარავს, ან .htaccess გამოიყენე სერვერზე, რომელიც PHP-FPM-ს უშვებს და ეს დირექტივები იგნორირდება. დაადასტურე phpinfo()-ით და წაიკითხე Loaded Configuration File ხაზი.

რა memory_limit უნდა ჰქონდეს WordPress-ს?

256 MB თითქმის ყველა რეალურ საიტს ფარავს, WooCommerce-ის ჩათვლით. 128 MB საკმარისია პატარა ბლოგისთვის, ცოტა plugin-ით. თუ გვერდის ჩასატვირთად 512 MB-ზე მეტი გჭირდება, რაღაც ძალიან ბევრ მონაცემს ტვირთავს და ლიმიტის გაზრდა მხოლოდ წარუმატებლობას აგვიანებს.

რატომ ვარდება ჩემი ატვირთვა ზუსტად 2 MB-ზე ან 8 MB-ზე?

ეს upload_max_filesize-ისა და post_max_size-ის ნაგულისხმევებია. გაზარდე ორივე, post_max_size უფრო დიდი დატოვე და დარწმუნდი, რომ memory_limit ახალ post_max_size-ს აღემატება. თუ მოთხოვნა PHP-ის შეტყობინების ნაცვლად 413-ით ვარდება, წინ მდგომი proxy მას პირველი უარყოფს.

უსაფრთხოა max_execution_time-ის 0-ზე დაყენება?

ბრძანების ხაზზე - დიახ, ეს უკვე ნაგულისხმევია. ვებ სერვერზე - არა: გაჭედილი მოთხოვნა worker-ს სამუდამოდ იკავებს და საკმარისი რაოდენობა pool-ს ამოწურავს. გაზარდე შემოსაზღვრულ მნიშვნელობამდე იმ საქმისთვის, რომელსაც სჭირდება, ხოლო ნამდვილად გრძელი სამუშაო დაგეგმილ დავალებაში გადაიტანე.

PHP-ის რომელი ვერსია გამოვიყენო?

ყველაზე ახალი, რომელსაც ყველა შენი დამოკიდებულება უჭერს მხარს, რაც პრაქტიკაში უმეტესი საიტისთვის 8.2 ან 8.3-ს ნიშნავს. თითოეული ვერსია წინაზე შესამჩნევად სწრაფია. production-ის განახლებამდე გამოსცადე staging ასლზე ხილული deprecation შეტყობინებებით, რადგან გაფუჭება plugin-ებსა და თემებშია და არა PHP-ში.

მჭირდება რამის დარეგულირება, თუ ჩემი ჰოსტი PHP-ს მართავს?

ჩვეულებრივ მხოლოდ memory_limit, ატვირთვის ზომები და max_input_vars, და ისინი ხშირად ფაილის ნაცვლად პარამეტრებად არის გამოტანილი. OPcache-სა და pool-ის ზომას ჰოსტი ჩვეულებრივ უკვე გონივრულად აყენებს და გაზომვის გარეშე მათი შეცვლა არის გზა, რომლითაც მომუშავე საიტი ნელი ხდება.