რამდენი RAM სჭირდება WordPress-ის საიტს სინამდვილეში

პატარა WordPress საიტი - ბლოგი, ვიზიტკა, პორტფოლიო, ოცი plugin, დღეში რამდენიმე ათასი ვიზიტი - 1 GB-ში კომფორტულად ცხოვრობს. დატვირთულ საიტს page builder-ით, წევრობის სისტემით ან რამდენიმე ასეული პროდუქტით 2-4 GB უნდა. WooCommerce მაღაზიას, რომელიც რეალურ თანხას ბრუნავს და cart-სა და checkout-ის ქეშირებადი არ არის, 4-8 GB უნდა და მას გამოიყენებს. ეს რიცხვები თავისთავად უსარგებლოა, რადგან WordPress მეხსიერებას ერთ მთლიან ნაწილად არ ხარჯავს. ის მას ხარჯავს როგორც PHP პროცესების რაოდენობა გამრავლებული თითოეულის ზომაზე, და ამ ნამრავლის ორივე ნახევარი შენ გიმართავს. როცა ეს არითმეტიკა გეხერხება, ნებისმიერი WordPress საიტის ზომას დაახლოებით ხუთ წუთში გამოთვლი და წინასწარ გაიგებ, დიდი გეგმა დაგეხმარება თუ plugin-ის პრობლემისთვის იხდი.

მოკლე პასუხი, საიტის ტიპის მიხედვით#

წაიკითხე ეს როგორც საწყისი წერტილები, იმავე სულისკვეთებით, რაც თამაშის სერვერის მოთხოვნებშია თამაშების მიხედვით: რიცხვი, საიდანაც იწყებ და რეალური მონაცემებით ასწორებ, და არა ზღვარი. პოსტის დანარჩენი ნაწილი სწორედ ამ გასწორებას ეხება.

სად მიდის მეხსიერება სინამდვილეში#

გეგმაზე, სადაც მთელი stack ერთ განაწილებაში მუშაობს, მეხსიერება ხუთ რამეს უნდა და მხოლოდ ერთი მათგანია WordPress:

• ვებ სერვერი. nginx პატარაა, რამდენიმე ათეული მეგაბაიტი. Apache mpm_prefork-ითა და mod_php-ით არა, რადგან თითოეულ Apache პროცესს PHP ინტერპრეტატორი აქვს.
• PHP-FPM worker-ები. დიდი ნაწილი. თითოეული worker სრული PHP პროცესია, რომელიც ყოველ მოთხოვნაზე ტვირთავს WordPress core-ს, შენს თემას და ყველა აქტიურ plugin-ს. აქ მიდის შენი მეხსიერების უმეტესობა და აქ არის მთელი სასარგებლო ტიუნინგი.
• OPcache. მეხსიერების ერთი საერთო ბლოკი, რომელიც კომპილირებულ PHP ბაიტკოდს ინახავს, ერთხელ ზომავ და ყველა worker იყენებს. ნაგულისხმევი 128 MB.
• ბაზის სერვერი. საკუთარი პროცესი ცხრილის გვერდებისა და ინდექსების საკუთარი ქეშით. პატარა საიტზე რამდენიმე ასეული მეგაბაიტი; დიდ მაღაზიაზე იმდენი, რამდენსაც მისცემ.
• ოპერაციული სისტემა და ყველაფერი, რასაც სხვას გაუშვებ. 150-350 MB მინიმალური Linux ინსტალაციისთვის, სანამ რამეს დაიწყებ.

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

PHP worker-ები არის რეალური ერთეული#

PHP-FPM pool ფიქსირებული რაოდენობის worker პროცესს უშვებს. თითოეული ერთ მოთხოვნას ამუშავებს თავიდან ბოლომდე. თუ ათი მოთხოვნა მაშინ მოვა, როცა ყველა worker დაკავებულია, ისინი რიგში დგებიან; თუ რიგი სავსეა, ვიზიტორები 502-ს ან 504-ს იღებენ. ესაა თითქმის ყოველთვის „საიტი დატვირთვისას დაეცა“ - არა მეხსიერების ამოწურვა, არა ბაზა, უბრალოდ worker-ებზე მეტი ერთდროული მოთხოვნა.

რამდენი worker გჭირდება, ამის არითმეტიკა მოკლეა:

workers needed = requests per second x average request time in seconds12 req/s x 0.30 s = 3.6  ->  round up, plus headroom  ->  6 workers12 req/s x 1.20 s = 14.4 ->  round up, plus headroom  ->  18 workers

მეორე ხაზი არის მთელი არგუმენტი წარმადობაზე მუშაობისთვის. იგივე ტრაფიკს სამჯერ მეტი მეხსიერება სჭირდება, როცა თითოეული მოთხოვნა ოთხჯერ უფრო დიდხანს გრძელდება, და მოთხოვნის დრო შენი თემისა და plugin-ების თვისებაა და არა შენი ჰოსტისა.

worker რამხელაა, ეს არითმეტიკა მეორე მხრიდან მოდის:

max_children = (RAM available for PHP) / (average worker RSS)2 GB plan:  2048 - 250 (OS + nginx) - 400 (database) - 128 (OPcache) = 1270 MB1270 MB / 110 MB per worker  =  11 workers

worker-ის ტიპური ზომები, გაზომილი როგორც resident მეხსიერება გახურებულ პროცესზე:

• სუფთა WordPress, მსუბუქი თემა, ათი plugin: 40-70 MB
• ტიპური ბიზნეს საიტი, page builder, ოცდაათი plugin: 90-150 MB
• WooCommerce, ან მძიმე მრავალფუნქციური თემა: 150-250 MB
• ერთი ცუდად მოქცეული plugin, რომელიც დიდ ფაილს აიმპორტებს: რასაც memory_limit დაუშვებს

შედეგი ჩაწერე pool config-ში და არ დატოვო ნაგულისხმევი, რომელიც პატარა გეგმისთვის ჩვეულებრივ ბევრად მაღალია:

pm = ondemandpm.max_children = 11pm.process_idle_timeout = 20spm.max_requests = 500request_terminate_timeout = 60srequest_slowlog_timeout = 5sslowlog = /var/log/php-fpm-slow.log

pm = ondemand worker-ებს მხოლოდ საჭიროებისას უშვებს და უქმობისას ტოვებინებს, რაც პატარა საიტს ტალღოვანი ტრაფიკით შეესაბამება და უქმი მეხსიერების ქვედა ზღვარს დაბლა ინარჩუნებს. pm = dynamic გახურებულ pool-ს ინახავს და სტაბილური ტრაფიკის მქონე საიტისთვის უკეთესია. pm.max_requests worker-ს გარკვეული რაოდენობის მოთხოვნის შემდეგ ანაცვლებს, რაც ცუდად დაწერილ plugin-ებში მეხსიერების ნელ ზრდას ფარავს.

php.ini: memory_limit, OPcache და პარამეტრები, რომლებსაც მნიშვნელობა აქვს#

memory_limit შენი გეგმის ზომა არ არის და არც რეზერვია. ეს ზღვარია იმისა, რასაც ერთ PHP პროცესს შეუძლია გამოყოს, სანამ PHP მოთხოვნას fatal error-ით შეწყვეტს. მისი 512M-ზე დაყენება 512 MB-ს არ ხარჯავს; ის ნიშნავს, რომ ერთ გაუკონტროლებელ მოთხოვნას 512 MB-ის გამოყენება ეძლევა, სანამ არ შეაჩერებენ.

ეს განსხვავება ურთიერთქმედების გამო არის მნიშვნელოვანი: memory_limit გამრავლებული pm.max_children-ზე არის შენი უარესი შემთხვევა. 512M გამრავლებული 20 worker-ზე არის 10 GB 4 GB გეგმაზე. პრაქტიკაში worker-ები ყველა ერთად პიკზე არასოდეს გადიან, მაგრამ plugin, რომელიც ლიმიტს ყოველ მოთხოვნაზე ციკლში ეჯახება, ამას შენს მაგივრად გაიგებს.

WordPress თავის საკუთარ ფენას ამატებს ზემოდან, რაც ხალხს ებნევა, ვინც memory_limit-ს ცვლის და ცვლილებას ვერ ხედავს. wp-includes/default-constants.php-ში WordPress ერთი საიტისთვის WP_MEMORY_LIMIT-ს 40M-ად განსაზღვრავს, multisite-ისთვის 64M-ად, ხოლო WP_MAX_MEMORY_LIMIT-ს 256M-ად admin ზონისა და cron-ისთვის. თუ php.ini-ში მნიშვნელობა უფრო მაღალია, WordPress უფრო მაღალს იყენებს; თუ admin-ში 256M-ზე მეტი გჭირდება, WordPress-ის მუდმივასაც ზრდი:

define( 'WP_MEMORY_LIMIT', '256M' );define( 'WP_MAX_MEMORY_LIMIT', '512M' );define( 'DISABLE_WP_CRON', true );

ნორმალური საიტისთვის გონივრული მნიშვნელობები: memory_limit = 256M php.ini-ში, WordPress-ის მუდმივები არ შეხო, სანამ რამე არ დაიჩივლებს. 128M უმეტესი საიტისთვის საკმარისია და PHP-ის ნაგულისხმევია; 512M იმპორტისთვის დიაგნოსტიკური პარამეტრია და არა მუდმივი. თუ გვერდის დასარენდერებლად ნამდვილად 256M-ზე მეტი გჭირდება, პრობლემა გვერდია. PHP-ის პარამეტრები, რომლებსაც მნიშვნელობა აქვს ფაილის დანარჩენ ნაწილს მოიცავს.

OPcache არის ყველაზე ღირებული მეხსიერება, რომელსაც დახარჯავ, რადგან ის ყოველი მოთხოვნიდან parse-სა და compile-ის ეტაპს აშორებს. მისი ორი ნაგულისხმევი WordPress-ისთვის არასწორია და თითქმის არავინ ცვლის:

opcache.enable = 1opcache.memory_consumption = 192opcache.interned_strings_buffer = 16opcache.max_accelerated_files = 30000opcache.revalidate_freq = 2

opcache.max_accelerated_files ნაგულისხმევად 10000-ია. WordPress ინსტალაციას ოცდაათი plugin-ით ხშირად ამაზე მეტი PHP ფაილი აქვს, და ლიმიტის მიღწევის შემდეგ დანარჩენი ყოველ მოთხოვნაზე თავიდან კომპილირდება, არსად გაფრთხილების გარეშე. opcache.memory_consumption ნაგულისხმევად 128 MB-ია, რომელსაც დიდი საიტი ავსებს; როცა ივსება, OPcache ყველაფერს ასუფთავებს და თავიდან იწყებს, რაც პასუხის დროში პერიოდულ ნახტომად ჩანს, რომელიც ჰოსტის პრობლემას ჰგავს და არ არის. ორივეს დაყენება პატარა გეგმაზეც ღირს, და ფასი მეხსიერების ფიქსირებული ბლოკია, რომელსაც ყველა worker იზიარებს და არა თითოეულზე.

ბაზის წილი#

WordPress-ის ბაზა ჩვეულებრივ ბევრად პატარაა, ვიდრე ხალხი ელოდება. ბლოგი ათასი პოსტით ათეულ მეგაბაიტს შეადგენს. ის სამ ადგილას იზრდება: post revision-ებში, wp_options-ის სტრიქონებში, რომლებიც ყოველ მოთხოვნაზე იტვირთება, და მაღაზიებისთვის - შეკვეთებსა და მათ metadata-ში.

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

SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS kb, COUNT(*) AS nFROM wp_optionsWHERE autoload IN ('yes', 'on', 'auto');

შეცვალე ცხრილის prefix შენი ინსტალაციის მიხედვით. WordPress 6.6-მა დამატებითი autoload მნიშვნელობები დაამატა, ამიტომ მოთხოვნა სამს ამოწმებს და არა ერთს. დაახლოებით 1 MB-ზე ნაკლები ჯანსაღია. რამდენიმე მეგაბაიტი ნიშნავს, რომ plugin, ჩვეულებრივ ისეთი, რომელიც თვეების წინ წაშალე, მონაცემებს ტოვებს, და საიტზე ყოველი მოთხოვნა ამის საფასურს დროითაც და მეხსიერებითაც იხდის.

თუ საკუთარ ბაზის სერვერს უშვებ, მისი ცხრილის გვერდების ქეში არის პარამეტრი, რომელსაც მნიშვნელობა აქვს, და დანარჩენი ხმაურია: InnoDB-ის buffer pool-ს მიეცი საკმარისი ადგილი შენი ცხრილების სამუშაო ნაკრებისთვის და უყურე, რომ სერვერი მთლიანად გეგმაში ჯერ კიდევ ეტევა. მართულ გეგმაზე ამას არ ტიუნავ, რაც შეზღუდვაცაა და შვებაც. RE:NODE-ის web გეგმები შეიცავს ბაზის slot-ებს, რომლებიც პანელიდან იქმნება გენერირებული host-ით, user-ითა და პაროლით, და „Open in phpMyAdmin“ ღილაკს, რომელიც შედის ერთჯერადი token-ით, სამოცი წამში ვადა გასდის - საკმარისია ზემოთ მოცემული მოთხოვნის გასაშვებად და dump-ის გასატანად და არა მუდმივი სამუშაო პროცესისთვის. phpMyAdmin-ით იმპორტი და ექსპორტი აღწერს ლიმიტებს, რომლებსაც დიდ ბაზაზე შეხვდები.

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

ქეშირება არითმეტიკას მთლიანად ცვლის#

ყველა ზემოთ მოცემული რიცხვი ვარაუდობს, რომ PHP მუშაობს. სრული გვერდის ქეში ნიშნავს, რომ არ მუშაობს, და ეს ერთი ცვლილება უფრო მეტს ღირს, ვიდრე ნებისმიერი გეგმის განახლება, რომლის ყიდვაც შეგიძლია.

ფენები, იმის მიხედვით, რამდენს ცვლის:

1. გვერდის ქეში. დარენდერებული HTML ინახება და PHP-სა და ბაზას შეუხებლად გაიცემა. ქეშირებული გვერდი ერთნიშნა მილიწამებს ღირს და worker-ს არ იკავებს. ეს განსხვავებაა იმას შორის, რომ ოთხი worker გჭირდება და ორმოცი.
2. OPcache. კომპილირებული ბაიტკოდი, ზემოთ განხილული. ყოველთვის ჩართული, ყოველთვის ღირს.
3. Object cache. მუდმივი საცავი შედეგებისთვის, რომლებსაც WordPress ახლა ყოველ მოთხოვნაზე თავიდან ითვლის. საჭიროებს Redis-ს ან Memcached-ს, რაც უმეტეს shared PHP ჰოსტინგზე ხელმისაწვდომი არ არის - და მის გარეშე WordPress მოთხოვნაზე ქეშზე გადადის, რომელიც გვერდის ყოველი ჩატვირთვის ბოლოს იყრება. Redis და როდის გჭირდება ის სინამდვილეში აღწერს, როდის ღირს მისი მოწყობა.
4. Browser და CDN ქეშირება. Header-ები, რომ განმეორებით მოსულ ვიზიტორებსა და edge node-ებს საერთოდ არ ეკითხათ. HTTP ქეშირების header-ები ახსნილი არის ცნობარი.

დაჭერა, და დიდია: გვერდის ქეში მხოლოდ ანონიმურ ვიზიტორებს ეხმარება. შესული მომხმარებლები, cart-ები, checkout-ები, ფორუმები, წევრთა პანელები და ყველაფერი პერსონალიზებული ქეშს განზრახ არ იყენებს, რადგან ალტერნატივაა ერთ ადამიანს მეორის კალათა აჩვენო. ამიტომ სჭირდება წევრობის საიტს ან მაღაზიას რეალური worker-ების სიმძლავრე ისე, როგორც იმავე ტრაფიკის ბლოგს არ სჭირდება, და ამიტომ ყოფს ამ პოსტის თავში ცხრილი მათ. WordPress-ის სისწრაფე და ქეშირება გადის, რომელი plugin რას აკეთებს.

შენი საკუთარი საიტის გაზომვა#

ხუთი წუთი გაზომვა ნებისმიერ ცხრილს სჯობს, ზემოთ მოცემულის ჩათვლით.

ჯერ worker-ის ზომა. მანქანაზე, სადაც shell გაქვს, ეს ბეჭდავს resident მეხსიერებას თითო PHP პროცესზე, უდიდესიდან დაწყებული:

$ ps -eo rss,comm --sort=-rss | grep php-fpm | head -15$ ps -eo rss,comm | grep php-fpm | awk '{s+=$1; n++} END {print s/n/1024 " MB avg"}'

resident მეხსიერება ცოტათი ზედმეტს ითვლის, რადგან worker-ები მშობელი პროცესისა და OPcache-ის გვერდებს იზიარებენ, ამიტომ საშუალო უსაფრთხო ზედა ზღვრად მიიჩნიე და არა ზუსტ მნიშვნელობად. შემდეგ ჩართე FPM status გვერდი და უყურე, რას აკეთებს pool სინამდვილეში:

pm.status_path = /status

listen queue ნულზე მეტი ნიშნავს, რომ მოთხოვნები worker-ს ელოდებიან. max children reached ნულზე მეტი ნიშნავს, რომ ბოლო restart-იდან სულ მცირე ერთხელ ამოგეწურა. ეს ორი მთვლელი პირდაპირ პასუხობს კითხვას „მჭირდება თუ არა დიდი გეგმა“, და სხვა არაფერი პასუხობს.

WordPress-ის შიგნიდან დანარჩენს WP-CLI გაძლევს:

$ wp db size --tables --human-readable$ wp plugin list --status=active --format=count$ wp option get cron --format=json | head -c 400$ wp transient delete --expired

დააყენე Query Monitor staging ასლზე და ჩატვირთე შენი ყველაზე ნელი გვერდი administrator-ად შესულმა. ის ბეჭდავს პიკურ მეხსიერებას ამ მოთხოვნაზე, ბაზის მოთხოვნების რაოდენობას, ყველაზე ნელ მოთხოვნებს და ნებისმიერ HTTP მოთხოვნას, რომელიც გვერდმა გარე სერვისებზე გააკეთა. სწორედ ბოლო პანელშია რეალური სიურპრიზები: plugin, რომელიც გვერდის ყოველ ჩატვირთვაზე ლიცენზიის სერვერს ეძახის, worker-ს იმდენ ხანს ინახავს, რამდენსაც ის სერვერი პასუხობს, და ორი წამით დაკავებული worker არის worker, რომელიც არავის ემსახურება.

პანელზე დაფუძნებულ ჰოსტზე პირველი ნახევრის ექვივალენტი კონსოლის გრაფიკებია, რომლებიც გეგმის ლიმიტების წინააღმდეგ მეხსიერებას, CPU-სა და დისკს ხატავენ. ვებ სერვერის მოთხოვნების ხმაური რიცხვის უკან არის დაკეცილი, რომლის გამორთვაც შეგიძლია, ასე ლოგი წაკითხვადი რჩება load ტესტის დროს.

როდის იყიდო მეტი და როდის შეასწორო საიტი#

იყიდე მეხსიერება, როცა გაზომვები ამბობს, რომ worker-ები სწორადაა ზომაზე და უბრალოდ საკმარისი არ არის: FPM status გვერდზე რიგი პიკზე იზრდება, worker-ის საშუალო ზომა გონივრულია, და ქეშირებული გვერდები სწრაფია. ეს რეალური სიმძლავრის ზღვარია და მეტი მეხსიერება მას ნამდვილად წყვეტს.

მეხსიერება არ იყიდო ამათ გამო, რადგან არ დაგეხმარება:

• ნელი გვერდები ტრაფიკის გარეშე. ერთი მოთხოვნა, რომელიც უქმ სერვერზე სამ წამს გრძელდება, კოდის პრობლემაა. მეტი მეხსიერება მას სამწამიან მოთხოვნად ტოვებს მეტი მეხსიერებით.
• worker-ის საშუალო 200 MB-ზე მაღლა ნორმალურ საიტზე. რაღაც ბევრად მეტს ტვირთავს, ვიდრე უნდა. გამორთე plugin-ები ნახევრებად staging ასლზე, სანამ საშუალო არ დაეცემა.
• Time-out-ები ზუსტად 30 ან 60 წამზე. ეს არის max_execution_time ან request_terminate_timeout და არა მეხსიერება.
• admin-ajax-ის ზედმეტი დარტყმა. heartbeat ან plugin, რომელიც ყოველ რამდენიმე წამში იკითხავს, worker-ებს ვიზიტორების გარეშე ხარჯავს. შეზღუდე.
• WordPress cron. ნაგულისხმევად wp-cron.php გვერდის ჩატვირთვებზე ირთვება, ამიტომ დატვირთული მომენტი დაგეგმილი ამოცანის მომენტიც ხდება. დააყენე DISABLE_WP_CRON და გაუშვი ის რეალური scheduler-იდან - RE:NODE-ზე ეს არის Schedules tab cron გამოსახულებითა და დალაგებული ამოცანებით.

კიდევ ერთი პატიოსანი შენიშვნა: WordPress-ს შენ აყენებ და არა ჩვენ. RE:NODE-ზე ერთი კლიკის ინსტალერი არ არსებობს და წინასწარ მომზადებული stack-ების კატალოგი არ არის. რასაც იღებ, არის კონტეინერი runtime-ით, SFTP-ით და file manager-ით, ბაზის slot-ები, proxy slot, რომელიც სერტიფიკატს გასცემს და ანახლებს, როგორც კი A ჩანაწერს ნაჩვენებ მისამართზე მიუთითებ, და backup slot-ები. WordPress-ის ხელით დაყენება არის თხუთმეტი წუთი, რომელიც ამას ფარავს, ხოლო WordPress-ის ახალ ჰოსტზე გადატანა არის ვერსია უკვე არსებული საიტისთვის.

თუ საიტი ამ proxy slot-ის უკან დგას, გახსოვდეს, რომ PHP proxy-ს მისამართს კლიენტის მისამართად ხედავს, სანამ სხვაგვარად არ უთხარი. რეალური ვიზიტორის IP X-Forwarded-For header-ში მოდის, და უსაფრთხოების plugin-ები, კომენტარების ლოგირება და rate limiting არასწორ მნიშვნელობას კითხულობენ, სანამ WordPress-ს არ დააკონფიგურირებ, რომ მას ენდოს. ეს გადატანის შემდეგ ყველაზე გავრცელებული სიურპრიზია.

FAQ#

საკმარისია 1 GB WordPress-ისთვის?

ბლოგისთვის ან ვიზიტკა საიტისთვის ჩართული გვერდის ქეშით - დიახ, კომფორტულად. ის ტოვებს ადგილს ოპერაციული სისტემისთვის, პატარა ბაზისთვის, OPcache-ისთვის და ოთხიდან ექვს PHP worker-მდე, რაც უფრო მეტი ერთდროულობაა, ვიდრე უმეტესი პატარა საიტი ოდესმე გამოიყენებს. WooCommerce-ისთვის, წევრობის საიტისთვის ან page builder-ისთვის ორმოცი plugin-ით საკმარისი არ არის.

რაზე დავაყენო memory_limit?

256M ნორმალური საიტისთვის. ეს არის მოთხოვნაზე ზღვარი და არა განაწილება, ამიტომ უფრო მაღალი მნიშვნელობა არაფერს ღირს, სანამ რამე მას ნამდვილად არ გამოიყენებს - მაგრამ უარეს შემთხვევაში ის worker-ების რაოდენობაზეც მრავლდება. თუ გვერდის დასარენდერებლად ნამდვილად 256M-ზე მეტი სჭირდება, გვერდი შეასწორე და არა რიცხვი გაზარდე.

რატომ ვარდება ჩემი საიტი პიკზე, მაგრამ მეხსიერების გრაფიკი ნორმალურად გამოიყურება?

იმიტომ, რომ PHP worker-ები ამოგეწურა და არა მეხსიერება. მოთხოვნები დაკავებული worker-ების უკან დგებიან და საბოლოოდ 502 ან 504 შეცდომებით წყდება, მაშინ როცა მთლიანი მეხსიერება ლიმიტს ბევრად ქვემოთაა. შეამოწმე max children reached FPM status გვერდზე და ან გაზარდე pm.max_children, თუ მეხსიერება დარჩა, ან მოთხოვნები უფრო სწრაფად დაასრულებინე.

მართლა ამდენით მეტი სჭირდება WooCommerce-ს?

დიახ, სტრუქტურული მიზეზით და არა კოდის ხარისხის გამო. Cart-ები, checkout-ები, ანგარიშის გვერდები და admin-ის შეკვეთების ეკრანები ქეშირებადი არ არის, ამიტომ თითოეული მათგანი PHP-ს უშვებს და ბაზას ეხება. მაღაზია იგივე ვიზიტორების რაოდენობით, რაც ბლოგს აქვს, რამდენჯერმე მეტ რეალურ სამუშაოს აკეთებს. WooCommerce ჰოსტინგის მოთხოვნები კონკრეტულს გადის.

გახდის მეტი RAM ჩემს საიტს უფრო სწრაფს?

მხოლოდ თუ ახლა ის გიწყდება. მეხსიერება ერთდროულობას გყიდულობს და არა სისწრაფეს. გვერდის ერთი ჩატვირთვა 1 GB-ზეც და 8 GB-ზეც ერთსა და იმავე დროს გრძელდება, თუ არაფერი იჭედება. გვერდს სწრაფს ხდის ქეშირება, ნაკლები plugin, ნაკლები ბაზის მოთხოვნა და უფრო სწრაფი CPU ბირთვი - იხილე TTFB, Core Web Vitals და ჰოსტინგი, რისი შეცვლა შეუძლია ჰოსტინგს და რისი არა.

რამდენ ვიზიტორს გაუძლებს 2 GB?

გვერდის ქეშით და ნორმალური თემით - დღეში ათიათასობით გვერდის ნახვას შეუმჩნევლად. ქეშის გარეშე და მძიმე builder თემით იგივე გეგმას რამდენიმე ასეულ ერთდროულ მკითხველზეც გაუჭირდება. პატიოსანი პასუხია, რომ გეგმის ზომა არ არის ცვლადი, რომელიც ამას წყვეტს - cache hit ratio და მოთხოვნის საშუალო დროა.