ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам / Андрей Половов (Флант)
Vložit
- čas přidán 15. 01. 2018
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2017, HighLoad Junior
Тезисы:
junior.highload.ru/2017/abstra...
Наша специализация - запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада - структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.
...
Кеш - главная помощь при highload. Причем и Cache, и Cash :D
Грамотно чувак ходит вокруг трибуны, такого я еще не видел :)))))))
оператору орден, ну или минимум медаль вручить!
Похоже, что вы не выступали перед многочисленной аудиторией)
Программист в отпуске - беды ждать неоткуда )
😁 Кодеры - они такие, подкрадываются незаметно во время отпуска, когда ты их совсем не ждёшь.
@@-dubok- и подмердживают говно в мастер
Прям концентрированная мудрость базовых вещей. Но на которые реально забивают практически все.
Хороший доклад, спасибо! Конечно все эти грабли уже были опробованы на себе и до всех рекомендаций дошли своим опытом, но людям кто начинает можно позавидовать, если они начнут следовать хотя бы этим советам, цены им не будет.
2020 год на дворе. Эти грабли детский опыт, описанный в десятках книжек год так за 2005-2010.
@@user-ll2xw7tn6v ооо какой ты умный. А что надо есть, чтобы стать таким же умным как ты?
@@Merk462 ну вообще он прав ))) поэтому и докладчик говорит "это все очевидно". Просто Артему не надо было смотреть конкретно этот доклад :)
ОБычно те кто начинают не имеют времени использовать это всё в своих проектах - их уволят :), до таких проектов начинающих не допускают :).
мне вот было интерестно, спасибо
первые 2 случая... вызывают "сомнения"
1) транзакции... про блокировки не сказал ни слова...
6 мин млн. транзакций и по 1 транзакции... блокировка идёт на доли микро-секунд... и остальные запросы работают нормально
а Если использовать 1 огромную транзакцию на 32 сек - может случиться ситуация - ПОЛНОЙ блокировки какой-то таблицы... к которой все обращаются (обновление цен/номенклатуры и т.п.) и все запросы будут отваливаться по тайм-ауту....
а это совсем не айс и делать так... совсем нельзя!
2) про индексы... чем их больше - тем дольше идёт добавление и изменение данных и см. 1)...
ооочень часто индексы делают не там и не так... добавлять на каждый запрос - новый индекс... вообще не разу не правильно
А запросы к бд в цикле как будто не блокируют)
@@user-ql4xu5qu2u базу - нет, процесс на котором выполняется код - да
Первый два случая все верно автор сказал. Речь идет о записях в журнал транзакций для оптимизации IO. Данные не изменятся, пока не запишутся в журнал транзакций на диск. В первом примере мы этого особо не заметим, но во втором примере это видно хорошо. Речь тут совсем не о блокировках, а о IO диска. Без индексов чтение будет выполняться всей таблицы, а для больших таблиц это будет очень медленно.
@@youknowme9732 индексирование полезно, если макс. 20% запросов на обновлен и измен данных, а остальные на чтения данных,
На индексирование приходятся сложные операции, особенно b3
@@yanslow9083 индексирование в целом нужно для быстрого чтения. Если у вас 80% запросов изменения, а чтения 20%, но бизнес требует быстрого чтения, то всем плевать будет на то, что запись существенно замедлится
Про транзакцию улыбнуло
Спасибо за полезную лекцию. С меня лайк и подписка!
смотрю комментарии и радуюсь. спасибо за факт чек )
Дэплоят по FTP - я думал это уже никто неиспользует, тяжёлый случай.
Забавно. Был на хайлоаде в последний раз в 2007 году. За 13 лет ничего не изменилось.
Отличный доклад, но смотреть тяжко, ходить кругами постоянно это раздражает.
Периодически натыкаюсь на видосы с этого канала. Один вопрос, где они берут всех этих программистов в своих рассказах? То у них таблицы без индексов, то все запросы через *, то монолиты пишут так что нельзя переиспользовать собственный код.
По объявлениям.
Да ладно - каждые два из трёх такие.
В интернетах то все вумные и грамотные - ага.
А как посмотришь на проект развивающийся > 1 года - Г неподдерживаемое . Два из трёх такие же как и те кто их писал
Проблема с индексацией - самая распространённая. Бывает практически у всех программистов. Обычно возникает когда с таблицей начинают работать более сложными запросами, чем предполагалось изначально. Добавляют новых полей, делают выборки по нескольким полям и т.д. Проморгать индексацию в таком случае на стадии разработки очень просто, особенно если на тестовом стенде объём данных существенно меньше чем в продакшене.
Ну это же PHP - там кого только нет.
чувак очень поверхностно понимает в базах. Где, что сколько раз читается с диска и какова настоящая цена содержания индекса. И особенно классно, когда индекс, вроде бы есть, но база при запросе его не берет, потому что план запроса посчитался неоптимально.
Я предполагаю, что чувак сечет. Просто если вдаваться глубоко в детали - времени всей конференции не хватит
спасибо!
Очень крутой доклад то, что нужно. Андрей, спасибо большое!
Блин на дворе был 2018 год, какой апач?
жизненно
37:43 У меня тот-же вопрос возник. Причём тут Апач и рендеринг кода... Апач ведь только отдает код и заголовки, а рендерингом (в понимании генерации кода) занимается приложение.
скорее имелось ввиду что апач поднимает процесс (дочерний) который занимается рендерингом
аналогично) За себя скажу, апач не юзаю уже лет 5, симфони/лара на голом nginx - все гуд
А он в курсе на 2:40, что и так, все запросы выполняются в транзакциях, но неявно? По другому быть не может. А его кейворды это просто явное объявление транзакции (а не автоматическое) и возможность её откатить там где нужно.
Умозаключения про базы и транзакции огонь!
Это сарказм? Можно подробнее?
@@gijduvon6379 идея автора: хотите снизить io - используйте транзакции.(рука-лицо). То есть блин транзакции не ради транзакция а ради io.
Ага, а слово батч даже не прозвучало
Отличный доклад!
Это не HighLoad Junior, это *HighLoad Infant*
Не, за транзакции и за коммиты не выше baby
@@urhtang HighLoad for Dummies за 21 день
на слайде про масштабирование - связка nginx + apache + php - а разве apache не лишний в этом списке? nginx же вроде умеет fastcgi делать на несколько backend-ов?
+/- либо nginx + apache + php, либо nginx + php-fpm (отдельный сервер, слушающий на отдельном порту). Новичкам проще первый вариант (те же htaccess работают)
Много кто ставит апачи как мэйн веб-сервер, да еще и PHP прикручивают через apache-mod_php, и вот апачи на каждый чих (css, js, картинки и другие статические файлы) поднимает весь environment. Предлагается поставить nginx как reverse proxy, чтобы дела делал апач, а все остальное - нжиникс
> отдельный сервер, слушающий на отдельном порту
Это совсем не обязательно, можно на том же сервере
Я же о том и пишу, что в этой связке Apache вообще лишний. Единственный случай, когда он может быть целесообразен, как по мне, так это когда у вас 100500 маленьких проектов и надо все их гибко настроить на одном сервере.
Как по мне от абсолютно лишний, в apache нету concurrency нафига он нужен когда он в 1000 раз медленней чем nginx (пагуглите бенчмарки)? из-за mod-php? а чем mod_php лучше php-fpm'a?
он под наркотиками? по кругу ходит как волчок... остановите его кто ни будь )))
ааа все 5 минуте понял Я к этим ребятам обращаться не буду ))) На откатах живут бездари неграмотные на сцену выгнали
Че, в 21 году еще используются апач проект?
очень тяжело сконцентрироваться на восприятии информации - то громко, то тихо, то "аааааа", то ходит по кругу, то слайды забывает переключить. на 12-й минуте я сдался
Все шишки уже набиты..)
Отличный доклад
mysql_query (из картинки) уже сто лет как устарел.
но во всяких там wordpress это все еще проблема github.com/johnpbloch/wordpress-core/search?utf8=%E2%9C%93&q=mysql_query&type= хотя сам вордпресс это проблема одна большая
Какие ещё системы по вашему можно использовать кроме wp?
Что такое Бакл для бакапов
Аццкий огонь...
Первый пример про 4 дисковой операции не корректен. Оптимизация идёт за счёт экономии ресурсов на открытие и закрытие четырёх транзакций.
"The contents of the WAL buffers are written out to disk at every transaction commit" - из документации постгреса, выходит ей не стоит верить?
@@mihax56 именно об этом и говорит @Ник - когда 4 операции не в одной транзакции, мускул каждую операцию оборачивает в свою отдельную транзакцию, т.е. получаем 4 транзакции и 4 комита и, как Вы правильно указали, 4 раза будет выполнена запись в лог
@@alexeylevande2486 вы походу оба не догоняете, я переведу суть его высказываний на русский язык: "утверждение об экономии за счет И/О неверное, потому что на самом деле экономия идет за счет И/О". так что изначальный упор в видео именно на И/О и точно также в документации - более корректен, чем рассказывать про открытие/закрытие транзакций.
@@mihax56 где противоречие то? 4 операции вне транзакции = 4 транзакции, каждая имеет свой коммит, а значит 4 операции записи в лог согласно Вашей же цитате "The contents of the WAL buffers are written out to disk at every transaction commit". Одна транзакция с 4 операциями = 1 коммит и запись в транзакшен лог за один раз.
@@alexeylevande2486 все верно, зачем тогда с этим спорить и пытаться доказывать что "пример про 4 дисковой операции не корректен" и на самом деле то открытие/закрытие транзакций дорогое? я вот утверждаю что открыть/закрыть транзакцию - дешево, транзация открывается/закрывается на любой запрос к базе, даже если этот запрос в прцинипе не будет к данным обращаться. так что противоречие тут в том что ктото спутал телое с мягким.
хорошо, когда высытупление написали заранее, хреново когда это пытаются рассказать но без умения просто что-то повествовать
скорость на 1.5 и считаем "ААааээм"
8:27 рано или поздно поменяется порядок столбцов в таблице, и тогда вообще все поломается.
спасибо за доклад
Капитан очевидность
Отличный доклад, но докладчик совсем толком не ответил на вопросы слушателей.
forbes.ru уг. просто потому что пользователь заходит с мобилки, начинает читать новость, и затем она ска пропадает потому что рендерится. я бы таким не хвалился.
Запросы через звездочку - это же любая nosql разработка
mysql_query в 2018...
Кто же в крон ставит дёрганье сайта через хттп? Омфг
Я как-то делал с локалхоста на локалхост, как ни крутил - не получалось иначе
Вроде бы даже у WP это стандартное решение.
назрена мне менеджер очередей или таймаут? я хочу параллельно и быстро.
в параллель дpoчить один запрос на получение новостей с другого сайта?
Я вообще не пойму зачем апач? Объясните мне, я просто уже лет 7 пользуюсь nginx, а с апачем даже не сталкивался. Одно знаю что он прожорлив.
apache http server это:
1. php-fpm подобная ПО с фишкой перечитывания .htaccess условий
2. любимый http сервер шаред хостингов
3. любимый http сервер старых скриптов
4. любимый http сервер в xAMP наборах
и еще много привязанностей от легаси приложений
Для php Apache работает быстрее nginx это факт. Только из-за значительно медленной отдачи статики он в итоге проигрывает Nginx. Но на высоконагруженных проектах это уже не работает
@@AlekseyCounter на то конференция называется HighLoad. С другой стороны если посмотреть то кто делает низконагруженные проекты, мини сайтики и тд скорее всего это видео даже не заинтересует )))
@@AlekseyCounter Прикола ради сделайте хотя бы примитивный "Hello World!" и используя ab сравните на Apache (mod_php и потом php-fpm) и Nginx+php-fpm. PHP-FPM настройте через сокет + opcache чтоб хернёй долго не страдать, сравните на 1 процессе вэб-сервера, потом на 4х и на 8. Ну и графики CPU/MEM/IO не забудьте. Результаты вас удивят и в сторону Апача вы больше никогда смотреть не будете.
@@AlekseyCounter не работает mod_php быстрее, чем php-fpm, это примерно одинаковые по скорости вещи. Зато апач в пару сотен раз медленнее отдает статику, чем nginx.
Конференция по высоконагруженному не могут номальную звукопередачу сделать ^_^
Да нафиг нужен вообще этот apache?
ну, во первых, доклад от 2017 года, во вторых, исторически сложилось, в-третьих, механизмы реврайтов апача, кмк, всё ещё мощнее аналогов в nginx.
+ есть куча интегрированных модулей от разные систем, которые работают нативно из коробки и являются встроенными.
одно и тоже как сказать зачем вам php используйте python. lol
@@altRU1st php быстрее питона, лол
Может у него особая база, но оборачивать селект в транзакцию не нужно .
Там update были, он скорее всего по них имел в виду.
Как лихо приравнены термины би и mysql. И навязано впечатление, что все бд полностью одинаковы в работе, а транзакции исключительно повышают производительность, как будто нет ни журналов, ни блокировок. Дальше простите, выключил.
4 записи в одну дисковую операцию если завернуть в транзакцию? Что курил автор?
Чай)
Цикорий))
заворачивая группы запросов в транзакцию, действительно можно получить более высокий IOPS, то есть большее количество записей в секунду. По крайней мере до тех пор, пока не случаются rollback`и.
все верно он сказал, транзакции обрабатываются пакетно, данные которые были изменены в ходе транзакции будут изменены за 1 доступ к жесткому диску, даже если там был с дейсяток апдейтов, это в идеале, в реальности такого прироста не получим по многим причинам, но как минимум в раза 2 можно снизить нагрузку IOPS за счет обертки групп запросов в транзакции
@@mikhaillucky8130 в мускуле с пыхом и автокоммитом прирост может быть и больше, ибо ты делаешь весь комплект запросов и коммитишь их разом, а не выполняешь коммит после каждого чиха
минус тут только в том, что надо помнить об атомарности транзакций и контролировать стейты коммитов (ну и ролбеки не проёбывать)
gj агхитектор проэктов. джун джуном
10:00
ведущий очень сильно нервничает: 2 секунды говорит 1 секунду думает, ходит туда-сюда. Это все из-за того что HLj? или на HL такой же уровень докладов?)
Это конечно минус ведущему, но почему ивент под раздачу попал?
Охота экшона, а количество и качество полезной информации не играет роли? Смотрите порнуху или экшн-боевики.
жмёте "Зубчатый колесо" -> "Скорость" -> выбираете 1.25, или 1.5, получаете "акшон" и отсутствие таких затяжных пауз. )
он вообще больше похож на пациента псибольницы. Что "программисты", что "администраторы" имеют в его лице один и тот же собирательный образ
Ну не обладает человек профессионально навыками нлп и не является сам по себе оратором. Кто из диванных экспертов смог бы выйти на сцену и не мыча, не забывая деталей, не волнуясь все по полочкам разложить и рассказать?
Ну иди сам выступи, если ты не был ни на одном HL и вообще не знаешь о чем речь, то рассказать вряд ли сможешь о чем либо. А выступающему спасибо, все когда-то начинают.
Что за привычка у людей чавкать, как вы это делаете, по ушам бьет, ужас просто
13:39 Лол, зачем так делать? чем php-cli не угодил?
вы слушать умеете? это пример реализации у клиента. lol
apache + nginx это еще что за бред? статику на отдельный сервер выкиньте и там ставьте свой nginx, а если деньги есть то картинки, архивы и пр. файлы выкиньте на s3.
Я вот не помню как на моей старой работе было, по-моему там еще и весь фронтэнд на emberjs + css гзипался и выкидывался на s3, но это не точно
доклад для уровня junior-ов и качество аналогичное...
какую хуйню вы несёте ...
если много денег, то выкидывать не на говнос3 надо, а в cdn, которая и ресурсы правильно распледелит, и скорит загрузку и прочее.
нахуй вам s3 storage?
а nginx + apache - вполне рабочая схема, позволяющая ускорить работоспособность системы без переписывания кода.
овердохуя различных движков cms завязаны на реврайты для апача, и тебе он нужен как воздух, не переписывать же весь проект на лету в момент создания нагрузки при отдаче статики.
nginx в овердохуя быстрее статику будет отдавать, проксируя запросы для пыха на апач, а тот уж пусть на них отвечает с учётом всего энвайрмента, для которого он запускается ...
А че мешает поставить nginx перед php-fpm и гзипать там все, что влезет? Нах тратить деньги на какой-то s3
Просто трэш..
флант такой флант) для начала свою производительность поднимите) ну и советы конечно забавные) уровня пхп джуна)
юзайте индексы и мульти инсерты)
это джун конфа... для джунов советы норм. во всяком случае если бы все им следовали было бы хорошо... а так да, все о них конечно знают... ;) тем более это админы им надо, как правило, быстро решить проблему, когда обратился клиент и его сайт уже лежит и "растекаться по древу" нет времени.
Уже начиная с транзакций можно не смотреть. Человек просто не знает, как это работает на самом деле.
Какая глупость!
tldr; Ну слезайте уже c LAMP.
Офигенный докладчик)
19:23 SQLite это экзотическая ДБ? Ха-ха.
Подобного бреда в 2020 году уже не должно быть от мамкиных дба которых допустили до проектирования систем. Заворачивать в транзакции импорт данных? А когда у тебя по тысячи записей из 10000 в 10 запросов будут заливаться и на 9ом запросе всё это наётся из-за ошибки в одном из 10 продуктов, откатится 1000 записей (или все 10000?!) и потом ищи-свищи где что? Или на первом продукте всё упадёт и остальные просто не импортнутся. Класс. "Надёжно" и "удобно" поддерживать. Записывать нужно по одной штуке такие вещи. Ты вообще знаешь зачем нужны транзакции? Импорт данных в 99% не может быть транзакционным, т.к. это не платежи и можно всё просто напросто повторить. А для увеличения производительности не используй реляционную базу там, где нужна noSql и масштабируй. Транзакции не позволят тебе ничерта масштабировать. Или мы ещё распределённые транзакции введём? ОМГ. Дисковые операции посчитал.... пздц. "Открой транзакцию и заблокируй к чертям всю систему пока импортятся продукты!". Ведь это так важно их за 0.06 а не за 6 секунд импортнуть. Ведь это каждую минуту миллиарды продуктов импортируются, да? Это всё вообще не вопрос транзакций и баз данных. Это вопрос архитектуры приложения. При любом импорте нормальная система должна сожрать всё что ок и выплюнуть разницу которая не подошла. А не откатить всё к херам.
Более того, системы, подразумевающие частые Create\update операции должны проектироваться вообще иначе, чем мамкингы сайты со статьями, где надо обновить десяток полей "если чё". Короче, типичный дба из совковой компании, которая положила болт на современные подходы, не учла опыт коллег западных и строит свой деревянный самолёт.
FaunaDB поддерживает распределенные транзакции
Тут всё проще. Это сисадмин. Его постоянно говнопрогеры пинают что всё тормозит и говорят что серваки говно, он ресурсы крыса зажал. А потом когда находят что в коде ошибка, у них просто пукан рвёт и они навсегда решают что надо только так делать и никак иначе, независимо от факторов)
Преставляю как его бомбит и как он орёт))
А причем тут devops? Все кейсы - онпремисные bare-metal серваки, ни клаудов, ни devops практик. Просто тонкая настройках вебсерверов - это не devops.
очень часто говорят про devops лишь бы сказать про devops, а по сути те же яйца только сбоку, суть devops-a: "мойте руки перед едой" ))) это как в камеди про табличку на дверь... lol ))))
Доклад неплохой. Но говорить, что nginx в 2018м - это просто реверсивный прокси - это просто неграмотность, имхо. openresty.org/en/
о боже, да этот lua никому в очко не всрался
А смысл смешивать нгинкс с луа?
Если уж приспичило на экзотические технологии то не проще ли сразу на rust, на c++ написать свое?
За то развитие для мозга.
"не позаботились хотя бы о капистране" чтоооо ? о чем речь, какой такой капистран?
Capistrano имеется ввиду
ходит и плямкает. ужас.
Слушать ааааа челика аааа очень аааааа сложно ааааа особенно аааа когда аааа кровь ааааа из ушей аааааа уже аааа идёт ааа
Ни какие это не кейсы особенно по сессиям, туфта полная берете NVME 970PRO на 1ТБ даже с посещаемостью 1 млн человек проблем не будет
php такой php
Зачем он ходит кругами?? Ужасно бесит!!
пункт номер 0: не использовать пэхапэ для высоких нагрузок
почему?
@@ivangorsky7537 потому что это язык и фремворк для домашних страничек. Был есть и будет. И в чем проблема? В том что он не заточен , не спроектирован под нагрузки, интерпретируемый, медленный, плохо работает с памятью, потоками и т.д.ю
@@user-ll2xw7tn6v PHP медленный? С чего ты взял? Очень шустрый язык. Причём не только в плане работы, но и в плане разработки, что очень важно для HL проектов.
@@ivangorsky7537 Это все хорошо, но код ведь выглядит как говно (я про любой php код)
@@MrRoperd когда-нибудь научишься писать более понятный код. Не бросай обучение)
если пишешь на ПЫХЕ в 2к18-19 то ты сверхразум.
а на чем надо писать?
@@HeLSpawn1 на чём жизнь прикажет. На .net core приятно работается и вакансий полно.
зачем пыха, апач?