Црн петок - ТЕХНИЧКИ водич за преживување - дел 1 - лак

Оваа статија е дел од серијата од 3 статии дизајнирани да им помогнат на онлајн продавниците да го надминат црниот петок.

  • ова е првиот дел
  • Во дел 2 разговаравме за ЦДН
  • Во идната статија ќе зборуваме за „паралелизација“ - односно употреба на неколку сервери истовремено.

Црниот петок е веќе голем настан во Романија. Не само ние во индустријата го зборуваме тоа, тоа се гледа во целиот печат. Ако оние што се занимаваат со маркетинг и продажба имаат причина да се радуваат, луѓето во техничките оддели се дефинитивно stresaИ> i на настанот. Ние бевме.

Оваа година серверите на Авантикарт поминаа скоро совршено 1, без застој и многу добри времиња на одговор (генерално помалку од 500 милисекунди). НЕ Не измислив ништо ново. Прочитав многу, експериментирав и составив различни технологии.

Исто како што ни помогнаа тоа што другите го напишаа, ние сакаме да вратиме нешто. Ние веруваме дека само со споделување на наученото, сите можеме да одиме напред. Преку овој напис, ние сакаме да им помогнеме на програмерите и заедницата за е-трговија во Романија да ги надминат претстојните Црни петок.

Добро, остави ја приказната и кажи ми што направи

На кратко, имаше 3 работи што доведоа до непречено одвивање на работите:

  1. Лак - моќна меморија
  2. CDN за слики и css/javascript
  3. Споделување барања на повеќе сервери

Ако сте сопственик на продавница на почетокот на патот, ве молиме, не го стреснете вашиот програмер со сите горенаведени. Не сите 3 се достапни за која било продавница. Точка 2 веројатно е доволна.

Добро, да го земеме секој одделно. Да започнеме со Лак затоа што тој веројатно е тој што ја „спаси“ ситуацијата во Авантикарт. За CDN и употреба на повеќе сервери, наскоро ќе се вратиме со написи.

Лак

За разлика од „нормалниот“ блог или страница, многу потешко е да се складира во продавница за Интернет. Зошто? Две главни причини:

  • затоа што не можете да ја складирате количката во вашата кошничка. Се повикуваме на ова парче од страницата:
  • бидејќи акциите треба да работат во реално време

Веројатно вашата платформа веќе има стандарден модул за кеш меморија (кешот може да се направи на неколку нивоа), но ние гарантираме дека ништо не го победува Лакот. Еве го врвот: побарајте додаток за лак за вашата платформа. Дури и да чини (самиот приклучок + имплементацијата) ќе видите дека вреди. Не е само црн петок. Зошто не сакате 100 милиони пати на одговор во текот на целата година?

Зошто лакот е толку гласен?

Лакот функционира како веб-сервер, што е првата точка на интеракција со посетителот. Во основа Лак „stЂћѓвЂќ пред Apache/Nginx или кој било веб-сервер што го користите и кешира сè што ќе фати. Така, многу малку апликации завршуваат со трошење ресурси (врски со бази на податоци, итн.).

По инсталирањето на Лакот, работи на портата 6081. Стандардно, треба да ја смените во порта 80, во спротивно ја губите целата забава. За да го направите ова, датотеката/etc/default/лак мора да се измени. Ние користиме Debian, за CentOS или други дистрибуции, конфигурацијата може да се разликува.

Во датотеката погоре, ќе најдете линија како:

Тука треба да промените од -а: 6081 во -а: 80. Исто така, би било корисно да поставите TTL користејќи го параметарот -t. Затоа таа линија станува нешто како:

Добро, сега кога го сменивме пристаништето во Лак, ќе мора да ја смениме и портата на веб-серверот. Ние користиме Apache, затоа ја менуваме датотеката /etc/apache2/ports.conf. Ја менуваме линијата Слушај 80 во Слушај 8080. Теоретски, тоа е доволно, но зависи од тоа како ги поставувате Виртуелните домаќини. Ајде да го рестартираме Apache и потоа да исчезне.

Досега беше едноставно, но сè уште не е подготвено. Лакот работи, но најверојатно не скрива ништо. Како знаете дали треба да кеширате? Освежете страница 2-3 пати. Потоа, погледнете во алатките Firebug/Developer.

Firebug Developer

Најверојатно, заглавието на Age покажува нула. Знак дека нема кеш меморија.

Проблеми со диета?

Нешто важно да се знае: Лакот има проблем со колачи. Нема да зачувува страница ако испраќа колачиња. Исто така, нема да се меморира ако серверот испрати заглавие за контрола на меморија без вредност на кешот. Да видиме како ги решаваме овие проблеми.

Avanticart е напишан на PHP, како и повеќето решенија за е-трговија со отворен извор (или заштитени) достапни на пазарот. Ако вашата продавница е напишана на друг јазик, сигурни сме дека ќе можете да најдете слични решенија.

Стандардно, PHP испраќа заглавие за контрола на кеш кога ќе ја започнете сесијата. Во алатките Firebug/Developer можете да видите нешто како:

За да се ослободите од него, само јавете се на session_cache_limiter (''); Пред почетокот на сесијата (); . Бидете внимателни како го додавате овој код. Ако користите платформа со отворен извор, ќе имате проблеми со идната надградба доколку директно го промените изворниот код. Може да напишете приклучок или да најдете поставка.

Сега, кога овој проблем е решен, да видиме како го решаваме со колачиња. Најдов интересни детали на страницата Брзо. Во суштина, се прават низа трикови за бришење на колачињата и враќање во форма на заглавие. Датотеката /etc/varnish/default.vcl треба да се измени за да покаже нешто како:

Сметаме дека коментарите во кодот се доволни, но да забележиме дека бараме колаче за сесија со името APP_SESSID_ (нешто). Тука ќе мора да го смените името на колачето на вашата платформа.

Друга важна работа што треба да се забележи е дека првото барање што го направил посетител секогаш ќе пристигне во продавницата без да меморира. Ова е направено за да се добие колачето за сесија.

Во споредба со верзијата предложена од Брзо, го додадовме овој дел како додаток:

Тоа е, ние не сакаме да се зачувуваме ако посетителот е на страницата за наплата, на страницата со сметка или ако барањето е датотеки .php (обично барања од Ајакс, бидејќи повеќето URL-адреси се SEO-пријателски, така што не завршува со .php). Сигурно имате страници што не треба да се зачувуваат. Треба да ги идентификувате и соодветно да ја измените датотеката.

По рестартирање на Лакот и направените 2-3 барања, треба да го видите заглавието за возраста што не е нула во Firebug/Developer алатки.

Ако стигнете овде и се ослободите од вашите проблеми со исхраната, честитки, вашиот Лак може да се дебелее (создава стомак - извинете - кеш). Ако заглавието Агеј сè уште покажува нула, тоа значи дека нешто не е во ред. Мора да го решите ова прашање пред да продолжите.

Кој ги јадеше колачите?

Добро, сега кешот се креира, но сепак колачињата не завршуваат во апликацијата на продавницата. За ова, треба да ја генерираме променливата $ _COOKIE од заглавието поставено од Varnish.

И ја создадов оваа одлика:

Повторно, бидете внимателни каде ја пишувате/повикувате оваа одлика за да избегнете проблеми со вашата идна надградба.

Кошницата, како и со корпата?

Супер Имаме кеш меморија, имаме колачиња. Останува само еден проблем: целата страница е зачувана, вклучително и делот од кодот што ви покажува колку производи имате во вашата кошничка.

За да тестирате, можете приватно/инкогнито да отворите нов прозорец на прелистувачот. На второто освежување (првото никогаш не се зачувува, се сеќавате?) Theе ја видите корпата во првиот прелистувач.

Лакот ни дава специјална ознака што можеме да ја вметнеме на страницата. Значи, каде што имаме кошничка, можеме да внесеме код како:

Кога Лакот ќе го види овој код на страницата, тој ќе побара барање до позадината/датотеката /esi_shopping_cart.php, ќе го земе резултатот и повторно ќе ја состави страницата, сето тоа без да знае посетителот.

Ние не го ставаме кодот од /esi_shopping_cart.php тука бидејќи имплементацијата се разликува од платформа до платформа, но може да биде едноставно ехо за некои променливи на сесијата.

За ESI да работи, треба да забележите дека подолу vcl_fetch ја ставам поставената линија beresp.do_esi = true; .

Добро, сè оди совршено, па време е да го извадиме пивото од студ, нели? Не брзајте, досега тоа беше лесниот дел.

Оваа меморија треба да се исчисти. Едноставниот метод е да ја исчистите целата меморија кога вршите какви било промени во продавницата. Тоа не би било проблем на обичен ден, но тука зборуваме за Црниот петок. Ако започнете да ја чистите целата меморија со секоја наредба за освежување на залихите, ќе имате проблем. Идеално, кешот треба да го исчистите само за производот чија залиха е променета и веројатно страницата за категории за тој производ.

За да ја исчистите меморијата, треба да направите посебни барања (PURGE/BAN наместо GET/POST) до Лак. Овие барања може да се направат на неколку начини и повеќе детали да се најдат во документацијата. Повеќе сакаме да користиме БАН.

Во Avanticart, бидејќи имаме повеќе продавници на ист сервер, треба да знаеме од која продавница сакаме да ја исчистиме нејзината меморија. Затоа, ние користиме некои дополнителни заглавија (X-Ban-Host и X-Ban-Url). Треба да ги измениме /etc/varnish/default.vcl за да додадеме поддршка за бришење + поставувања заглавија.

Бидејќи овие барања можат да доаѓаат од каде било, подобро е да не дозволиме никој да ја исчисти својата меморија. Ја додаваме оваа линија на почетокот на датотеката:

Потоа ја менуваме функцијата vcl_recv на следниов начин:

Ја менуваме функцијата vcl_fetch за да додадеме специјални заглавија:

И сега го рестартираме Vanish за да ги искористиме промените.

Тука ја имате функцијата PHP што се справува со бришење:

Се разбира, кога и каде ја користите оваа функција е многу важна и може да има влијание врз перформансите. Може да се дадат редовни изрази за $ url. Така, за да ја исчистиме целата меморија може да ја наречеме clearVarnishCache ($ домаќин, '. *');

Сега е навистина подготвено. Ако мислите дека нешто пропуштивме, оставете ни коментар. И ако сакате да добивате идни статии за CDN и повеќе сервери, претплатете се.

погрешен амбиент влијаеше на еден клиент што доведе до чудно однесување на количката (Емилијан, повторно се извинуваме).