От известно време насам, наблюдавам по-бавно зареждане на сайта, а изключително сложното настройване на w3 total cache в комбинация с многото му излишни според мен опции, ме накараха да стигна до тази стъпка.
WordPress WP Super Cache е плъгин, който съм използвал преди няколко години в блога. Плъгин който прави страниците статични html и ги сервира към браузъра на потребителя така. По този начин се избягва динамичната php обработка и съответно сайта се зарежда по-бързо.
Не е ясно дали и за напред ще оставя нещата така, но нищо не ми пречи да тествам!
Също така обмислям варианта да тествам и nginx pagespeed мод-а, но това ще го оставя за бъдещето, защото съм сигурен, че минусите(проблемите) там ще са доста повече от плюсовете!
Отдавна не съм писал в блога на тема „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 мрежата ми.
Тъй като конфигурационният файл е доста голям, съм го приложил в cdn-на.
Днес ще пиша за един проблем който мъчи блога ми от доста време. Става дума за страниците в блога където има много снимки – когато се отворят за първи път (преди 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)
Привет! От няколко дни чета и тествам портнатото приложение за nginx – ngx_pagespeed. Идеята му е сайта ни да се отваря още по-бързо. Преди 2 години google го пуснаха но само за apache. Е наближава момента и ние , феновете на nginx да го ползваме така успешно както на apache. Онзи ден излезе beta версия-та и така реших да се заема с тестване :biggrin: .
Информация как се инсталира може да прочете в официалната страница на плугина в github
Аз ще прескоча начина на инсталиране и ще премина към конфигурирането което е същественото. Първо е необходимо да имаме създадена предварително директория : /var/ngx_pagespeed_cache/ , и ако може да бъде с права 777.
Следват параметрите които се добавят в конфиг файла на сайта.
Ето така са при мен
# PageSpeed
pagespeed on;
# let's speed up PageSpeed by storing it in the super duper fast memcached
pagespeed MemcachedThreads 1;
pagespeed MemcachedServers "localhost:11211";
# show half the users an optimized site, half the regular site
pagespeed RunExperiment on;
pagespeed AnalyticsID UA-***-1;
pagespeed ExperimentVariable 1;
pagespeed ExperimentSpec "id=1;percent=50;level=CoreFilters;enabled=collapse_whitespace,remove_comments;";
pagespeed ExperimentSpec "id=2;percent=50";
# Filter settings
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters collapse_whitespace,remove_comments,combine_css,combine_javascript,extend_cache,inline_css,rewrite_css,rewrite_images,rewrite_javascript,sprite_images;
# needs to exist and be writable by nginx
pagespeed FileCachePath /var/ngx_pagespeed_cache;
# This is a temporary workaround that ensures requests for pagespeed
# optimized resources go to the pagespeed handler.
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" { }
location ~ "^/ngx_pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
location /ngx_pagespeed_statistics { allow 192.168.*.0/24; allow 87.97.*.*; deny all; }
location /ngx_pagespeed_message { allow 192.168.*.0/24; allow 87.97.*.*; deny all; }
Накратко , тук добавяме хост-а на memcached сървъра , като можем да добавим няколко със запетая помежду им. В секцията EnableFilters добавяме каквито искаме филтри които ще ползваме. Можем да ги видим предварително от ngxpagespeed.com . В последните две директиви location описваме от кои адреси да имаме достъп до статистиките.
След рестарт на nginx вече имаме работещ pagespeed.
Аз се натъкнах на няколко бъга, като главния беше доста зъл – сайта изобщо не се отваряше. Причината беше в една от опциите на w3 total cache плугина ми, а именно : в Browser Cache не трябва да имаме пусната : Enable HTTP (gzip) compression
Това причинява неизвестна грешка в браузъра , мисля че 303 или нещо такова пишеше и нищо се отваря.
Всичко това го направих с цел блога да се отваря още по-бързо. Дано съм помогнал и на други с тази идея.
Привет, днес ще пиша за тези два страхотни плугина за кеширане. От около 2 години използвам WP SuperCache и бях много доволен заради това как е направен юзър френдли и колко лесно се работи с него.
Тъй като мен ме гризе отвътре да се занимавам с нещо по-предизвикателно , реших днес да сменя WP SuperCache с другия така прехвален плугин W3 Total Cache. Този плугин го ползвам в един от сайтовете ми, и наскоро видях че има голям ъпдейт , че така реших ,че е момента и аз да го пробвам. Хареса ми това колко много функции има, поддръжка на ETag ,компресирането на css и js , работи с varnish който ползвам и аз и много други! Просто страхотно!
Разбира се, имах малко проблеми в началото точно с minify настройките му , но не ми отне много време да ги оправя и да тествам след това.
Прилагам графика от pingdom за резултатите на блога ми в период от няколко месеца, където си личи че работата ми си струва, и резултатите говорят сами за себе си 🙂