WooCommerce ჰოსტინგის მოთხოვნები: რეალური მაღაზიის ზომა

WooCommerce მაღაზია რამდენიმე ასეული პროდუქტით, დღეში ოცზე ნაკლები შეკვეთით და ტრაფიკის მოულოდნელი ზრდის გარეშე მშვიდად მუშაობს 2 GB მეხსიერებასა და ერთნახევარ CPU ბირთვზე. მაღაზია, რომელიც დღეში რამდენიმე ასეულ შეკვეთას ასრულებს, 8 GB-სა და სამ-ოთხ ბირთვს ითხოვს. ეს ორი რიცხვი შემოფარგლავს მაღაზიების უმეტესობას, რომელსაც ამ სტატიის მკითხველი აპირებს აგებას, და მათ შორის სხვაობა სინამდვილეში ტრაფიკზე არ არის - ის იმაზეა, საიტის რა ნაწილის მიწოდება შეიძლება ქეშიდან, და მაღაზია სწორედ ისეთი საიტია, სადაც პასუხია „ნაკლები, ვიდრე ფიქრობ“.

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

რა სჭირდება WooCommerce-ს, სანამ RAM-ს დათვლი#

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

HTTPS მაღაზიისთვის არჩევითი არ არის. გადახდის gateway-ები უარს ამბობენ თავიანთი სკრიპტების უბრალო HTTP-ით ჩატვირთვაზე, ბრაუზერები არასაიმედო გვერდზე ბარათის ველს ავტომატურად არ შეავსებენ, და checkout ჩუმად ჩავარდება ისე, რომ plugin-ის შეცდომას დაემსგავსოს. ჯერ სერტიფიკატი აამუშავე - HTTPS და Let's Encrypt ახსნილი აღწერს გაცემას, ხოლო www თუ apex დომენი და გადამისამართებები - იმას, რომ ორივე hostname დაფარულია, რადგან მაღაზია, რომელიც www-ზე შეცდომას იძლევა, კარგავს მომხმარებლებს, რომლებმაც ის აკრიფეს.

PHP გაფართოებები, რომლებიც რეალურად მნიშვნელოვანია: mysqli, curl, mbstring, dom, xml, json, zip, fileinfo, openssl, intl, bcmath და gd-ის ან imagick-ის ერთ-ერთი სურათების ზომის შესაცვლელად. რამდენიმე გადახდისა და მიწოდების plugin-ს soap უნდა. curl-ის არარსებობა ყველა gateway-ს არღვევს; gd-ის ან imagick-ის არარსებობა ნიშნავს, რომ პროდუქტის სურათები არასოდეს იცვლის ზომას და შენი მედიათეკა ათჯერ უფრო სწრაფად იზრდება, ვიდრე უნდა.

თავად PHP პარამეტრები ის ნაწილია, რასაც ხალხი ცდება, და ღირს მათი პირდაპირ დაყენება და არა მემკვიდრეობით მიღება:

memory_limit = 512Mmax_execution_time = 300max_input_vars = 5000upload_max_filesize = 64Mpost_max_size = 64Mopcache.enable = 1opcache.memory_consumption = 256opcache.interned_strings_buffer = 16opcache.max_accelerated_files = 20000opcache.revalidate_freq = 2

max_input_vars უცნაურია. WooCommerce-ის პარამეტრების ეკრანები და ცვალებადი პროდუქტები უზარმაზარ ფორმებს აგზავნის, და როცა ლიმიტს მიაღწევს, PHP შეყვანას ჩუმად ჭრის - ანუ 90 ვარიაციიანი პროდუქტი შეინახე და 40 მათგანი უშეცდომოდ ქრება. 5000 არის რიცხვი, რომელსაც თავად WooCommerce ითხოვს.

opcache.max_accelerated_files ნაგულისხმევად 10000-ია, და WooCommerce ინსტალაციას ოცი plugin-ით ამაზე მეტი PHP ფაილი აქვს. ქეშის გავსების შემდეგ ჭარბი ნაწილი ყოველ მოთხოვნაზე ხელახლა კომპილირდება და შენი time-to-first-byte ხილული მიზეზის გარეშე იზრდება. PHP პარამეტრები, რომლებიც მნიშვნელოვანია დანარჩენს განიხილავს.

WordPress-ს PHP-ის თავზე საკუთარი ლიმიტი აქვს და ის ნაგულისხმევად უფრო დაბალია:

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

ზომა: RAM, CPU და დისკი შეკვეთების მოცულობის მიხედვით#

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

სამი მოდიფიკატორი მაღაზიას ერთი მწკრივით ზემოთ სწევს შეკვეთების რაოდენობის მიუხედავად. კატალოგის ზომა: 20 000 პროდუქტი ვარიაციებით ბაზასა და ყოველ ადმინისტრატორის გვერდს რეალურ დატვირთვას აძლევს, დაბალი შეკვეთების მოცულობის დროსაც. Plugin-ების რაოდენობა: ყოველი აქტიური plugin კოდია, რომელიც ყოველ მოთხოვნაზე იტვირთება; ორმოცი plugin სხვა აპლიკაციაა, ვიდრე ათი. ტრაფიკის ფორმა: მაღაზიას, რომელიც თვის შეკვეთებს ფასდაკლების დროს ორ საათში იღებს, პიკს უნდა გაუძლოს და არა საშუალოს.

დისკი უმეტესად სურათებია. დათვალე დაახლოებით 2 - 5 MB თითო პროდუქტზე მას შემდეგ, რაც WordPress ქმნის თავის thumbnail ზომებს, პლუს ბაზა, პლუს backup-ები, თუ მათ ლოკალურად ინახავ - რაც არ უნდა გააკეთო.

RE:NODE-ზე web ჰოსტინგის ქვეშ CMS ხაზი 1 GB-დან 8 GB-მდეა, ოთხ vCPU-მდე, და ეს ზემოთ მოცემული ცხრილის პირველ სამ მწკრივს ფარავს. CPU არის მკაცრი შეზღუდვა შენ მიერ ნაყიდ წილზე და არა burst შემწეობა, ამიტომ მაღაზია, რომელიც ფასდაკლებისას 100%-ზე დგას, ნელია და არასოდეს - შეჩერებული. ზედა მწკრივის ზემოთ მაღაზიას საკუთარი მანქანა სჭირდება - იხილე VDS-სა და პანელს შორის არჩევა, რა იცვლება, როცა ოპერაციულ სისტემას თვითონ იღებ.

PHP worker-ები არის რეალური კონკურენტულობის ლიმიტი#

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

pm = dynamicpm.max_children = 12pm.start_servers = 4pm.min_spare_servers = 2pm.max_spare_servers = 6pm.max_requests = 500

WooCommerce მოთხოვნა ჩვეულებრივ 64 - 128 MB PHP მეხსიერებას იკავებს, ამიტომ არითმეტიკა ასეთია: PHP-სთვის ხელმისაწვდომი მეხსიერება, გაყოფილი პროცესის საშუალო ზომაზე, არის შენი ჭერი pm.max_children-ისთვის. 4 GB გეგმაზე, სადაც PHP-სთვის დაახლოებით 3 GB თავისუფალია და პროცესი 96 MB-ია, ეს დაახლოებით 30-ია - და შენ დააყენებ უფრო დაბალზე, რადგან ბაზასაც და web სერვერსაც მეხსიერება სჭირდება.

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

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

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

რატომ ვერ იქნება მაღაზია სრულად გვერდებად ქეშირებული#

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

• /cart/, /checkout/ და /my-account/, პლუს ნებისმიერი გვერდი, რომელიც ამ block-ებს ან shortcode-ებს სხვა URL-ის ქვეშ შეიცავს.
• ნებისმიერი მოთხოვნა, რომელიც woocommerce_items_in_cart ან woocommerce_cart_hash cookie-ს ატარებს, ან cookie-ს, რომლის სახელიც wp_woocommerce_session_-ით იწყება. ვიზიტორს, რომელსაც კალათაში რაღაც აქვს, არასოდეს უნდა მიეწოდოს სხვა ვიზიტორის ქეშირებული გვერდი.
• ნებისმიერი მოთხოვნა, რომლის query string-შიც add-to-cart, wc-ajax ან removed_item არის.

ყოველი სერიოზული ქეშირების plugin ამ წესებს იცნობს და ნაგულისხმევად იყენებს. საფრთხე ხელნაკეთი წესია proxy დონეზე, ან CDN, რომელიც „ყველაფრის ქეშირებაზე“ არის მორგებული, და ასე ხვდება მაღაზია იქამდე, რომ ერთ მომხმარებელს მეორის კალათას აჩვენებს. თუ ამ თავიდან ერთ რამეს წაიღებ, cookie-ების სია წაიღე.

კალათის fragment-ები დაკავშირებული წარმადობის ხაფანგია. ნაგულისხმევად WooCommerce ყოველ გვერდის ჩატვირთვაზე არაქეშირებულ AJAX მოთხოვნას აგზავნის ?wc-ajax=get_refreshed_fragments-ზე, რომ კალათის ვიჯეტმა სწორი რაოდენობა აჩვენოს - რაც ნიშნავს, რომ ყოველი გვერდის ნახვა, ქეშირებული თუ არა, მაინც ერთხელ უშვებს PHP-ს. მაღაზიაზე, რომლის თემაც header-ში კალათის რაოდენობას აჩვენებს, ეს დატვირთვის ყველაზე დიდი წყაროა. ჩვეულებრივი პასუხებია fragment-ების ჩატვირთვა მხოლოდ იმ გვერდებზე, სადაც კალათა მართლა ჩანს, ან ცოცხალი რაოდენობის ჩანაცვლება JavaScript-ით cookie-დან გამოთვლილით. WordPress-ის სიჩქარე და ქეშირება დანარჩენ stack-ს განიხილავს.

ბაზა და ცხრილები, რომლებიც იზრდება#

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

Autoload პარამეტრები. ყოველი მოთხოვნა wp_options-ის ყველა მწკრივს, რომელიც autoload-ად არის მონიშნული, PHP მეხსიერებაში ტვირთავს, სანამ სხვა რამე მოხდება. Plugin-ები იქ პარამეტრებს, ლიცენზიის ბლობებსა და ქეშირებულ API პასუხებს ყრიან და არასოდეს ასუფთავებენ. მაღაზია 3 MB autoload-ებული პარამეტრებით ამ ფასს ყოველ მოთხოვნაზე იხდის, AJAX-ების ჩათვლით.

SELECT option_name, LENGTH(option_value) AS bytesFROM wp_optionsWHERE autoload IN ('yes', 'on', 'auto', 'auto-on')ORDER BY bytes DESCLIMIT 20;

ამ სიაში დაახლოებით 100 KB-ზე მეტს ახსნა სჭირდება. ვადაგასული transient-ები - მწკრივები, რომელთა სახელიც _transient_-ით იწყება - წასაშლელად უსაფრთხოა, და WP-CLI ამას ერთი ბრძანებით აკეთებს: wp transient delete --expired.

შეკვეთების შენახვა. WooCommerce ადრე შეკვეთებს wp_posts-ში პოსტებად ინახავდა, მათი ველები კი wp_postmeta-ში იყო, რაც ნიშნავდა, რომ შეკვეთის მარტივი ძებნა self-join-ების გროვა იყო. High-Performance Order Storage ამას გამოყოფილი ცხრილებით ჩაანაცვლა - wp_wc_orders, wp_wc_orders_meta, wp_wc_order_addresses და wp_wc_order_operational_data. ახალი ინსტალაციებისთვის ის ნაგულისხმევია WooCommerce 8.2-დან; ძველი მაღაზიები ჩართავენ WooCommerce, Settings, Advanced, Features-ში, რაც ჯერ სინქრონიზაციას უშვებს. თუ შენი მაღაზია ამაზე ძველია და ადმინისტრატორის შეკვეთების ეკრანები ნელა იტვირთება, ეს არის გამოსწორება, და ის უფრო დიდი მოგებაა, ვიდრე დამატებითი RAM-ის ნებისმიერი რაოდენობა.

Action Scheduler. WooCommerce ფონურ სამუშაოს - ელფოსტებს, მარაგის სინქრონიზაციას, გამოწერის განახლებებს, ანალიტიკის იმპორტებს - wp_actionscheduler_actions-ში აყენებს რიგში. დასრულებული action-ები დაახლოებით ერთი თვე ინახება და შემდეგ გასუფთავების job-ით იშლება. ეს გასუფთავება თავად დაგეგმილი action-ია, ამიტომ მაღაზიაში, სადაც cron სწორად არ მუშაობს, ცხრილი შეუზღუდავად იზრდება, და მაღაზიები, რომლებშიც მილიონობით მწკრივია, გავრცელებული სანახავია. სანამ ვარაუდობ, რომ ბაზა კარგადაა, შეამოწმე რაოდენობა WooCommerce, Status, Scheduled Actions-ში.

Lookup ცხრილები. wp_wc_product_meta_lookup, wp_wc_customer_lookup და ანალიტიკის ცხრილები იმისთვის არსებობს, რომ ფილტრაციამ და ანგარიშგებამ wp_postmeta არ წაიკითხოს. თუ გადახრიან, ისინი Status, Tools ეკრანიდან თავიდან შენდება, რაც ღირს იცოდე, როცა ანგარიშები შეკვეთების სიას არ ემთხვევა.

ერთი პრაქტიკული შენიშვნა ძრავზე: WordPress და WooCommerce MySQL-თან თავსებადი ბაზებისთვისაა დაწერილი და სხვას ვერ გამოიყენებს. RE:NODE-ზე web გეგმები ორ ბაზის სლოტს შეიცავს, რომლებიც პანელში იქმნება, გენერირებული host-ით, მომხმარებლით და პაროლით და Open in phpMyAdmin ღილაკით, რომელიც შენ 60 წამის ვადიანი token-ით შეგიყვანს. ცალკე გასაყიდი ბაზის ჰოსტინგის ხაზი PostgreSQL და MongoDB-ია, რაც უამრავი საქმისთვის სწორი ინსტრუმენტია და არა ის, რასაც WordPress მაღაზია უერთდება.

Cron: wp-cron არ არის cron#

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

ჩაანაცვლე ის ნამდვილი cron ჩანაწერით:

define( 'DISABLE_WP_CRON', true );

# Every five minutes, from the system crontab*/5 * * * * curl -sS https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1# Better, if WP-CLI is available: no HTTP round trip, real exit codes*/5 * * * * cd /var/www/html && wp cron event run --due-now --quiet

ხუთი წუთი სწორი ინტერვალია მაღაზიების უმეტესობისთვის. ერთი წუთი გამართლებულია, თუ გამოწერებს ან ცოცხალ მარაგის სინქრონიზაციას უშვებ; უფრო მოკლე მხოლოდ დატვირთვაა. თუ სინტაქსი ახალია შენთვის, cron გამოსახულებები ახსნილი ხუთ ველს შლის, ხოლო დაგეგმილი ამოცანები, რომლებიც ღირს ჩამოთვლის მათ, რომლებიც თავის ადგილს იმსახურებს.

სესიები, object caching და კალათის fragment-ები#

ყოველი მყიდველი კალათით wp_woocommerce_sessions-ში მწკრივს იღებს, cookie-თი გასაღებით, რომელსაც ყოველდღიური დაგეგმილი action ასუფთავებს. მაღაზიაში, სადაც cron გატეხილია, ეს ცხრილიც შეუზღუდავად იზრდება, და რადგან ის თითქმის ყოველ არაქეშირებულ მოთხოვნაზე იკითხება და იწერება, გაბერილი sessions ცხრილი ყველგან იგრძნობა.

მუდმივი object cache ერთადერთი ყველაზე დიდი გაუმჯობესებაა, რომელიც დატვირთულ მაღაზიას შეუძლია. მის გარეშე WordPress ყოველ მოთხოვნაზე თავის შიდა ქეშებს თავიდან აგებს და transient-ები ბაზიდან იკითხება და მასში იწერება. მასთან ერთად პარამეტრები, transient-ები და query-ის შედეგები მეხსიერებაში ცხოვრობს მოთხოვნებს შორის, და ბაზის დატვირთვა მკვეთრად ეცემა - ხშირად განახევრდება დიდი კატალოგის მქონე მაღაზიაზე. მას Redis ან Memcached სერვისი და შესაბამისი object-cache.php drop-in სჭირდება.

გაერკვიე, რას მოითხოვს ეს: ეს ცალკე სერვისია და არა პარამეტრი. RE:NODE მართულ Redis-ს ან Memcached-ს არ ყიდის, ამიტომ საზიარო web გეგმაზე drop-in-ისთვის მისათითებელი არაფერია. VDS-ზე საიტის გვერდით შენ დააყენებ და გაუშვებ რომელსაც ამჯობინებ. Redis, როცა გჭირდება არის პატიოსანი ვერსია იმისა, როდის ღირს დამატებითი მოძრავი ნაწილი - და მაღაზიისთვის, რომელსაც დღეში ოცზე ნაკლები შეკვეთა აქვს, ჩვეულებრივ არ ღირს.

მედია, backup-ები და მონაცემები, რომელთა ხელახლა შექმნა შეუძლებელია#

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

• გააკეთე backup ყოველ განახლებამდე. Plugin-ის განახლებები მაღაზიაზე production-ის ცვლილებაა. ჯერ აიღე backup, რომლის აღდგენაც ხუთ წუთში შეგიძლია, ყოველ ჯერზე.
• შეინახე backup-ები მანქანის გარეთ. იმავე დისკზე backup შენს შეცდომებისგან იცავს და არა დისკისგან. RE:NODE-ზე backup სლოტები ყველა გეგმაში შედის, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, აღდგება ღილაკით და იკეტება, რომ როტაციამ მნიშვნელოვანი არ წაშალოს. სერვერის წაშლა მის backup-ებს წაშლის, ჩაკეტილებისაც.
• დროდადრო აღადგინე ერთი. ბაზის backup-ები და აღდგენები და აღდგენის გატესტვა, სანამ გჭირდება ორივე იმიტომ არსებობს, რომ backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა.
• ბარათის მონაცემები ნუ შეინახავ. გამოიყენე gateway, რომელიც ბარათის დეტალებს შენი სერვერისგან მთლიანად შორს ინახავს - hosted ველი ან გადამისამართება. ეს შენი ჰოსტინგიდან PCI ტვირთის თითქმის მთელ ნაწილს იღებს და სწორი არჩევანია ყოველი მაღაზიისთვის მნიშვნელოვან მასშტაბამდე.

გაზომვა გამოცნობის ნაცვლად#

გეგმის გაზრდამდე გაარკვიე, რომელი რესურსია რეალურად ლიმიტზე. პანელის გრაფიკები მეხსიერებას, CPU-სა და დისკს ლიმიტებთან ერთად აჩვენებს; სერვერის დატვირთვის გრაფიკის კითხვა განმარტავს, რას ნიშნავს ფორმები. WordPress-ის შიგნით სამი ინსტრუმენტი თითქმის ყველაფერს პასუხობს:

• Query Monitor გვიჩვენებს გვერდზე ყველა query-ს, თითოეულმა რამდენი დრო წაიღო და რომელმა plugin-მა გაუშვა. დააყენე staging-ზე, გაიმეორე ნელი გვერდი და ხშირად პასუხი ერთი შეხედვით გაქვს.
• WooCommerce, Status აჩვენებს PHP-ისა და ბაზის ვერსიებს, მეხსიერების ლიმიტს, გაფართოებებს და იმას, ჯანმრთელია თუ არა cron და დაგეგმილი action-ები.
• ნელი query-ების ლოგი, თუ ბაზის სერვერის კონფიგურაციას წვდები, გეუბნება, რომელი query ხარჯავს რეალურად და არა რომელზე ეჭვობ.

სწორ გეგმაზე მაღაზიამ ქეშირებული კატეგორიის გვერდი სერვერის დროის 200 ms-ზე გაცილებით ნაკლებში უნდა მოგვცეს და არაქეშირებული პროდუქტის გვერდი - 500 ms-ზე ნაკლებში. თუ ქეშირებული გვერდები ნელია, პრობლემა სერვერია. თუ მხოლოდ არაქეშირებულია ნელი, პრობლემა PHP-ა, plugin-ები ან ბაზა - და მეტი RAM მას ვერ შეეხება.

FAQ#

რამდენი RAM სჭირდება WooCommerce მაღაზიას?

2 GB პატარა მაღაზიისთვის დაახლოებით დღეში ოცზე ნაკლები შეკვეთით, 4 GB, როცა ტრაფიკი სტაბილურია, და 8 GB დღეში რამდენიმე ასეული შეკვეთისთვის ან ათეულობით ათასი პროდუქტის კატალოგისთვის. მეხსიერებას PHP worker-ები მოიხმარენ, ამიტომ პატიოსანი კითხვაა, რამდენი ერთდროული არაქეშირებადი მოთხოვნის მომსახურება გჭირდება. რამდენი RAM სჭირდება WordPress-ს ზოგად ვერსიას შეიცავს.

შემიძლია ჩვეულებრივი WordPress გეგმის გამოყენება WooCommerce-ისთვის?

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

სჭირდება WooCommerce-ს ცალკე ბაზის სერვერი?

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

რატომ არის ჩემი მაღაზია ნელი მხოლოდ ადმინისტრატორის პანელში?

თითქმის ყოველთვის შეკვეთების ან პროდუქტების სია, და თითქმის ყოველთვის ძველი ინსტალაცია, რომელიც შეკვეთებს ისევ პოსტებად ინახავს. ჩართე High-Performance Order Storage, შეამოწმე Action Scheduler ცხრილის ზომა და შეხედე autoload-ებულ პარამეტრებს. სამივე ბაზის პრობლემაა, რომელსაც front-end ქეშირების არცერთი რაოდენობა არ ეხება.

მჭირდება Redis WooCommerce-ისთვის?

მხოლოდ მაშინ, როცა ბაზა შეფერხების წერტილია, რაც მაღაზიების უმეტესობისთვის რჩევაზე გვიან ხდება. მუდმივი object cache დიდი მოგებაა დატვირთულ მაღაზიაზე დიდი კატალოგით და პატარაზე ძალიან ცოტას აკეთებს. მას ასევე სჭირდება Redis ან Memcached სერვისის არსებობა, რასაც საზიარო web გეგმა აქ არ იძლევა.

გამოასწორებს ჰოსტინგი ჩემს Core Web Vitals-ს?

ნაწილობრივ. ჰოსტინგს time-to-first-byte ეკუთვნის, და ნელი TTFB ყველაფერს მის შემდეგ ზღუდავს. Largest Contentful Paint და layout shift უმეტესად თემის, სურათების ზომებისა და მესამე მხარის სკრიპტების საქმეა, და დიდ გეგმაზე გადასვლა მათგან არცერთს არ ცვლის.