Миф об очень сложном Highload
Цель доклада - напомнить/рассказать слушателям о том, что мир изменился и "высокие нагрузки" уже не являются сложной задачей, стандартные инструменты на современном железе дают производительность приемлемую для практически любых задач.
Тезисы.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Запросы в MySQL, вычисление на Perl, работа Apache+nginx. Сравнение дефолтных результатов с требуемыми цифрами.
3. Размышления, почему в жизни встречается производительность хуже дефолтной. Примеры причин:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очень хитрых хитов, без highload хит отработать не успеет.
- Наш сервис — не конечный сайт клиента, а сервис для сервиса, требования к производительности выше обычных.
- Наш сервис тормозит из-за тормозного партнера, на партнера повлиять не можем, highload — костыль вокруг него.
- Фронтенд на любом проекте
6. Положительная программа.
- В 2016-ом году надо изучать и оптимизировать фронтенд, а не сервер. Учим JS и Android SDK вместо C и серверных алгоритмов.