WordPress-ის object cache Valkey-ით: დაყენება და ზღვრები

Persistent object cache WordPress-ის ბაზაში ძიებების შედეგებს Valkey-ში ინახავს მოთხოვნებს შორის, ასე რომ შემდეგი მოთხოვნა მათ მეხსიერებიდან კითხულობს და ბაზას თავიდან აღარ ეკითხება. საიტზე, სადაც შესული მომხმარებლები არიან, დატვირთული ადმინისტრაციული ნაწილია ან WooCommerce მაღაზიაა, ის გვერდზე ბაზის მოთხოვნების რაოდენობას მკვეთრად ამცირებს და ადმინისტრაციულ პანელს შესამჩნევად აჩქარებს. ვიზიტკა საიტზე, რომლის გვერდებიც უკვე page cache-იდან მიეწოდება, ის თითქმის არაფერს ცვლის - გვერდი PHP-მდე არ აღწევს, ამიტომ დასაზოგი მოთხოვნები არ არის.

ეს განსხვავება მთელი პოსტია ერთ წინადადებაში. თავად დაყენება ათი წუთია: plugin, ოთხი ხაზი wp-config.php-ში და ერთი ღილაკი. ფიქრს ითხოვს იმის გარკვევა, ეკუთვნის თუ არა შენი საიტი იმ ტიპს, რომელიც სარგებელს იღებს, cache-ის ზომის შერჩევა და იმ რამდენიმე ჩავარდნის ცნობა - მოძველებული options, დაკარგული drop-in, შემთხვევით საიტებს შორის გაზიარებული cache. ეს პოსტი ყველაფერს ფარავს.

რა არის object cache#

WordPress-ს ყოველთვის ჰქონდა object cache: WP_Object_Cache კლასი wp_cache_get()-ისა და wp_cache_set()-ის უკან. Core მას იყენებს options-ისთვის, პოსტებისთვის, post meta-სთვის, term-ებისთვის, მომხმარებლებისთვის და მოთხოვნების შედეგებისთვის, plugin-ები კი საკუთარი მონაცემებისთვის. ნაგულისხმევად ის PHP-ის მეხსიერებაში ცხოვრობს და ყოველი მოთხოვნის ბოლოს კვდება. ის ზოგავს განმეორებით ძიებებს ერთი გვერდის ჩატვირთვის შიგნით და არაფერს - ჩატვირთვებს შორის.

Persistent object cache ამ კლასს ცვლის ისეთით, რომელიც იმავე მონაცემებს გარე სერვერზე ინახავს. WordPress შემცვლელს drop-in ფაილიდან, wp-content/object-cache.php-დან ტვირთავს, თითქმის ყველაფერზე ადრე. მისი არსებობისას იმავე პოსტზე მეორე მოთხოვნა ბაზას აღარ ეკითხება პოსტზე, მის meta-ზე, მის term-ებზე ან ავტორზე; ის მათ Valkey-დან იღებს.

WordPress 6.1-დან Site Health ეკრანი persistent object cache-ს იმ საიტებზე გირჩევს, რომლებსაც საკმარისად დიდად თვლის, რომ სარგებელი ნახონ, ამიტომაც ბევრი საიტის მფლობელი მის შესახებ პირველად იქ იგებს.

რას აჩქარებს და რას არა#

Object cache მხოლოდ იმ მოთხოვნებს ეხმარება, რომლებიც PHP-ს უშვებენ და ბაზას ეკითხებიან. ამიტომ კითხვაა, რომელი მოთხოვნები აკეთებენ ამას შენს საიტზე.

ბოლო ორი ხაზი არასასიამოვნოა. თუ გვერდი ნელია, რადგან plugin უშვებს meta_query-ს, რომელიც ასი ათას ხაზს სკანირებს, object cache შედეგს მეორედ სწრაფად მოგცემს, პირველად კი ისევე ნელა - მათ შორის ყოველ ჯერზე, როცა cache იწმინდება. და თუ გვერდი ნელია, რადგან page builder 800 ms-ს ხარჯავს HTML-ის აწყობაზე PHP-ში, ამას მონაცემების ვერანაირი cache ვერ შეცვლის. გაზომე, სანამ რამეს დაამატებ. Query Monitor აჩვენებს მოთხოვნების რაოდენობასა და დროს გვერდზე, და ხვდება თუ არა object cache.

ნელი WordPress საიტისთვის მოქმედებების თანმიმდევრობა:

1. Page cache ანონიმური ტრაფიკისთვის, რაც საიტების უმეტესობისთვის ყველაზე დიდი მოგებაა.
2. გაასწორე ყველაზე ნელი მოთხოვნები და ყველაზე მძიმე plugin-ები.
3. Persistent object cache ყველაფრისთვის, რასაც page cache ვერ მოემსახურება.
4. მერე იფიქრე მეტ PHP worker-ზე ან მეტ მეხსიერებაზე.

WordPress-ის სიჩქარე და cache page cache-ის მხარეს გადის და იმას, როგორ ერგება შრეები ერთმანეთს.

Plugin-ები#

Valkey-სთან მოსაუბრე drop-in-ის მიღების რამდენიმე გზა არსებობს. ყველა Redis პროტოკოლზე ლაპარაკობს, ამიტომ Valkey-ს უცვლელად უკავშირდება.

• Redis Object Cache (უფასო, Till Krüss-ის) ყველაზე ფართოდ გამოყენებულია. ის object-cache.php-ს აყენებს, ადმინისტრაციულ პანელში სტატუსსა და hit-rate მეტრიკებს აჩვენებს და WP_REDIS_* მუდმივებით ირგება. მას შეუძლია phpredis გაფართოების, Relay-ის ან Predis-ის გამოყენება, რომელიც მასთან ერთად მოყოლილი სუფთა PHP კლიენტია - ამიტომ ის მუშაობს იქაც, სადაც PHP გაფართოებების დაყენება არ შეგიძლია.
• Object Cache Pro იმავე ავტორის კომერციული ვერსიაა, უკეთესი სერიალიზაციითა და შეკუმშვით, ჯგუფების უფრო ეფექტური გასუფთავებითა და მხარდაჭერით. ის დიდ მაღაზიებსა და სააგენტოებზეა გათვლილი.
• W3 Total Cache და LiteSpeed Cache page cache-თან ერთად object cache-ის პარამეტრებსაც შეიცავს. გონივრულია, თუ ერთ-ერთს უკვე იყენებ; მოერიდე ორი object cache drop-in-ის ერთდროულად გაშვებას - object-cache.php მხოლოდ ერთია.

ეს პოსტი Redis Object Cache-ს იყენებს, რადგან ის უფასოა, გავრცელებული და კარგად დოკუმენტირებული.

დაყენება, ნაბიჯ-ნაბიჯ#

1. შეამოწმე, აღწევს თუ არა WordPress Valkey-მდე. ნებისმიერი მანქანიდან, სადაც კლიენტია, valkey-cli -h <host> -p <port> --askpass და შემდეგ PING უნდა პასუხობდეს PONG-ით. თუ შენი WordPress ერთ სერვერზე მუშაობს და Valkey მეორეზე, ეს ქსელური გამოძახებაა cache-ის ყოველ წაკითხვაზე, ამიტომ ისინი ერთ ლოკაციაზე უნდა იყვნენ. RE:NODE-ზე ვებ ჰოსტინგიც და Valkey-იც გერმანიაში მუშაობს, ხოლო Valkey გეგმას თავისი host, პორტი და გენერირებული პაროლი მოყვება.
2. შეამოწმე phpredis გაფართოება. ფაილი <?php phpinfo(); შიგთავსით ვებ root-ში, ერთხელ ჩატვირთული და შემდეგ წაშლილი, აჩვენებს redis განყოფილებას, თუ გაფართოება არსებობს. თუ არა, plugin Predis-ზე გადადის, რომელიც უფრო ნელია, მაგრამ მუშაობს.
3. დაამატე მუდმივები `wp-config.php`-ში, იმ ხაზის ზემოთ, რომელიც ამბობს That's all, stop editing!:

define( 'WP_REDIS_HOST', '203.0.113.20' );define( 'WP_REDIS_PORT', 6380 );define( 'WP_REDIS_PASSWORD', 'the-generated-password' );define( 'WP_REDIS_DATABASE', 0 );define( 'WP_REDIS_PREFIX', 'shop_example_com:' );define( 'WP_REDIS_TIMEOUT', 1 );define( 'WP_REDIS_READ_TIMEOUT', 1 );define( 'WP_REDIS_MAXTTL', 86400 );

1. დააყენე და გაააქტიურე Redis Object Cache Plugins-იდან, შემდეგ Add New.
2. ჩართე ის Settings-ში, შემდეგ Redis, ღილაკით Enable Object Cache. ეს drop-in-ს wp-content/object-cache.php-ში აკოპირებს. WP-CLI-ით wp redis enable იგივეს აკეთებს, wp redis status კი კავშირის მდგომარეობას აჩვენებს.
3. ჩატვირთე რამდენიმე გვერდი და შეამოწმე სტატუსის ეკრანი: ის უნდა ამბობდეს Connected-ს, hit-ები კი უნდა იზრდებოდეს. Query Monitor-მა იმავე ადმინისტრაციული გვერდის მეორე ჩატვირთვაზე ბაზის გაცილებით ნაკლები მოთხოვნა უნდა აჩვენოს.

მუდმივები, რომელთა გაგებაც ღირს:

• `WP_REDIS_PREFIX` პრაქტიკაში სავალდებულოა. ორი WordPress საიტი, რომლებიც ერთ Valkey-ზე მიუთითებენ განსხვავებული პრეფიქსების გარეშე, options-ის cache-ს იზიარებენ და ერთმანეთის პარამეტრებს აჩვენებენ - ერთ-ერთი ყველაზე დამაბნეველი ბაგი, რისი შექმნაც შეგიძლია. გამოიყენე დომენი.
• `WP_REDIS_MAXTTL` ყოველი key-ის სიცოცხლის ხანგრძლივობას ზღუდავს. ზოგი plugin cache ჩანაწერებს ვადის გარეშე ინახავს; ზღვრის გარეშე ისინი ცოცხლობენ, სანამ არ განიდევნებიან. ერთი დღე გონივრული ჭერია.
• `WP_REDIS_TIMEOUT` და `WP_REDIS_READ_TIMEOUT` წამებშია. მოკლე დაიჭირე: თუ Valkey მიუწვდომელია, ყოველი გვერდი timeout-ს ელოდება, სანამ სათადარიგო გზაზე გადავა.
• `WP_REDIS_PASSWORD` იღებს მასივს, [ 'username', 'password' ], როცა ნაგულისხმევი მომხმარებლის ნაცვლად ACL მომხმარებელს იყენებ.
• `WP_REDIS_DISABLED`, true-ზე დაყენებული, cache-ს გვერდს უვლის drop-in-ის წაშლის გარეშე - საგანგებო ჩამრთველი.

პაროლი ვერსიების კონტროლის გარეთ დაიჭირე, თუ wp-config.php repository-შია. WordPress-ის ხელით დაყენება wp-config.php-ის დანარჩენ ნაწილს ფარავს.

Valkey-ის ზომა WordPress-ისთვის#

Object cache-ის ზომა დაახლოებით იმ ობიექტების ნაკრებია, რომლებსაც შენი საიტი რეგულარულად ეხება: options (autoload-ირებულების ჩათვლით), პოსტები, meta, term-ები, მომხმარებლები, transient-ები და რასაც plugin-ები ამატებენ. საიტების უმეტესობისთვის ეს მოულოდნელად პატარაა.

გაზომე და ნუ გამოიცნობ: ნორმალური ტრაფიკის ერთი დღის შემდეგ INFO memory აჩვენებს used_memory_human-ს, და plugin-ის სტატუსის ეკრანი იმავე ციფრს აჩვენებს.

Valkey-ისთვის, რომელიც მხოლოდ object cache-ად გამოიყენება, სწორი eviction პოლიტიკაა allkeys-lru ან allkeys-lfu: როცა მეხსიერება ივსება, ყველაზე ნაკლებად სასარგებლო ჩანაწერები იყრება და WordPress მათ ბაზიდან თავიდან აგებს. noeviction-ით სავსე cache ჩაწერებს აჩავარდნებს და plugin შეცდომებს აცხადებს. თუ იგივე Valkey სხვა აპლიკაციის სესიებს ან რიგებსაც ინახავს, ეს კონფლიქტი მიზეზია, რომ WordPress-ს საკუთარი ინსტანცია მისცე; Valkey-ის მეხსიერება და eviction პოლიტიკები ამ კომპრომისს ხსნის.

Persistence object cache-ისთვის ნაკლებად მნიშვნელოვანია, ვიდრე Valkey-ში სხვა რამისთვის, რადგან მასში ყველაფრის თავიდან აგება შეიძლება. ის მაინც ეხმარება: რესტარტის შემდეგ შენახული cache მაშინვე თბილია, ნაცვლად იმისა, რომ ყველა გვერდმა ერთდროულად გადაიხადოს ცივი სტარტის ფასი.

Transient-ები, autoload-ირებული options და მოძველებული მონაცემები#

WordPress-ის ორი მექანიზმი ქცევას ცვლის, როცა persistent object cache დაყენებულია, და ორივე ხსნის ბაგებს, რომლებზეც ხალხი წერს.

Transient-ები ბაზიდან გადადიან. Object cache-ის გარეშე set_transient() წერს wp_options ცხრილში. მასთან ერთად transient-ები მხოლოდ Valkey-ში ცხოვრობენ და ბაზას არასოდეს ეხებიან. ეს ჩვეულებრივ გაუმჯობესებაა - ვადაგასული transient-ები wp_options-ში აღარ გროვდება - მაგრამ ნიშნავს, რომ plugin, რომელიც რაღაც აუცილებელს transient-ში ინახავს, მას კარგავს, როცა cache იწმინდება ან key განიდევნება. Transient-ები ერთჯერადად არის გათვლილი; plugin-ს, რომელიც მათ საცავად იყენებს, ბაგი აქვს, რომელსაც object cache ავლენს.

Options cache-ირდება, `alloptions`-ის ჩათვლით. WordPress ყველა autoload-ირებულ option-ს ერთბაშად ტვირთავს და ერთ ჩანაწერად ინახავს cache-ში. თუ option-ს პირდაპირ ბაზაში შეცვლი - phpMyAdmin-ით, მიგრაციის სკრიპტით ან search-replace-ით - WordPress cache-ირებულ მნიშვნელობას აჩვენებს, სანამ cache არ გასუფთავდება. ეს კლასიკური "ბაზაში საიტის URL შევცვალე და არაფერი მოხდა"-ა. ბაზის ნებისმიერი პირდაპირი რედაქტირების შემდეგ გაასუფთავე cache plugin-ის ეკრანიდან ან wp cache flush-ით.

მასთან დაკავშირებული ხაფანგია უზარმაზარი alloptions ჩანაწერი. ზოგი plugin ასობით კილობაიტ options-ს autoload-ით ტვირთავს; მაშინ ყოველი მოთხოვნა ამ ბლოკს Valkey-დან იღებს და მოთხოვნაზე მეხსიერება იზრდება. Query Monitor და wp option list --autoload=on --format=total_bytes ზომას აჩვენებს. Autoload-ირებული options-ის შემცირება ეხმარება object cache-ით თუ მის გარეშე.

Staging ასლები, მიგრაციები და multisite

სამი სიტუაცია cache-ს სიჩქარის ნაცვლად დაბნეულობის წყაროდ აქცევს, და თითოეულს მარტივი წესი აქვს.

Staging ასლები. დააკლონე საიტი staging-ზე, მასთან ერთად wp-config.php დააკოპირე, და staging საიტი ახლა production-ის cache ჩანაწერებს კითხულობს და წერს - იგივე host, იგივე პრეფიქსი. Staging-ის ცვლილებები production-ზე ჩანს, სანამ key-ებს ვადა არ გაუვათ, production-ის options კი staging-ზე ჩანს. მიეცი ყოველ ასლს საკუთარი WP_REDIS_PREFIX, ან საკუთარი Valkey, პირველი გვერდის ჩატვირთვამდე. WP_ENVIRONMENT_TYPE-ის სწორად დაყენება თავისთავად cache key-ებს არ ცვლის.

მიგრაციები. საიტის ახალ ჰოსტზე გადატანა URL-ების search-replace-ით ბაზის პირდაპირი რედაქტირებაა, ამიტომ ახალ ჰოსტზე object cache გაასუფთავე import-ის შემდეგ და ტესტირებამდე. WordPress-ის ახალ ჰოსტზე გადატანა გადატანის დანარჩენ ნაწილს ფარავს. თუ ბაზას გადაიტან, მაგრამ იგივე Valkey-ს ტოვებ, იქაც გაასუფთავე.

Multisite. ქსელი ერთ drop-in-სა და ერთ პრეფიქსს იზიარებს; plugin ქვე-საიტებს blog id-ით აცალკევებს და ზოგ ჯგუფს, მაგალითად მომხმარებლებსა და საიტის მეტამონაცემებს, მთელი ქსელისთვის გლობალურად განიხილავს. ნუ შეეცდები თითო ქვე-საიტს საკუთარი პრეფიქსი მისცე საიტზე მუდმივების რედაქტირებით. Cache-ის ზომა მთელ ქსელზე შეარჩიე და ელოდე, რომ გასუფთავება ყველა ქვე-საიტს ერთდროულად შეეხება.

Deploy-ები. კოდის deploy-ების უმეტესობას გასუფთავება საერთოდ არ სჭირდება. Deploy, რომელიც ცვლის, როგორ ინახავს plugin cache-ირებულ მონაცემებს - ახალი სტრუქტურა იმავე key-ის ქვეშ - სჭირდება, და plugin-ის საკუთარი განახლების რუტინა ჩვეულებრივ ამას აგვარებს. როცა deploy შეცდომებს იწვევს, რომლებიც გასუფთავების შემდეგ ქრება, სწორედ ეს მოხდა.

პრობლემების მოგვარება#

"Error establishing a Redis connection" ან სტატუსი ამბობს Not Connected. შეამოწმე host, პორტი და პაროლი WordPress სერვერიდან valkey-cli-ით. Connection refused ნიშნავს, რომ მისამართი ან პორტი არასწორია; WRONGPASS ან NOAUTH ნიშნავს, რომ პაროლია არასწორი.

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

ბაზაში შეტანილი ცვლილებები არ ჩანს. Cache-ირებული options. გაასუფთავე object cache.

ჩართვის შემდეგ გვერდები შენელდა. ჩვეულებრივ latency: თუ cache-ის ყოველი გამოძახება ნელ ქსელს კვეთს, გვერდზე ასობით გამოძახება ჯამდება. შეამოწმე, რომ WordPress და Valkey ერთმანეთთან ახლოს არიან. უფრო იშვიათად, Predis საიტზე, რომელიც გვერდზე ათასობით cache გამოძახებას აკეთებს, phpredis-ზე ნელია.

`object-cache.php` სულ ქრება ან სხვა plugin-ისაა. ორი cache plugin drop-in-ისთვის ეჯიბრება ერთმანეთს. აირჩიე ერთი და მეორეს object cache ფუნქცია გამორთე.

საიტი Valkey-ის გათიშვის შემდეგ მთლიანად ტყდება. ასე არ უნდა ხდებოდეს - plugin ბაზაზე გადადის. თუ ხდება, WP_REDIS_DISABLED დააყენე true-ზე, რომ საიტი აამუშავო, და შეამოწმე timeout-ები.

FAQ#

მჭირდება object cache, თუ page cache უკვე მაქვს?

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

თავსებადია თუ არა Redis Object Cache Valkey-სთან?

ის Redis პროტოკოლზე ლაპარაკობს phpredis-ის, Relay-ის ან Predis-ის მეშვეობით, Valkey კი ამ პროტოკოლს ახორციელებს, ამიტომ ის იმავე host-ის, პორტისა და პაროლის პარამეტრებით უკავშირდება. მიუთითე მუდმივები Valkey სერვერზე და ჩვეულებრივად ჩართე.

შეუძლია რამდენიმე WordPress საიტს ერთი Valkey ინსტანციის გაზიარება?

დიახ, თითო საიტზე უნიკალური WP_REDIS_PREFIX-ით, ან ცალკე ლოგიკური ბაზებით WP_REDIS_DATABASE-ით. ისინი მეხსიერებას გაიზიარებენ, ამიტომ დიდ საიტს შეუძლია პატარის ჩანაწერები გამოდევნოს. მნიშვნელოვანი საიტებისთვის ცალკე ინსტანციები მათ დამოუკიდებლად ინახავს.

დაიკარგება მონაცემები object cache-ის გასუფთავებით?

არა, თუ plugin-ები სწორად იქცევიან: object cache-ში ყველაფრის ბაზიდან თავიდან აგება შეიძლება. ელოდე ერთ ნელ წუთს, სანამ გათბება. გამონაკლისია plugin, რომელიც აუცილებელ მონაცემებს მხოლოდ transient-ებში ინახავს, და ეს plugin-ის ბაგია.

ეხმარება object cache WooCommerce-ის checkout-ს?

დიახ - კალათის, checkout-ისა და ანგარიშის გვერდების page cache-ში ჩადება შეუძლებელია, ამიტომ ისინი ყოველ ჩატვირთვაზე PHP-ს უშვებენ და ბაზას ეკითხებიან. პროდუქტების, options-ისა და სესიასთან დაკავშირებული ძიებების cache ამ სამუშაოს ამცირებს. ის არ აჩქარებს გადახდის gateway-ს გამოძახებებს, რომლებიც გარეა.