Отдавна не съм писал в блога на тема “varnish“, но ето че версия 4 на любимият ми HTTP “ускорител” ме накара да го сторя.
Varnish 4 излезе преди година и нещо, но така и не си направих труда да обновя версията на web.root.bg от 3 до 4 заради многото промени по конфигурационните файлове. Невъзможността на SSL поддръжка от страна на varnish-cache.org беше втората причина поради която не съм се занимавал досега с обновяване.
Днес обаче реших да си поиграя и успях да направя работеща инстанция с версия 4.1. Разликите със старата 3.0.5 са изключително много, но за феновете на кеширането като мен, новата версия определено си заслужава. Въпреки това продължавам да се доверявам изцяло на комбинацията nginx + W3 Total Cache + nginx cache ot rtcamp.com за WordPress системи, но ползвам varnish за CDN мрежата ми.
Тъй като конфигурационният файл е доста голям, съм го приложил в gitlab-a.
Искам да споделя че, постепенната трансформация на сайта ми към SSL е вече напълно приключила! От както през лятото google обявиха, че ще взимат за критерий в ранкването си, сайтовете да имат валиден SSL , аз започнах да работя по този въпрос.
Срещах какви ли не спънки – конфигурационния файл на nginx-a за блога ми е голям батак. Отгоре на всичко използвам много плъгини и там също каша и се получаваше loop когато направя сайта да е винаги през HTTPS.
Е уви, вече всички тези проблеми са останали на заден план и всичко си работи. Последната дивотия която бях пропуснал да направя, е да добавя CA сертификата на StartSSL.com при nginx-a, и така някой от браузърите не виждаха валиден моя сертификат.
След като направих това, и тествах през sslshopper.com, реших че е време да слагам 301 редирект и всичко да ходи към nginx-a на SSL.
Това което остава да направя, е да измисля как varnish-а ми да работи на 443 порт ( за сега не работи ) – може би е време да го ъпдейтна до версия 4.
Днес ще пиша за един проблем който мъчи блога ми от доста време. Става дума за страниците в блога където има много снимки – когато се отворят за първи път (преди varnish-a да е направил кеширан вариянт на страница) се отваря за около 2 минути!! Това е просто меко казано нелепо и трябваше да го оправя!
Днес открих че проблема е от една заявка която прави w3-total-cache плугина когато се използва CDN. Ако спазваме внимателно указанията за инсталация на този плугин трябва да напишем следната заявка:
DROP TABLE IF EXISTS `wp2_w3tc_cdn_queue`;
CREATE TABLE IF NOT EXISTS `wp2_w3tc_cdn_queue` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `local_path` varchar(500) NOT NULL DEFAULT '', `remote_path` varchar(500) NOT NULL DEFAULT '', `command` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '1 - Upload, 2 - Delete, 3 - Purge', `last_error` varchar(150) NOT NULL DEFAULT '', `date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', PRIMARY KEY (`id`), KEY `date` (`date`) ) ;
Ами хубаво ама не правете това! Днес открих че MySQL-a ми товареше на 160% CPU като отворя сайта на Ани и след като отворих mysql.log видях следното:
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/jquery/jquery.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/jquery/jquery-migrate.min.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/wlwmanifest.xml'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/comment-reply.min.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-content/themes/postline/js/audio-player.js'
И ето защо страниците със снимките се отварят така мега бавно! Дропнах таблицата и си реших проблема завинаги!
MariaDB [jbblog]> DROP TABLE IF EXISTS `wp2_w3tc_cdn_queue`; Query OK, 0 rows affected (0.04 sec)
Уеб хостинг технологиите се развиват с всеки изминал ден. Разполагането на един сайт на няколко сървъра с цел балансиране е вече нещо нормално. Има много готови вариянти за хардуерен load balancer – например F5 които обаче са доста скъпи. Тук идва и нуждата от готово такова безплатно решение.
По принцип аз използвам varnish като балансьор пред уеб сървърите ми, но за целта са необходими доста настройки и технологични познания в областта.
Започнах да го разучавам и открих това, че инсталирането и конфигурирането му е доста лесно. Може да работи като cluster – два master-а или един един master и един slave/backup/.
Ще започна с тестването му като пусна един или два сайта да минават през него. Смятам да пусна snimka.net тъй като е доста натоварен и ще разбера дали ще работи нормално. Идеята ми е да направя нещо такова:
Тъй като потреблението на сървърите ми постепенно се покачва, наскоро включих и втори сървър с varnish за load balancing. Поради тази причина също трябваше да помисля за някакъв мониторинг над двата прокси сървъра.
Аз лично предпочитам mrtg, но също така полвам и cacti за рисунките, но ми трябваше да вкарам nagios-а в употреба, с цел да ме известява когато има проблеми.
Доста търсих из нета за подходящи плугини и най-накрая попаднах на нещо добро!
За целта трябваше да си инсталирам NRPE (Nagios Remote Plugin Executor) чрез който да изпълнявам команди на двата varnish сървъра.
Намерих 2 плугина, съответно ще напиша и за двата как става номера с инсталирането.
Единия казва дали backend-а (VCL) работи или не.
Другият пък казва средното hit ratio на varnish-a (може да се настрой кога да казва critical, кога да казва warning)
Изтегляме check_varnish_backends.py и го местим в /usr/lib/nagios/plugins/check_varnish.pl и му слагаме chmod +x
След това отваряме /etc/nagios/nrpe.cfg и слагаме следния ред най-отдолу:
Здравейте,
Добар ден,
Привет!