Оптимізація сайту. Діагнози і курси лікування

Іван Міхеєв (AGIMA)
Іван Міхеєв

Сьогодні ми поговоримо, як ясно з назви доповіді, про оптимізацію. Взагалі, доводилося комусь оптимізувати сайти? Доводилося. На цьому шляху нас зустрічає багато цікавинок, від того, як до нас приходить незрозумілий код – від попереднього підрядника, наприклад, або свій код, який нам доводиться потім переосмислювати – й виникають проблеми, які при певних навантаженнях починають нас дико турбувати.




Якщо ви прийшли за якимось диким хардкором, ви в цій доповіді його, на жаль, не побачите, а може, й на щастя. Те, що я сьогодні буду розповідати – це, взагалі, ніякої не Rocket Science, нічого складно, це ті інструменти, які ви можете отримати навіть на віртуальному хостингу, якщо у вас на highload'е використовується, припустимо, віртуальний хостинг. Розповім про інструменти, про те, які приклади оптимізації були у нас в компанії, і трошки торкнемося масштабування, т. к. це теж з оптимізації, але вже трохи в іншому розрізі.



Перший висновок, який я зробив для себе на шляху моєї історії розробки – це те, що срібної кулі, взагалі, ніде не існує. Тобто немає якогось універсального рішення, універсального підходу або інструменту, який позбавив би усіх від головного болю, яку ми зустрічаємо на шляху оптимізації. Тому ось такий висновок срібної кулі немає.



Також з досвіду я зрозумів згодом, що якщо у вас вчора був день оновлень, і вчора ж у вас впав сайт, то тут теж ніякої особливої науки – справа саме в оновленні. Що ми робимо? Ми випробовуємо назад і починаємо розбиратися, що сталося, що було в релізі не так. Важливо це зрозуміти відразу, що у вас щось сталося не так.



Давайте поговоримо про більш-менш наближеною до реальності ситуації. Наприклад, у вас зростає навантаження на сайт. Можливо, вона росте рівномірно, але, швидше за все, вона у вас росте нерівномірно, а якимись піками. І в ці піки вашого сайту дико погано. Він починає нескінченно віддавати сторінки, у вас білий екран, замість контенту, різні випадкові помилки 500-ті і не 500-ті, ви часто помічаєте обірване від сервера з'єднання, або, взагалі, у вас сторінки завантажуються наполовину, половина картинок не прогрузилась, і, взагалі, там якесь м'ясо діється. Ці симптоми говорять про те, що вам пора задуматися про оптимізацію вашого порталу чи сайту і вже починати робити якісь кроки на шляху до поліпшення.



Щоб структурувати доповідь, розглянемо типові компоненти програми – з чого воно, взагалі, складається? Зазвичай на будь-якій мові є якийсь front-end, де розташований безпосередньо user інтерфейс, тобто якщо сайт, то це браузер, якщо додаток, то якийсь інтерфейс. Є application, на якому крутиться ваш додаток, крутиться вся бізнес-логіка. І є шар даних – це може бути СУБД, це може бути, не дай бог, XML, це можуть бути будь-які дані, які повинні приходити до вас яким би то не було способом application. І маючи цю структуру, повертаємося до проблеми – у нас тупить сайт, він довго вантажиться, є якісь проблеми. З чого почати? Як до цієї справи підійти, що ж нам робити?



Перше, що напрошується – це подивитися на ваш front-end, тому що це допоможе вам відкинути відразу кілька варіантів того, в який бік вам рухатися.



Основні проблеми на цьому етапі – саме проблеми, пов'язані з тим, чому гальмує ваш сайт. Це у вас неадекватно довго завантажується сторінка, тобто ви розумієте, що скрипт відпрацював максимально швидко, але доставка контенту клієнту в браузер відбувається дуже довго. У вас блокується виконання CSS. Це про те, що якщо у вас, наприклад, користувач бачить спочатку білий екран, а потім це якось несподівано перетворюється для нього в щось гарне – це ситуація не дуже… Коли ви бачите часткове завантаження контенту, тобто картинка у вас вантажиться нереально довго, або у вас вимальовується модель дуже довго – це теж не дуже то ситуація. Ну і, затримка виконання JS-скриптів, коли у вас якийсь скрипт підключається 80-м у списку всіх Javaскриптов, і ви розумієте, що він відпрацьовує не так, як треба, то тут теж потрібно щось оптимізувати.



Для діагностики існують досить прості інструменти, які є в кожному браузері, напевно, і не в браузері.

Перше, що напрошується – Firebug. Всі знають, як ним користуватися – натиснули на F12, і навіть в самому старому ie він точно є. Встромили Firebug, подивилися, які у вас там запити, скільки сторінок віддається, коли контент завантажився, і коли виконувався якийсь скрипт. Це, взагалі, безкоштовно, просто подивилися статистику, зайняло це у вас 5 хвилин – ну, дотягнутися до клавіші F12 + пара хвилин. Все, у вас є вся статистика, вже є якесь розуміння, в який бік рухатися далі.

Є дуже цікавий інструмент – YSlow. Він, крім якихось метрик, може вам ще розповісти словами, що вам потрібно виправити. Цей інструмент для мене якесь відкриття.

Ще є Google PageSpeed, який вам ще скаже, як підвищити ранжування вашого сайту на підставі того, що вам потрібно щось на фронті поміняти. Тут, до речі, фронт розглядають з точки зору клієнта браузера.

Таким чином, встромили ці інструменти, подивилися, що у нас зламалося, і починаємо вже щось виправляти.



На що потрібно звертати увагу, коли ви дивитеся ці метрики?

Перше і ключове, більшість тематичних сайтів грішать цим – це швидкість відтворення DOM. Є такі сайти, в яких DOM містить ну дуже багато елементів – більше 10 тис. – це вже стає проблемою для того, щоб це рендери, при скролінгу починають сайти тупити, якщо ви відкриваєте його на телефоні, то це ще більшою проблемою стає. Отже, варто подивитися, скільки у вас, взагалі, малюється з працею.

Друге – це наявність зовнішніх JS і CSS. Це, взагалі, окрема тема, тому що якщо у вас якийсь JS, який лежить у вас на сервері, запитується, причому, ви часом не знаєте, якого в підсумку він буде розміру, тому що є якісь зовнішні бібліотеки, а з ними все складно. І у вас, звичайно ж, починає блокуватися завантаження цих скриптів, тобто він чекає, поки завантажиться один якийсь скрипт, тільки потім починає вантажити ще щось. Те ж саме з CSS, тобто тут потрібно грамотно виділяти такі скрипти і, напевно, вже не йдеться тільки про доступність сервісу, якого забирає у вас цей JS, але і про це теж.

У нас, наприклад, був такий випадок, коли ми викочували сайт одного досить відомого фітнес-клубу. Там був якийсь зовнішній скрипт, який підключався і робив якісь операції. Розробники розробляли, все у них було круто, вони не врахували лише те, що він у них закэшировался на браузері, і коли вони прод його вкотили, то цей скрипт у них там важив півметра. Що таке 500 Кб в рамках перекидання між дисками? Це не дуже великі цифри, але коли це починає грузиться – не дуже круто, коли у вас прелоады вантажаться секунди. Плюс там ще було дуже багато графічного контенту, який теж закэшировался у розробників, а вони як би не запитали кеш. Загалом, багато досліджень проводили, поки в результаті не зрозуміли, що справа це можна було б в Firebug подивитися і все.

Ну, і час встановлення з'єднання з сервером. Тут все цікаво, тому що тут важливо розуміти, що реально у вас фронт тупить, або у вас просто інтернет-канал якийсь дуже слабенький. Такі проблеми теж трапляються, і тут скоріше потрібно йти розбиратися з вашим провайдером мережі, а не копати ваш код.



Які ж можна застосувати методи оптимізації фронту?

Минификация, об'єднання, стиснення – все це впливає лише на два фактора – на вагу і кількість файлів при завантаженні. Коли у вас вантажаться 10 javascript'ов, і деякі з них із зовнішніх сервісів, це не дуже добре позначається на фронтенде, тому що браузер, по-моєму, може підтримувати п'ять одночасних з'єднань (залежить від версії), а все інше блокується. Якщо ви, звичайно, вантажте синхронно. Об'єднання в якомусь моменті допомагає вам цього уникнути – у вас з 10 файлів формується один. І природно, один в 30 Кб завантажиться швидше, ніж 30 в 1 Кб. Це потрібно розуміти.

Але тут є такий момент з точки зору минификации (особливо CSS). Коли у вас йде момент налагодження, то на виявляли у своєму житті таку деякі відкривають девелоперську панель і починають міняти циферки, як це все помінялося, і вони там ще вказують сходинку. Так от, у разі стислих файлів, вони вкажуть вам рядок «1», окрім тих випадків, якщо у вас немає сурс мэпперов на цих минификаторах. Але і так з ними не все так однозначно, тому що іноді деякі сурс мэпперы теж вам тільки якийсь ключовий, головний елемент показують, де починається. А де конкретно в коді, може бути дуже складно. Тут теж потрібно дуже грамотно застосовувати підхід, тому що в налагодженні це може зіграти з вами злий жарт.

Стиснення. Тут все, напевно, прозоро, тому що медіаконтент потрібно точно стискати і не вантажити в контейнер 100 на 100 пікселів якусь Full HD картинку. Зараз до цих пір зустрічаються випадки, коли начебто картиночка маленька, а туди Full HD заганяють, і клієнт каже: «А чому так довго?». Такий момент теж потрібно враховувати.

Друга група інструментів для оптимізації – рефакторинг вашого JS-коду, тому що часто саме він тупить, тому що він написаний. Особливо, якщо ви використовуєте якісь фреймворки, які вам не до кінця зрозумілі, а ще у вас DOM складається з декількох тисяч елементів, а ще у вас якісь події на jQuery і т. д. Коротше, все буде насправді не дуже швидко працювати.

Ну, і оптимізація DOM – це теж важлива річ. Коли, якщо хто пам'ятає, виходив iPad 1 або 2, то у них була проблема, коли вони вантажили всякі тематичні сайти, наприклад, новинні портали типу woman.ru або ще якісь такі. У них історично склалося, що DOM була дуже складною, тобто дуже багато елементів, і просто iPad це не переварював. Ви відкривали сайт, він як би його рендерил-рендерил, рендерил-рендерил, але це не доходило ні до нічого особливо, і тоді вони дуже сильно по цій темі повинні були оптимізуватися. Зайняло, напевно, дуже багато часу.

Ці всі пункти приведуть просто до прискорення роботи вашого сайту.



І безплатну пораду, який відноситься вже не до клієнтів, а більше до фронту вашого проксі або сервера nginx – статику треба віддавати через nginx. Досі ми зустрічаємося з такими випадками, коли статика не через nignx йде, і це на диску позначається не дуже добре, тому, якщо у вас сайт тупить, і ви вважаєте, що в іншому все нормально, перевірте статику – у вас через nginx віддається чи ні?



Перейдемо до більш цікавої частини, це Application і DB. Та частина, на якій насправді зустрічається більшість помилок і яка дає вам просто полігон для оптимізації.



Якщо у вас повільно формуються сторінки, хреново виконується скрипт, формується html, часто зустрічаються помилки 500-ті, будь-які… Будь 500-ая – це вже дзвіночок. Якщо ви спостерігаєте через вашу систему моніторингу якісь простої сайту, то тут, якщо не потрібно бити на сполох, то варто задуматися, чи все у вас, взагалі, в порядку. Якщо це якийсь поодинокий випадок, то можна подумати, подивитися, розібрати його, якщо ж це низка таких випадків, то тут вже точно потрібно підходити комплексно до цієї задачі.



Які у нас є варіанти, коли гальмує Application або DB? Насправді таких ключових блоку три:

  • у вас сервер вичерпав свій ресурс,
  • програмісти зробили якийсь не дуже якісний код,
  • або щось недобре коїться в базі.
Як у цьому всьому, взагалі, розібратися?



Перше, що приходить в голову – це не встановлювати ніяких там профилировщики, не вигадувати якусь незрозумілу річ, а просто зайти у ваш термінал і скористатися звичайними інструментами ОС.

Є у вас команда top, яка допоможе вам зрозуміти, скільки у вас залишилося пам'яті на сервері. Є strace, lsof і т. д. Всі ці команди є в ОС линуксовой, під вінду теж є подібні команди, тобто ви нічого не робите, у вас все є під рукою, ви просто дивіться, яке поточний стан вашого сервера. І взагалі тут немає нічого страшного.

Був випадок у нас з одним рітейлером. У них є такі речі, як каталоги, може, знаєте, їх в pdf викачують. І цікаво, що в день, коли вони викладають, чомусь дуже багато людей їх починає завантажувати. Не знаю, для якої мети, але там реально 2000 чоловік чомусь йдуть на цей портал і починають качати саме каталоги. І у нас сайт прибув трохи. Почали розбиратися. Системний адміністратор просто встромив laptop і зрозумів, що всі файлики віддавалися через apache access_log'ам. Але, звичайно, віддавати файлики pdf через apache не дуже добре. Просто звернули конфіг на nginx (знову ж таки, рада пам'ятаємо? – статику через nginx), всі залітало. Тобто тут явний приклад – ми витратили на це 5 хвилин, просто встромили laptop, подивилися, що з дисками відбувається, подивилися access_log, все. І все відразу стало зрозуміло, поправили.

Якщо навіть у вас ще крутіше – є система моніторингу, то вам навіть в ОС особливо ходити не потрібно, ви з них можете це все зрозуміти. Тобто є різні метрики, за якими ви розумієте, де, в якому місці у сервера настав невеликий криза.



Другий момент – це slow логи. Slow логи є майже скрізь, вони вам допомагають визначити місця і час, коли стався той або інший запит, або скрпит виконувався надзвичайно довго. Основна тема з slow логами, може, проблема, чи не проблема навіть, а просто привід посперечатися, поговорити – це час визначення повільного запиту. Тут насправді все ще простіше. Ви – власник вашої системи та ви знаєте, який час запиту виконання скрипта для вас є оптимальним або допустимим. Просто налаштовуєте slow лог таким чином, щоб усі критичні запити у вас писалися, а всі некритичні не писалися, тобто вам важливо розуміти час, який для вас є критичним, щоб не вважати, якщо два запити виконуються більше трьох секунд, то це вже все. Тому що є така річ як статистика, розрахунки чи звіти, а там як би і 5 секунд на виконання запиту в цілому нормально.



Ще одна порада – краще slow логи включати відразу на початку розробки. Це вас врятує від несподіваних піків навантаження та наступних розборів польотів типу «що у нас сталося?». Тому що з тим же оновленням, коли ви выкатываете на прод, і у вас починає навантаження дуже нерівномірно скакати саме на сервері, то тут вам потрібно швидко відкотитися і повернути стан. А якщо у вас slow лог не був включений, вам буде дуже складно зібрати якусь статистику або метрики. Якщо ж у вас він був включений, то ви просто дивіться метрики, потім все вирішуєте, можливо, проводите якийсь навантажувальне тестування. Власне, ось і все.

Також у нас є різні логи – це error_log і access_log, тобто всі інструменти сервера, який є в нашому розпорядженні, їх можна використовувати, не застосовуючи ніяких додаткових інструментів. Це те, що у вас є в коробці ОС, плюс моніторинг. Але моніторинг потрібно налаштовувати.



Наступний крок на шляху до більш швидкого розуміння вашого додатки, а якщо воно не ваше, то це ще більш цікавий для вас інструмент – це профилировщики. Профилировщики є майже під кожну мову, мені здається, вони є під кожен мову. І кожен поважаючий себе профілювальник відзначено певними плюсами, які, в принципі, для будь-якого профилировщика однакові. Це простота використання, тобто ви просто визначаєте, з якого моменту ви можете стартувати, де йому потрібно закінчити, пишіть в налаштування, що він повинен писати, які поведінкові характеристики і все. На виході ви отримуєте callstack всіх виконаних функцій за час профілювання, тобто ви бачите, яка функція скільки виконувалася у вас є розуміння, скільки ця функція виконувалася сама по собі, скільки виконувалися її вкладені функції, є розуміння, скільки пам'яті вона споживає. А логи профилировщика ще вам дозволяють callgraph побудувати, щоб ви могли простежити маршрут якогось діяння, яке є высоконагруженным, в даному випадку, в якому час виконання більше n-го числа секунд.



Наприклад, є Xhprof. Ми розробляємо на PHP, і у нас є Xhprof. Це те, як він виглядає. Мені здається, у багатьох профілювальником схожий інтерфейс – є якась таблиця з callsteck, і є якийсь граф, який показує вам, звідки починався якийсь складний запит і де він закінчувався.

Є також Visual Studio профайлер, ще різні, на багато мов легко гуглятся будь профилировщики.

Далі, щоб нам краще розуміти, що ж нам потрібно зробити, пропоную розглянути невеликий приклад. Почнемо з симптому.



Ми раптом розуміємо, що наш сайт дуже гальмує. У даному випадку висока час виконання скрипта саме на сервері, тобто ми зрозуміли, що у нас на фронті все норм, але при формуванні скрипта виникають якісь проблеми. Все, що нам потрібно, це профілювальник або slow логи – кому як подобається, у кого що є, хто що може налаштувати.

І така невелика штука – команда EXPLAIN. Надалі зрозумієте, чому.



Встромляємо профілювальник і бачимо ось таку штуку, що у нас 14 викликів MySQL_query виконуються за 1 секунду. Не дуже хороший показник.



Якщо ми простежимо трохи вище, то ми розуміємо, що якась функція з ім'ям getNewUserNotificationCNT виконується лише 640 мілісекунд і, швидше за все, з цих 640, вона 620 виконує запит. Тобто можна просто уявити і зрозуміти, що тут профілювальник відпрацював, і ця функція є нашим вузьким місцем. Все, що нам треба піти в цю функцію і подивитися, що вона за запит виконує.



Бачимо, що запит досить тривіальний – це вибір кількості нових, непрочитаних повідомлень. Насправді тут, можливо, вже відразу зрозуміло, у чому проблема, що з цим запитом не так, але щоб перевірити наші побоювання, ми робимо EXPLAIN цього SELECT'а:



Ми розуміємо, що цей SELECT, який хоче у користувача вибрати всі непрочитані повідомлення, пробігає по таблиці з мільйоном рядків. Погодьтеся, ситуація не дуже. Я хочу вибрати окремого юзера, у мене там, дай боже, якихось 10 повідомлень, а він мені по всьому мільйону їх відбирає. Плюс, COUNT (*) – досить навантажена операція. Коротше, щось тут не так. І ми бачимо з цього EXPLAIN, що на цих таблицях взагалі немає ніяких індексів, і в цьому плані він явно нічого не хоче використовувати.



Ми переходимо далі. Робимо простий ALTER TABLE, додаємо INDEX за USER_ID і за прочитаним. І що ми бачимо? Що у нас з мільйона записів кількість скоротилася до двох. Мені здається, чудова робота індексів з 1 млн. рядків пробегаться до двох.

Даний приклад показує, що ми встромили EXPLAIN, подивилися, що у нас надзвичайно величезна кількість рядків задіяно, і зрозуміли, що потрібно вжити якісь індекси.

З індексами теж треба бути обережними. І з EXPLAIN. Тому що якщо у вас EXPLAIN в одній версії відпрацьовує по-одному, то не факт, що він відпрацює в такий же базі, але в іншій версії, тому що EXPLAIN задіє і планувальники, і оптимізатори, і від версії до версії стратегії планування можуть змінюватися. Тому з ними теж треба бути обережним, і не факт, що індекс, який ви накотили на одній СУБД, він як би норм для іншої. Тут дуже тривіальний приклад, але в принципі його можна скиллить на різні більш складні запити і дивитися.

Якщо б у нас були ще якісь join'ни або ще які-небудь таблиці, EXPLAIN б показав тут ще кілька рядків і сказав вам, що він використовував би – where або індекс – і скільки рядків з кожної таблиці було б задіяно. Цікавий інструмент, який, мені здається, потрібно використовувати будь діагностиці запитів, він вам допоможе дуже багато всього пояснити.



В результаті у нас виконання запитів з 1 із скоротилася до 300 мс. Мені здається, хороший показник в цілому. Якщо говорити завантаженні сторінки, то до цієї операції з індексом однієї строчки коду вона виконувалася за 2,5 с, після цієї оптимізації – 700 мс. Тобто нічого собі така оптимізація, це без кеша.

Які проблеми можуть бути ще на нашому шляху? Тут зібраний якийсь топ логічних помилок програмістів:



Перше, що зустрічається – виконання запитів до баз даних у циклі. Це, коли у вас є якийсь селект з якоїсь таблиці, а потім всередині іншого циклу, коли він йде за рядками цього селекта, робиться ще один селект, в принципі, однотипний, який можна було б винести в перший, через join'и якісь добирається додаткова інформація. Для Бітрікс-розробників досить поширена проблема, тому що вони роблять свій get list, за get list'у форычем йдуть і ще якийсь get list забирають. Не дуже круто це позначається на продуктивності.

Друга проблема – це нескінченні цикли в коді, тобто якась логічна помилка, де у вас while повинен йти до якогось значення, п'ять разів відпрацювати, а він у вас просто ковбасить його нескінченну кількість разів. Це не дуже добре позначається на вашому додатку, і воно просто нічого не віддає в підсумку.

Також зустрічаються така помилка (з допомогою профилировщика вона дуже добре визначається) – непотрібні виклики функції. Це коли у вас замість того, щоб запхати значення якогось виконання функції в змінну, ця функція підставляється замість змінної, і вона викликається дике кількість разів, особливо при роботі з рядками. Такий момент, який в теорії може обламати вашу систему.



Що з цим робити? Тут, як мені здається, немає варіантів, тільки робити якийсь рефакторинг, виправляти помилки в коді і в наступному робити code review більш коректно.



Але в цьому світі є ще й інші процеси, які не є помилкою розробника, швидше є помилкою недооціненості вашого додатка. Коли ви думали, що цей процес не повинен зачіпати велика кількість ресурсів, а в результаті він просто ковбасить мільйони рядків – для вас це несподіванка. Є практики і для цих речей. Якщо у вас є якийсь процес, який не дуже вам критичний в real time виконувати, просто виносьте його в cron, планувальник, або робите якийсь покроковий скрипт, або вводите поняття черг, якщо треба якусь навантажену операцію зробити, і потім досить швидко віддати контент користувачеві.



Приклади таких операцій типові. Це або імпорт товарів, який явно не повинен проводитися на хітах, а повинен проводитися пізно вночі, коли нікого немає на сайті. Відправка пошти – теж досить показовий приклад, тому що якщо у вас великий потік відправки повідомлень, то це може навантажити ваш сервер, краще для таких речей робити черги. У нас були такі приклади, коли клієнту потрібно було формувати звітність в excel, і там дуже багато було рядків, але йому було потрібно, щоб по кліку здався звіт. Тут ми вводили покрокове створення або теж переводили в черзі, тобто він там натискав, йому говорили: «Скоро у тебе з'явиться звіт, зайди через 5 хвилин», і потім цей звіт формувався і віддавався. Такі методики застосовні і досить ефективні на будь-якій платформі.



Підходимо до того питання, що якщо у вас все добре, якщо код у вас вилизаний, якщо індекси в базі налаштовані, якщо у вас на фронті, взагалі, нічого критичного немає, і ви розумієте, що сайт повинен, у принципі, швидко працювати, а він все одно гальмує.



Тут нам на допомогу приходить горизонтальне масштабування, тому що будь-яка оптимізація рано чи пізно заходить у глухий кут – вона обмежена ресурсами вашого сервера так чи інакше. Тобто скільки б ви не вилизували ваш код, скільки б не розробляли різних підходів до формування індексів, так чи інакше у вас все колись упреться в ресурси сервера.

І тут у вас є два варіанти:

  1. ви апгрейдите ваш сервер – встромляєте ще один слот для оперативної пам'яті, робите диски швидше, або просто потужність процесора збільшуєте;
  2. або ви переходите до горизонтального масштабування, що в принципі вирішує дві задачі. Перша – це резервування, тобто ви завжди маєте якийсь резерв на випадок, якщо у вас відпав перший сервер, майстер, і у вас є певний баланс навантаження, тобто ваша навантаження концентрується вже не на одному сервері, а розподіляється на декілька, що позитивно позначається на швидкості вашого додатка.
Але тут важливо розуміти, що це все кльово, коли у вас код робочий. Якщо у вас помилки якісь в додатку, то його і 10 серверів можуть не врятувати. У вас просто буде на всі ці сервера якась навантаження скажена, і ви замість того, щоб зі 100 користувачів до 1 млн. збільшитися, зі 100 дійдете до 150. Тут важливо теж кордон цю розуміти.



Якщо підводити підсумок, то в принципі, не шукайте універсальних способів, тому що їх немає, кожна задача унікальна. Для будь-оптимізація – досить прямо тут і зараз увіткнути слот оперативної пам'яті і більше вам нічого не потрібно. На перший час це вам дасть відстрочку до моменту, поки ви будете виробляти рефакторинг, це не дуже дорого – зробити апгрейд вашого сервера, додатковий купити процесор, пам'ять.

В першу чергу визначте вузьке місце, тобто перед тим, як щось робити, краще провести діагностику, щоб точно знати, в якому місці у вас реально баг.

Використовуйте прості інструменти, тобто не потрібно вигадувати якісь мега рішень, є операційна система, є її інструменти, є різні профилировщики – використовуйте їх.

Купіть ОЗП – це теж оптимізація. Тут теж про те, що іноді питання стоїть не в оптимізації коду або програми, а просто в покупці додаткового слоти оперативної пам'яті, що вирішить левову частку ваших проблем.

І не бійтеся майбутнього горизонтального масштабування. Рано чи пізно, якщо ви плануєте, що у вас сайт буде жити, ви до цього так чи інакше прийдете, тому що навантаження буде зростати, будуть зростати якісь процеси на сайті, і вам доведеться все одно його горизонтально масштабувати.

Контакти
miheev@agima.ru
facebook

Ця доповідь — розшифровка одного з кращих виступів на навчальній конференції розробників високонавантажених систем HighLoad++ Junior. Зараз ми активно готуємо старшого брата HighLoad++ Junior — конференцію розробників високонавантажених систем HighLoad++ 2016 року — у цьому році HighLoad++ пройде в Сколково, 7 і 8 листопада.

Різниця між конференціями важлива — Junior — це не для дітей. Це про highload в умовах обмежених ресурсів (часових, грошових, кваліфікаційних). HighLoad для дизайн-студій — як витримати високу відвідуваність в реальних умовах, без розробки власних модулів до nginx :)

Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.