ამ სტატიაში ჩვენ განვიხილავთ მიკროკეშირებას: რატომ არის საჭირო, როგორ უნდა დააყენოთ და რა სირთულეები შეიძლება შეგხვდეთ გზაზე.
რა არის მიკროკეშირება?
მიკროკეშირება — ეს არის კეშის ტიპი, რომელიც სრულად ქმნის გვერდების ფაილებს და საშუალებას აძლევს უკვე მზადყოფნაში მყოფ გვერდს, რომ გამოიცვალოს ბექენდ სერვერზე მოთხოვნის ნაცვლად.
ამგვარი კეშირების მთავარი მინუსი, რა თქმა უნდა, ის არის, რომ გვერდები ძალიან იშვიათად განახლდება. მაგრამ რა არის ამგვარი კეშირების უპირატესობები?
მოდით, ავიღოთ სიტუაცია სუსტი სერვერით და საკმაოდ სწრაფი ვებსაიტით, მაგრამ მასზე დიდი რაოდენობით მოთხოვნები მოდის ბოტებისგან. ისინი დატვირთავენ როგორც ბექენდს, ასევე მონაცემთა ბაზას, რაც გამოიწვევს ვებსაიტის შესრულების ვარდნას და მისი დატვირთვა უფრო ნელა იქნება. აქ მიკროკეშირება მოდის დახმარებაში: ჩვენ უბრალოდ ვაძლევთ უკვე მზადყოფნაში მყოფ გვერდებს, არ ვტვირთავთ არც ბექენდს და არც მონაცემთა ბაზის სერვერს. ასევე მიკროკეშირება საშუალებას აძლევს გვერდებს ბევრად უფრო სწრაფად დაიტვირთოს, რადგან არ არის საჭირო ყოველი მოთხოვნის დროს ბექენდიდან პასუხის მოლოდინი.
ამგვარი კეშირება არ გამოდგება დინამიური ვებსაიტებისთვის და ადმინისტრაციული პანელის გვერდებისთვის, მაგრამ თუ გაქვთ გვერდი, რომელსაც, მაგალითად, ერთხელ დღეში განაახლებთ, ეს შესანიშნავი ვარიანტია.
ახლა შეგვიძლია გადავიდეთ მიკროკეშირების კონფიგურაციაზე.
მიკროკეშირების კონფიგურაცია
ამისთვის გვჭირდება დირექტორია, სადაც ჩვენი კეში იქნება შენახული.
ამ სტატიაში გამოყენებული იქნება ნაწილობრივი RAM როგორც დისკზე ადგილი, რადგან ეს უფრო ეფექტურია, ვიდრე ასეთი ფაილების შენახვა დისკზე.
პირველ რიგში, შევქმნათ დირექტორია, სადაც ჩვენი კეში იქნება შენახული, ჩვენს შემთხვევაში /home/cache:
mkdir /home/cache
მონტაჟება 1 GB RAM როგორც ფაილების ადგილი შემდეგი ბრძანების საშუალებით:
mount -t tmpfs -o size=1G tmpfs /home/cache
და დავამატებთ ამ სივრცის მონტაჟს ყოველი სერვერის გაშვების დროს (ეს სტრიქონი უნდა დაემატოს ფაილში /etc/fstab):
tmpfs /home/cache tmpfs rw,size=1G 0 0
ასევე ვაწესებთ უსაფრთხო უფლებებს დირექტორიისთვის:
chown www-data:www-data -R /home/cache
chmod 700 /home/cache
მზადაა, ჩვენ მოვამზადეთ ადგილი კეშისთვის. ამ გადაწყვეტილების პლუსია ის, რომ სერვერის გადატვირთვის დროს მთელი კეში იწმინდება.
ახლა ჩვენ ვიმუშავებთ პოტენციურ სირთულეებზე, რომლებიც შეიძლება ხელი შეუშალოს კეშთან მუშაობას, და რის გამოც ის არ იმუშავებს, მიუხედავად იმისა, რომ კეშის ფაილები იქმნება. პირველი, რაც უნდა გააკეთოთ — PHP-ში პარამეტრი session.cache_limiter უნდა დააყენოთ public, წინააღმდეგ შემთხვევაში ვებსაიტის სათაურში იქნება მითითებული Pragma: no-cache, რაც არ მოგვცემს კეშის სწორად გამოყენების და შექმნის საშუალებას.
მეორე სირთულე — საჭიროა სტრიქონის დამატება თქვენი ვებსაიტის .htaccess ფაილში. რეკომენდირებულია max-age-ის დაყენება ასევე, როგორც დანარჩენი კეშისთვის, რათა კეში არ მოძველდეს:
Header set Cache-Control "max-age=300, public"
ახლა ჩვენ შეგვიძლია ვიყოთ დარწმუნებული, რომ თითქმის არაფერი შეგვიშლის კეშის გამოყენებაში. ყველაზე მნიშვნელოვანი ბოლოს დავტოვე, კერძოდ Nginx-ის კონფიგურაცია.
ფაილში /etc/nginx/nginx.conf უნდა დაემატოს შემდეგი სტრიქონები http სექციაში:
proxy_cache_path /home/cache levels=1:2 keys_zone=global_cache:100m max_size=1g inactive=5m;
proxy_cache_valid any 5m;
proxy_cache_valid 200 5m;
proxy_cache_valid 404 15s;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_503;
proxy_cache_lock on;
ვებსაიტის კონფიგურაციის ფაილში location / ბლოკში უნდა დაემატოს შემდეგი სტრიქონები:
location / {
proxy_cache global_cache;
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_key $host$request_uri;
proxy_ignore_headers "Set-Cookie";
proxy_pass http://backend;
}
ISPManager-ისთვის ეს სტრიქონები უნდა დაემატოს location @fallback ბლოკში, რადგან ყველა მოთხოვნა ბექენდზე გადის ამ ბლოკის საშუალებით.
ახლა ავუხსნი, რა პასუხისმგებლობა აქვს თითოეულ სტრიქონს, რომელიც ჩვენ დავამატეთ კონფიგურაციაში:
proxy_cache_path /home/cache levels=1:2 keys_zone=global_cache:100m max_size=1g inactive=5m;- proxy_cache_path — გზა, სადაც კეში იქნება შენახული.
- levels=1:2 — შეიძლება გამოყენებულ იქნას არა უმეტეს 3 ჩასმის (მაგალითად, 1:2:3). ციფრები პასუხობენ კეშის დირექტორიების სახელების სიმბოლოების რაოდენობას, რაც საჭიროა ნელი დისკების სწრაფი მუშაობისთვის. თუ მხოლოდ
levels=1-ს გამოიყენებთ, ნელი დისკების შემთხვევაში კეშის ეფექტი მცირე იქნება, რადგან დიდი რაოდენობით ფაილები შეიქმნება. რეკომენდებულია უკვე მზადყოფნაში მყოფი კონფიგურაციის გამოყენება. - keys_zone=global_cache:100m — ზონის სახელი, რომელსაც ჩვენი ვებსაიტები მიმართავენ. თუ კეში კონფიგურირებულია
global_cacheზონაზე, ის ფაილებს ეძებს კონკრეტულად/home/cacheდირექტორიაში.100m— კეშისთვის სახელების ზონის ზომა. - max_size=1g — კეშის საერთო ზომა.
- inactive=5m — დრო, რომლის განმავლობაში კეში აქტიურად ითვლება. თუ ამ დროს კეშზე არ მიმართავენ, სისტემა მიიჩნევს მას არაქტიულად და შეუძლია წაშალოს.
proxy_cache_valid any 5m;— დრო, რომლის განმავლობაში კეში შენახული იქნება.anyნიშნავს, რომ ყველა HTTP კოდი, გარდა კონკრეტულად მითითებული, 5 წუთის განმავლობაში იქნება შენახული.proxy_cache_use_stale error timeout invalid_header updating http_500 http_503;— საშუალებას აძლევს ძველ კეშს გამოყენება შეცდომების დროს, რომლებიც მითითებულია სტრიქონში.proxy_cache_lock on;— არ აძლევს საშუალებას ერთდროულად რამდენიმე მოთხოვნიდან ერთნაირი კეშის შექმნას.proxy_cache global_cache;— მიუთითებს, რომელი კეშის ზონა უნდა გამოიყენოს ვებსაიტმა.proxy_cache_key $host$request_uri;— კეშის სტატუსის შემოწმება. თუ სათაურში იქნებაX-Cache-Status: HIT, მაშინ ყველაფერი სწორად არის კონფიგურირებული. თუMISS, მაშინ უნდა ვეძიოთ მიზეზები.proxy_ignore_headers "Set-Cookie";— საშუალებას აძლევს შექმნას მოთხოვნა, იგნორირებას უკეთებს ქუქის. ამის გარეშე კეში არ აჩვენებსHIT, რადგან ყოველი მოთხოვნა უნიკალური იქნება.proxy_pass http://backend;— აქ უნდა მიუთითოთ ბექენდ სერვერის IP და პორტი (მაგალითად,localhost:8080, თუ Apache2 გამოიყენება როგორც ბექენდ სერვერი).
კეშის სტატუსის შემოწმება შესაძლებელია ბრძანების საშუალებით:
curl -I http://თქვენი_ვებსაიტი
პასუხში იქნება სათაური X-Cache-Status: HIT (ან MISS, BYPASS). ყველაფერი, რაც არ არის HIT, — ეს არის შეცდომა.
მზადაა. ჩვენ მიკროკეშირება დავაყენეთ ვებსაიტზე.
*ვებსაიტი articlesite.com შექმნილია სპეციალურად სტატიისთვის.
ასევე გთავაზობთ სხვა სასარგებლო სტატიების განხილვას: