Сайт с голямо натоварване, написан на Kohana - За чист и ясен код!
Въведение
„Много бърза рамка. Сравняването на рамка е трудно и рядко отразява реалния свят, но Kohana е много ефективна и внимателно оптимизирана за използване в реалния свят.“
Така е написано на главната страница на тази рамка, вярно ли е? Да, но с пила. Малко за проблема. Имах поръчка от студио creative-cafe.ru за един силно натоварен проектhttp://www.jv.ru/longlivers, изглежда работи добре и бързо на машина за разработчици. Индикаторите за зареждане на главната страница с деактивирани системи за кеширане под Ubuntu 11.10 показват 1-2 секунди (след оптимизация 30-50ms), под Windows обикновено е охрана от 4-5 секунди и същият хардуер, само различни операционни системи, но тази статия не е за това (съветвам ви да работите под операционна система, близка до производствената). Така че индикаторите изглеждат доста добри за 1-2 секунди, но в производството сървърът ще бъде по-мощен, като цяло лети там, но до някои действия. Когато клиентът натисна F5 и го задържи за 10 секунди, сървърът успя да изтегли съдържанието само след 30 секунди ... Общо бяха изпратени около 200-300 заявки ... Това вече не е редът, но какво ще стане, ако дойдат 1000?
Инструменти за оптимизация
На първо място, трябва да се погрижите за базата данни (структури, заявки), кеширане, компресиране на стилове и скриптове.
Оптимизация на бази данни
Базата данни в проекта обикновено е малка, 15 таблици, тя е изцяло направена според нормализацията, ключовете са зададени на местата, които са необходими, всички заявки са оптимизирани, заявките, които са „системни“ (повече за това по-късно), се кешират. Общо 22 заявки се изпълняват на основната след кеширане и отнема малко 2,5 ms. За да оптимизирате таблицата, мога да препоръчам да използвате функцията за обяснение, да прочетете какво представлява нормализирането на таблиците на базата данни и също така препоръчвам настройка и гледанерегистър на бавните заявки, той ще бъде уместен, когато базата данни събере информация и тогава можете да видите коя заявка надвишава прага на бавните заявки. Но всичко това не се отнася за рамки, това е просто разбиране на това как работи базата данни.
Как една рамка може да ни помогне? За да работя с базата данни, използвах ORM, както можех да забележа при работа с различни рамки, всички ORM четат структури на таблици, както Zend Framework, така и Kohana. И защо трябва да четем структурата на таблиците всеки път, ако те рядко се променят, особено в производството? За да направите това, трябва да кеширате тази информация, по-долу е класът, който ви позволява да направите това:
Сложих този метод в папкатаapplication/classes/orm.php в модели, които използват наследяване от ORM, не промених нищо, т.е.
рамката първо търси този файл „при мен“ и ако не го намери, ще го намери на мястото му в ORM модула. И така с този метод реших проблема с допълнителните заявки. Освен това, в зависимост от проекта, е възможно да се кешират данните от заявката, които са статични по природа (имам различни настройки, амин сапун, брой данни на страница и т.н.)
Разбира се, самата ORM зарежда системата, т.к. връща всички данни от заявката, т.е.изберете * от, но как да го направите, ако имате нужда само от определени полета? Не знам, който знае да ми каже. Това е особено забележимо при голяма таблица с голям брой полета и голямо количество данни. Със сигурност има повече проблеми в базата данни, но все пак е трудно за ORM. Използването на прости заявки е много по-малко ресурсоемко, но уви, ние губим в простотата на изграждане на заявки.
Стилове и скриптове
кеширане
За системата за кеширане избрах memcache, тя ви позволява да запазвате данни по тип key=> стойност, съхранява ги в RAM на сървъра, така че работата с този тип кеш е много бърза.
Отказвамкъдето е възможно от използване на ООП
Конкатенация на съдържанието на файла
Когато сайтът се управлява от Kohana, много файлове са свързани чрез вътрешния автозареждащ файл, само около 70 системни файла, останалите са силно зависими от свързаните модули и достигат до 260 на главната страница на сайта. Времето, през което локалният ми компютър ще свърже тези файлове, обикновено е смешно 5 ms, не бих му обърнал внимание, но клиентът поиска да комбинира всичко в един файл и да намали броя на включванията ... Е, какво да кажа, той плаща. Този модул е намерен от един блогър, описание и решение на проблема тук SuperCache. След прилагането му броят на фалите е намален на 75 от 260.
Инструменти за профилиране
Използвах различни инструменти за проследяване на тесните места. Например, харесах DebugToolbar, това е чисто информационен модул, който показва всички необходими глобални променливи със стойности, времето за изпълнение на различни части от рамката, заявките на страницата, кои модули са свързани, кои рутери има и кои рутери са включени и много повече, посочих всичко това в примера, в долната част на страницата, също така показва измервания на времето чрез марки, зададени с помощта на класаProfiler.
Вторият инструмент е класътProfiler и е вграден в ядрото на рамката. Само с помощта на този клас успях да поставя точки в различни части на сайта и да видя коя част колко време отнема да се изработи. Например, интересуваме се колко време отнема изчертаването на форма, вземаме начална точка в началото на формата и точка на спиране в края. Профайлърът ще ни каже колко време е отнело, точно това ми помогна да намеря тесните места. Ще опиша как се работи с профайлъра в друга статия.
Тук ще дам само един пример, който ще покаже 2 еднакви фигури (само рисуване безлогика на работа). В най-долната част на формуляра има профайлър, има раздел „Изграждане на формуляр“ и има две точки в него, както можете да видите, резултатите са осезаеми - изграждането на чист html е хиляди пъти по-бързо от изграждането на същото на ООП, особено ако си го представите като част от голям проект. Обърнете внимание на количеството използвана памет. Също така в горния десен ъгъл е DebugToolbar, там също е необходимата информация за работа.
PS Нуждаете се от отстъпки за продукти или услуги? Купете купони на www.newsavings.ca, за да спестите пари.