ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам / Андрей Половов (Флант)

Рет қаралды 107,338

6 жыл бұрын

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2017, HighLoad Junior
Тезисы:
junior.highload.ru/2017/abstra...
Наша специализация - запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада - структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.
...

Пікірлер: 177

@socketam4524 Жыл бұрын

Кеш - главная помощь при highload. Причем и Cache, и Cash :D

@Anatoliy_- 3 жыл бұрын

Программист в отпуске - беды ждать неоткуда )

@-dubok- 7 ай бұрын

😁 Кодеры - они такие, подкрадываются незаметно во время отпуска, когда ты их совсем не ждёшь.

@vr29645 Ай бұрын

@@-dubok- и подмердживают говно в мастер

@romanfomin5653 4 жыл бұрын

Грамотно чувак ходит вокруг трибуны, такого я еще не видел :)))))))

@mmaslennikov 2 жыл бұрын

оператору орден, ну или минимум медаль вручить!

@yuriykovalevsky8871 Жыл бұрын

Похоже, что вы не выступали перед многочисленной аудиторией)

@gleboleynik7844 2 жыл бұрын

Прям концентрированная мудрость базовых вещей. Но на которые реально забивают практически все.

@yuriik.6711 3 жыл бұрын

мне вот было интерестно, спасибо

@altRU1st 4 жыл бұрын

Хороший доклад, спасибо! Конечно все эти грабли уже были опробованы на себе и до всех рекомендаций дошли своим опытом, но людям кто начинает можно позавидовать, если они начнут следовать хотя бы этим советам, цены им не будет.

@user-ll2xw7tn6v 3 жыл бұрын

2020 год на дворе. Эти грабли детский опыт, описанный в десятках книжек год так за 2005-2010.

@Merk462 3 жыл бұрын

@@user-ll2xw7tn6v ооо какой ты умный. А что надо есть, чтобы стать таким же умным как ты?

@dmitriypronichev7048 3 жыл бұрын

@@Merk462 ну вообще он прав ))) поэтому и докладчик говорит "это все очевидно". Просто Артему не надо было смотреть конкретно этот доклад :)

@user-dn8yk9wq7c Жыл бұрын

ОБычно те кто начинают не имеют времени использовать это всё в своих проектах - их уволят :), до таких проектов начинающих не допускают :).

@urhtang 4 жыл бұрын

Про транзакцию улыбнуло

@ProgTime 11 ай бұрын

Спасибо за полезную лекцию. С меня лайк и подписка!

@adambright5416 2 жыл бұрын

смотрю комментарии и радуюсь. спасибо за факт чек )

@user-pl9hn7mg1q 4 жыл бұрын

первые 2 случая... вызывают "сомнения" 1) транзакции... про блокировки не сказал ни слова... 6 мин млн. транзакций и по 1 транзакции... блокировка идёт на доли микро-секунд... и остальные запросы работают нормально а Если использовать 1 огромную транзакцию на 32 сек - может случиться ситуация - ПОЛНОЙ блокировки какой-то таблицы... к которой все обращаются (обновление цен/номенклатуры и т.п.) и все запросы будут отваливаться по тайм-ауту.... а это совсем не айс и делать так... совсем нельзя! 2) про индексы... чем их больше - тем дольше идёт добавление и изменение данных и см. 1)... ооочень часто индексы делают не там и не так... добавлять на каждый запрос - новый индекс... вообще не разу не правильно

@user-ql4xu5qu2u 3 жыл бұрын

А запросы к бд в цикле как будто не блокируют)

@artogoroduser 3 жыл бұрын

@@user-ql4xu5qu2u базу - нет, процесс на котором выполняется код - да

@youknowme9732 Жыл бұрын

Первый два случая все верно автор сказал. Речь идет о записях в журнал транзакций для оптимизации IO. Данные не изменятся, пока не запишутся в журнал транзакций на диск. В первом примере мы этого особо не заметим, но во втором примере это видно хорошо. Речь тут совсем не о блокировках, а о IO диска. Без индексов чтение будет выполняться всей таблицы, а для больших таблиц это будет очень медленно.

@yanslow9083 Жыл бұрын

@@youknowme9732 индексирование полезно, если макс. 20% запросов на обновлен и измен данных, а остальные на чтения данных, На индексирование приходятся сложные операции, особенно b3

@vladislavstepanov7591 8 ай бұрын

@@yanslow9083 индексирование в целом нужно для быстрого чтения. Если у вас 80% запросов изменения, а чтения 20%, но бизнес требует быстрого чтения, то всем плевать будет на то, что запись существенно замедлится

@user-dn8yk9wq7c Жыл бұрын

Дэплоят по FTP - я думал это уже никто неиспользует, тяжёлый случай.

@pavelpavel7938 4 жыл бұрын

Периодически натыкаюсь на видосы с этого канала. Один вопрос, где они берут всех этих программистов в своих рассказах? То у них таблицы без индексов, то все запросы через *, то монолиты пишут так что нельзя переиспользовать собственный код.

@pyroman010 4 жыл бұрын

По объявлениям.

@unique00id 4 жыл бұрын

Да ладно - каждые два из трёх такие. В интернетах то все вумные и грамотные - ага. А как посмотришь на проект развивающийся > 1 года - Г неподдерживаемое . Два из трёх такие же как и те кто их писал

@mootal2202 2 жыл бұрын

Проблема с индексацией - самая распространённая. Бывает практически у всех программистов. Обычно возникает когда с таблицей начинают работать более сложными запросами, чем предполагалось изначально. Добавляют новых полей, делают выборки по нескольким полям и т.д. Проморгать индексацию в таком случае на стадии разработки очень просто, особенно если на тестовом стенде объём данных существенно меньше чем в продакшене.

@-dubok- 7 ай бұрын

Ну это же PHP - там кого только нет.

@damir8847 6 жыл бұрын

Очень крутой доклад то, что нужно. Андрей, спасибо большое!

@alexgeiman7206 3 жыл бұрын

Забавно. Был на хайлоаде в последний раз в 2007 году. За 13 лет ничего не изменилось.

@MakarMS 4 ай бұрын

А он в курсе на 2:40, что и так, все запросы выполняются в транзакциях, но неявно? По другому быть не может. А его кейворды это просто явное объявление транзакции (а не автоматическое) и возможность её откатить там где нужно.

@kl45gp Жыл бұрын

спасибо!

@ruslanmustaev8170 4 жыл бұрын

Отличный доклад, но смотреть тяжко, ходить кругами постоянно это раздражает.

@alexeygorbachev5092 6 жыл бұрын

жизненно

@dizelvinable 4 жыл бұрын

Отличный доклад!

@Merk462 3 жыл бұрын

37:43 У меня тот-же вопрос возник. Причём тут Апач и рендеринг кода... Апач ведь только отдает код и заголовки, а рендерингом (в понимании генерации кода) занимается приложение.

@artogoroduser 3 жыл бұрын

скорее имелось ввиду что апач поднимает процесс (дочерний) который занимается рендерингом

@user-bb4mm2py1e 3 жыл бұрын

аналогично) За себя скажу, апач не юзаю уже лет 5, симфони/лара на голом nginx - все гуд

@tsolodov 4 жыл бұрын

Умозаключения про базы и транзакции огонь!

@gijduvon6379 3 жыл бұрын

Это сарказм? Можно подробнее?

@tsolodov 3 жыл бұрын

@@gijduvon6379 идея автора: хотите снизить io - используйте транзакции.(рука-лицо). То есть блин транзакции не ради транзакция а ради io.

@user-nl1fi7nx2b Жыл бұрын

Ага, а слово батч даже не прозвучало

@tiptopkamerton 6 жыл бұрын

на слайде про масштабирование - связка nginx + apache + php - а разве apache не лишний в этом списке? nginx же вроде умеет fastcgi делать на несколько backend-ов?

@gb12335 6 жыл бұрын

+/- либо nginx + apache + php, либо nginx + php-fpm (отдельный сервер, слушающий на отдельном порту). Новичкам проще первый вариант (те же htaccess работают)

@1Cry1987 6 жыл бұрын

Много кто ставит апачи как мэйн веб-сервер, да еще и PHP прикручивают через apache-mod_php, и вот апачи на каждый чих (css, js, картинки и другие статические файлы) поднимает весь environment. Предлагается поставить nginx как reverse proxy, чтобы дела делал апач, а все остальное - нжиникс

@tiptopkamerton 6 жыл бұрын

> отдельный сервер, слушающий на отдельном порту Это совсем не обязательно, можно на том же сервере

@tiptopkamerton 6 жыл бұрын

Я же о том и пишу, что в этой связке Apache вообще лишний. Единственный случай, когда он может быть целесообразен, как по мне, так это когда у вас 100500 маленьких проектов и надо все их гибко настроить на одном сервере.

@Holms 6 жыл бұрын

Как по мне от абсолютно лишний, в apache нету concurrency нафига он нужен когда он в 1000 раз медленней чем nginx (пагуглите бенчмарки)? из-за mod-php? а чем mod_php лучше php-fpm'a?

@milovidov42 4 жыл бұрын

Блин на дворе был 2018 год, какой апач?

@AlekseyCounter 5 жыл бұрын

Это не HighLoad Junior, это *HighLoad Infant*

@urhtang 4 жыл бұрын

Не, за транзакции и за коммиты не выше baby

@pavelpavel7938 4 жыл бұрын

@@urhtang HighLoad for Dummies за 21 день

@sergeywhite8897 5 жыл бұрын

Отличный доклад

@romy4romy4 20 күн бұрын

Запросы через звездочку - это же любая nosql разработка

@user-st3qw7kw4h 7 ай бұрын

Отличный доклад, но докладчик совсем толком не ответил на вопросы слушателей.

@ShowMeYourCoconut 4 жыл бұрын

чувак очень поверхностно понимает в базах. Где, что сколько раз читается с диска и какова настоящая цена содержания индекса. И особенно классно, когда индекс, вроде бы есть, но база при запросе его не берет, потому что план запроса посчитался неоптимально.

@dzmitryshalukhov1681 2 жыл бұрын

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

@sergeyk1982 4 жыл бұрын

Аццкий огонь...

@websofter 2 жыл бұрын

Че, в 21 году еще используются апач проект?

@artem4329 6 жыл бұрын

mysql_query (из картинки) уже сто лет как устарел.

@Holms 6 жыл бұрын

но во всяких там wordpress это все еще проблема github.com/johnpbloch/wordpress-core/search?utf8=%E2%9C%93&q=mysql_query&type= хотя сам вордпресс это проблема одна большая

@whtmg 3 жыл бұрын

Какие ещё системы по вашему можно использовать кроме wp?

@667077 5 жыл бұрын

Все шишки уже набиты..)

@d33pF41L 2 жыл бұрын

скорость на 1.5 и считаем "ААааээм"

@maliciousfree 5 жыл бұрын

он под наркотиками? по кругу ходит как волчок... остановите его кто ни будь ))) ааа все 5 минуте понял Я к этим ребятам обращаться не буду ))) На откатах живут бездари неграмотные на сцену выгнали

@kostyan1983 2 жыл бұрын

Что такое Бакл для бакапов

@user-bb5xw8bd8w 2 жыл бұрын

Капитан очевидность

@SbWereWolf 6 жыл бұрын

спасибо за доклад

@nsname 5 жыл бұрын

Первый пример про 4 дисковой операции не корректен. Оптимизация идёт за счёт экономии ресурсов на открытие и закрытие четырёх транзакций.

@mihax56 5 жыл бұрын

"The contents of the WAL buffers are written out to disk at every transaction commit" - из документации постгреса, выходит ей не стоит верить?

@alexeylevande2486 4 жыл бұрын

@@mihax56 именно об этом и говорит @Ник - когда 4 операции не в одной транзакции, мускул каждую операцию оборачивает в свою отдельную транзакцию, т.е. получаем 4 транзакции и 4 комита и, как Вы правильно указали, 4 раза будет выполнена запись в лог

@mihax56 4 жыл бұрын

@@alexeylevande2486 вы походу оба не догоняете, я переведу суть его высказываний на русский язык: "утверждение об экономии за счет И/О неверное, потому что на самом деле экономия идет за счет И/О". так что изначальный упор в видео именно на И/О и точно также в документации - более корректен, чем рассказывать про открытие/закрытие транзакций.

@alexeylevande2486 4 жыл бұрын

@@mihax56 где противоречие то? 4 операции вне транзакции = 4 транзакции, каждая имеет свой коммит, а значит 4 операции записи в лог согласно Вашей же цитате "The contents of the WAL buffers are written out to disk at every transaction commit". Одна транзакция с 4 операциями = 1 коммит и запись в транзакшен лог за один раз.

@mihax56 4 жыл бұрын

@@alexeylevande2486 все верно, зачем тогда с этим спорить и пытаться доказывать что "пример про 4 дисковой операции не корректен" и на самом деле то открытие/закрытие транзакций дорогое? я вот утверждаю что открыть/закрыть транзакцию - дешево, транзация открывается/закрывается на любой запрос к базе, даже если этот запрос в прцинипе не будет к данным обращаться. так что противоречие тут в том что ктото спутал телое с мягким.

@user-ee1xf7qm5d 2 жыл бұрын

очень тяжело сконцентрироваться на восприятии информации - то громко, то тихо, то "аааааа", то ходит по кругу, то слайды забывает переключить. на 12-й минуте я сдался

@soam8175 6 жыл бұрын

хорошо, когда высытупление написали заранее, хреново когда это пытаются рассказать но без умения просто что-то повествовать

@Elfcheg 11 ай бұрын

8:27 рано или поздно поменяется порядок столбцов в таблице, и тогда вообще все поломается.

@delifeful 4 жыл бұрын

forbes.ru уг. просто потому что пользователь заходит с мобилки, начинает читать новость, и затем она ска пропадает потому что рендерится. я бы таким не хвалился.

@user-pf7yh2lj7v 11 ай бұрын

Конференция по высоконагруженному не могут номальную звукопередачу сделать ^_^

@user-lz4hz2yy8j 4 жыл бұрын

mysql_query в 2018...

@bumm1077 4 жыл бұрын

назрена мне менеджер очередей или таймаут? я хочу параллельно и быстро.

@altRU1st 4 жыл бұрын

в параллель дpoчить один запрос на получение новостей с другого сайта?

@nikolay6700 4 жыл бұрын

Может у него особая база, но оборачивать селект в транзакцию не нужно .

@SntrTube 3 жыл бұрын

Там update были, он скорее всего по них имел в виду.

@user-cr9un3cj2x 5 жыл бұрын

Я вообще не пойму зачем апач? Объясните мне, я просто уже лет 7 пользуюсь nginx, а с апачем даже не сталкивался. Одно знаю что он прожорлив.

@AnarJafarov 5 жыл бұрын

apache http server это: 1. php-fpm подобная ПО с фишкой перечитывания .htaccess условий 2. любимый http сервер шаред хостингов 3. любимый http сервер старых скриптов 4. любимый http сервер в xAMP наборах и еще много привязанностей от легаси приложений

@AlekseyCounter 5 жыл бұрын

Для php Apache работает быстрее nginx это факт. Только из-за значительно медленной отдачи статики он в итоге проигрывает Nginx. Но на высоконагруженных проектах это уже не работает

@AnarJafarov 5 жыл бұрын

@@AlekseyCounter на то конференция называется HighLoad. С другой стороны если посмотреть то кто делает низконагруженные проекты, мини сайтики и тд скорее всего это видео даже не заинтересует )))

@mrClinFromDonetsk 4 жыл бұрын

@@AlekseyCounter Прикола ради сделайте хотя бы примитивный "Hello World!" и используя ab сравните на Apache (mod_php и потом php-fpm) и Nginx+php-fpm. PHP-FPM настройте через сокет + opcache чтоб хернёй долго не страдать, сравните на 1 процессе вэб-сервера, потом на 4х и на 8. Ну и графики CPU/MEM/IO не забудьте. Результаты вас удивят и в сторону Апача вы больше никогда смотреть не будете.

@im8730 4 жыл бұрын

@@AlekseyCounter не работает mod_php быстрее, чем php-fpm, это примерно одинаковые по скорости вещи. Зато апач в пару сотен раз медленнее отдает статику, чем nginx.

@EdwVee 3 жыл бұрын

Кто же в крон ставит дёрганье сайта через хттп? Омфг

@user-ny1jm3sf7t 3 жыл бұрын

Я как-то делал с локалхоста на локалхост, как ни крутил - не получалось иначе

@mootal2202 2 жыл бұрын

Вроде бы даже у WP это стандартное решение.

@user-gj6vo3xm5b 3 жыл бұрын

Офигенный докладчик)

@underscoreunderscore8312 5 жыл бұрын

4 записи в одну дисковую операцию если завернуть в транзакцию? Что курил автор?

@AnarJafarov 5 жыл бұрын

Чай)

@maxb3000 5 жыл бұрын

Цикорий))

@bopodaa 5 жыл бұрын

заворачивая группы запросов в транзакцию, действительно можно получить более высокий IOPS, то есть большее количество записей в секунду. По крайней мере до тех пор, пока не случаются rollback`и.

@mikhaillucky8130 4 жыл бұрын

все верно он сказал, транзакции обрабатываются пакетно, данные которые были изменены в ходе транзакции будут изменены за 1 доступ к жесткому диску, даже если там был с дейсяток апдейтов, это в идеале, в реальности такого прироста не получим по многим причинам, но как минимум в раза 2 можно снизить нагрузку IOPS за счет обертки групп запросов в транзакции

@zerocool4eg 4 жыл бұрын

@@mikhaillucky8130 в мускуле с пыхом и автокоммитом прирост может быть и больше, ибо ты делаешь весь комплект запросов и коммитишь их разом, а не выполняешь коммит после каждого чиха минус тут только в том, что надо помнить об атомарности транзакций и контролировать стейты коммитов (ну и ролбеки не проёбывать)

@NikK0lay 5 жыл бұрын

Да нафиг нужен вообще этот apache?

@zerocool4eg 4 жыл бұрын

ну, во первых, доклад от 2017 года, во вторых, исторически сложилось, в-третьих, механизмы реврайтов апача, кмк, всё ещё мощнее аналогов в nginx. + есть куча интегрированных модулей от разные систем, которые работают нативно из коробки и являются встроенными.

@altRU1st 4 жыл бұрын

одно и тоже как сказать зачем вам php используйте python. lol

@im8730 4 жыл бұрын

@@altRU1st php быстрее питона, лол

@illiailliaa8846 5 жыл бұрын

gj агхитектор проэктов. джун джуном

@michealmltefive5510 3 жыл бұрын

10:00

@mazxification 4 жыл бұрын

флант такой флант) для начала свою производительность поднимите) ну и советы конечно забавные) уровня пхп джуна) юзайте индексы и мульти инсерты)

@altRU1st 4 жыл бұрын

это джун конфа... для джунов советы норм. во всяком случае если бы все им следовали было бы хорошо... а так да, все о них конечно знают... ;) тем более это админы им надо, как правило, быстро решить проблему, когда обратился клиент и его сайт уже лежит и "растекаться по древу" нет времени.

@zvezda9light Жыл бұрын

Как лихо приравнены термины би и mysql. И навязано впечатление, что все бд полностью одинаковы в работе, а транзакции исключительно повышают производительность, как будто нет ни журналов, ни блокировок. Дальше простите, выключил.

@pavelfedoruk 2 жыл бұрын

Просто трэш..

@MrKshart 5 жыл бұрын

13:39 Лол, зачем так делать? чем php-cli не угодил?

@altRU1st 4 жыл бұрын

вы слушать умеете? это пример реализации у клиента. lol

@MsHorbjorn 3 жыл бұрын

Что за привычка у людей чавкать, как вы это делаете, по ушам бьет, ужас просто

@f00b4r123 Жыл бұрын

19:23 SQLite это экзотическая ДБ? Ха-ха.

@mikhailkalinin6484 6 жыл бұрын

ведущий очень сильно нервничает: 2 секунды говорит 1 секунду думает, ходит туда-сюда. Это все из-за того что HLj? или на HL такой же уровень докладов?)

@1Cry1987 6 жыл бұрын

Это конечно минус ведущему, но почему ивент под раздачу попал? Охота экшона, а количество и качество полезной информации не играет роли? Смотрите порнуху или экшн-боевики.

@vladimirvlasov4773 6 жыл бұрын

жмёте "Зубчатый колесо" -> "Скорость" -> выбираете 1.25, или 1.5, получаете "акшон" и отсутствие таких затяжных пауз. )

@leksanders8908 5 жыл бұрын

он вообще больше похож на пациента псибольницы. Что "программисты", что "администраторы" имеют в его лице один и тот же собирательный образ

@lddnsk 4 жыл бұрын

Ну не обладает человек профессионально навыками нлп и не является сам по себе оратором. Кто из диванных экспертов смог бы выйти на сцену и не мыча, не забывая деталей, не волнуясь все по полочкам разложить и рассказать?

@altRU1st 4 жыл бұрын

Ну иди сам выступи, если ты не был ни на одном HL и вообще не знаешь о чем речь, то рассказать вряд ли сможешь о чем либо. А выступающему спасибо, все когда-то начинают.

@user-ll2xw7tn6v 3 жыл бұрын

Подобного бреда в 2020 году уже не должно быть от мамкиных дба которых допустили до проектирования систем. Заворачивать в транзакции импорт данных? А когда у тебя по тысячи записей из 10000 в 10 запросов будут заливаться и на 9ом запросе всё это наётся из-за ошибки в одном из 10 продуктов, откатится 1000 записей (или все 10000?!) и потом ищи-свищи где что? Или на первом продукте всё упадёт и остальные просто не импортнутся. Класс. "Надёжно" и "удобно" поддерживать. Записывать нужно по одной штуке такие вещи. Ты вообще знаешь зачем нужны транзакции? Импорт данных в 99% не может быть транзакционным, т.к. это не платежи и можно всё просто напросто повторить. А для увеличения производительности не используй реляционную базу там, где нужна noSql и масштабируй. Транзакции не позволят тебе ничерта масштабировать. Или мы ещё распределённые транзакции введём? ОМГ. Дисковые операции посчитал.... пздц. "Открой транзакцию и заблокируй к чертям всю систему пока импортятся продукты!". Ведь это так важно их за 0.06 а не за 6 секунд импортнуть. Ведь это каждую минуту миллиарды продуктов импортируются, да? Это всё вообще не вопрос транзакций и баз данных. Это вопрос архитектуры приложения. При любом импорте нормальная система должна сожрать всё что ок и выплюнуть разницу которая не подошла. А не откатить всё к херам. Более того, системы, подразумевающие частые Create\update операции должны проектироваться вообще иначе, чем мамкингы сайты со статьями, где надо обновить десяток полей "если чё". Короче, типичный дба из совковой компании, которая положила болт на современные подходы, не учла опыт коллег западных и строит свой деревянный самолёт.

@artogoroduser 3 жыл бұрын

FaunaDB поддерживает распределенные транзакции

@bromox3761 2 жыл бұрын

Тут всё проще. Это сисадмин. Его постоянно говнопрогеры пинают что всё тормозит и говорят что серваки говно, он ресурсы крыса зажал. А потом когда находят что в коде ошибка, у них просто пукан рвёт и они навсегда решают что надо только так делать и никак иначе, независимо от факторов) Преставляю как его бомбит и как он орёт))

@igorsk1133 5 жыл бұрын

apache + nginx это еще что за бред? статику на отдельный сервер выкиньте и там ставьте свой nginx, а если деньги есть то картинки, архивы и пр. файлы выкиньте на s3. Я вот не помню как на моей старой работе было, по-моему там еще и весь фронтэнд на emberjs + css гзипался и выкидывался на s3, но это не точно

@AnarJafarov 5 жыл бұрын

доклад для уровня junior-ов и качество аналогичное...

@zerocool4eg 4 жыл бұрын

какую хуйню вы несёте ... если много денег, то выкидывать не на говнос3 надо, а в cdn, которая и ресурсы правильно распледелит, и скорит загрузку и прочее. нахуй вам s3 storage? а nginx + apache - вполне рабочая схема, позволяющая ускорить работоспособность системы без переписывания кода. овердохуя различных движков cms завязаны на реврайты для апача, и тебе он нужен как воздух, не переписывать же весь проект на лету в момент создания нагрузки при отдаче статики. nginx в овердохуя быстрее статику будет отдавать, проксируя запросы для пыха на апач, а тот уж пусть на них отвечает с учётом всего энвайрмента, для которого он запускается ...

@im8730 4 жыл бұрын

А че мешает поставить nginx перед php-fpm и гзипать там все, что влезет? Нах тратить деньги на какой-то s3

@dzen1234 5 жыл бұрын

Доклад неплохой. Но говорить, что nginx в 2018м - это просто реверсивный прокси - это просто неграмотность, имхо. openresty.org/en/

@igorsk1133 5 жыл бұрын

о боже, да этот lua никому в очко не всрался

@AnarJafarov 5 жыл бұрын

А смысл смешивать нгинкс с луа? Если уж приспичило на экзотические технологии то не проще ли сразу на rust, на c++ написать свое? За то развитие для мозга.

@AlexeyZlobin 2 жыл бұрын

tldr; Ну слезайте уже c LAMP.

@SergeyMorsin 3 жыл бұрын

Уже начиная с транзакций можно не смотреть. Человек просто не знает, как это работает на самом деле.

@yuri.moiseyev 3 жыл бұрын

Какая глупость!

@devmozg 4 жыл бұрын

"не позаботились хотя бы о капистране" чтоооо ? о чем речь, какой такой капистран?

@ivankprod 2 жыл бұрын

Capistrano имеется ввиду

@borystsolin 4 жыл бұрын

А причем тут devops? Все кейсы - онпремисные bare-metal серваки, ни клаудов, ни devops практик. Просто тонкая настройках вебсерверов - это не devops.

@altRU1st 4 жыл бұрын

очень часто говорят про devops лишь бы сказать про devops, а по сути те же яйца только сбоку, суть devops-a: "мойте руки перед едой" ))) это как в камеди про табличку на дверь... lol ))))

@bumm1077 4 жыл бұрын

ходит и плямкает. ужас.

@AntiPutler 5 жыл бұрын

php такой php

@rusmemes 4 жыл бұрын

пункт номер 0: не использовать пэхапэ для высоких нагрузок

@ivangorsky7537 4 жыл бұрын

почему?

@user-ll2xw7tn6v 3 жыл бұрын

@@ivangorsky7537 потому что это язык и фремворк для домашних страничек. Был есть и будет. И в чем проблема? В том что он не заточен , не спроектирован под нагрузки, интерпретируемый, медленный, плохо работает с памятью, потоками и т.д.ю

@ivangorsky7537 3 жыл бұрын

@@user-ll2xw7tn6v PHP медленный? С чего ты взял? Очень шустрый язык. Причём не только в плане работы, но и в плане разработки, что очень важно для HL проектов.

@MrRoperd 2 жыл бұрын

@@ivangorsky7537 Это все хорошо, но код ведь выглядит как говно (я про любой php код)

@ivangorsky7537 2 жыл бұрын

@@MrRoperd когда-нибудь научишься писать более понятный код. Не бросай обучение)