Comments 26
Интересно, но очень не хватает конкретных примеров было/стало. Например какой был client_max_body_size.
В InnoDB данные хранятся в больших совместно используемых файлах, в отличие от используемого прежде MyISAM, где для каждой конкретной таблицы создается отдельный файл данных.
innodb_file_per_table/0
innodb_flush_log_at_trx_commit 1
есть еще вот https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/
https://news.ycombinator.com/item?id=27226382
2. А что если brotli, pagespeed, proxy_buffering ни разу не про кеширование? А кеширование на nginx — это примерно начинать отсюда.
3. А что если скрипт не поддерживает memcache?
И много много подобных «а что если». И прежде чем подводить итог в статье, хотелось бы цифры (а не мелкие картинки) — вот, было столько-то запросов в сек, такое-то время генерации, потребление проца, iops, памяти; стало столько-то и столько-то, проверялось на движке магазина таком-то и таком-то железе.
Загрузите все картинки в базу. Все товары сделайте с произвольным набором полей (произвольного типа). Список полей для каждого товара с их типами и значениями храните в одной таблице. Ссылки на картинки, кстати, отдельной строкой тоже там же.
А теперь попробуйте вывести все товары со всеми их полями, чтобы в поле description были слова "робот" и "трансформер", в категории (да, тоже отдельная строка) "игрушки".
В смысле — как? Обычно, как любые другие данные. Зачем тут base64?
Ну, если мы возьмем тот же Woocommerce, то там, вроде бы, все же на диске хранят отдельно изображения, так что мой пример был немного ироничным.
Но, тем не менее, по существу вопроса, вот ответ на SO из которого, в принципе, можно понять — "как можно сделать чтобы было медленно"
UPD. А, дошло)) Просто считываем файл и прямо так и пишем в бд) Настолько жесть, что в голову не пришло даже)
А я не могу понять, что здесь непонятного :)
Картинка — это набор байт. Или, по-другому, "данные". что нам мешает взять и записать данные в базу данных?
Ну понятно, что у поля не должна быть текстовая кодировка, но в остальном-то какие проблемы прочитать содержимое файла в переменную и отправить эту переменную в БД, как любую другую? :)
Предположу что причина — это Wordpress с плагином WooCommerce?
Один раз по просьбе клиента пришлось залезть внутрь и посмотреть как оно хранит данные. Так вот — оно все что можно хранит в одной огромной таблице, в отдельной колонке указывая тип данных. Конечно оно будет тормозить в базе. Одним запросом все не вытащить, все может доходить до отдельного запроса (или больше) на каждый показываемый продукт.
Видел это давно, но вряд ли за 5 лет это поменяли.
Настройка nginx здесь — это как покрасить ржавое ведро чтобы вода хотя бы краской (кэш) задерживалась. Попробуйте профилировать запросы к базе.
Очень жаль, что в статье почти нет фактуры. Вот не хочется ругаться, скорее всего тут действительно искреннее желание поделиться, но по факту статья выглядит совсем по-другому. На реддите часто постят спам индусские бодишопы, методом "сеошник спускает копирайтеру топик, тот пишет набор слов на заданную тему". И читая эту статью, я не могу избавиться от ощущения что она написана тем же способом. От некоторых цифр глаза на лоб лезут
- 80 секунд на наиболее посещаемых страницах? Это что вообще? Для того, чтобы это заметить, надо проводить специальное исследование? И с такими цифрами мы говорим о живом бизнесе, серьёзно? На этот сайт кто-то ещё ходил? Но тогда при чем здесь слово "highload"? Может быть 80 — это все-таки опечатка, и речь о 8 секундах?
- 3-8 секунд на страницу после оптимизации преподносится как достижение. Нет, ну я могу понять, что унутре там адов битрикс, для которого это действительно значительное достижение, на пределе возможностей. Но по современным меркам это труп, который даже не дышит. Что говорит PageSpeed про такие "достижения"?
Но ок, перейдем к самим шагам.
- Шаг 1. Настройка баз данных. Ээээ. А где про саму настройку-то? что именно настроили? Этот пункт — ну реально мемасик про "profit!!!". Зачем его вообще было писать?
- Шаг 2. myisam? В каком смысле myisam? Innodb — это движок по умолчанию уже не меньше 10 лет. Откуда здесь вообще взялась БД на myisam? Хотя наверное снова можно найти универсальное объяснение — битрикс. Ну ок.
- Innodb. В принципе правильная рекомендация, но объяснение… "Дело в том, что пока запрос не будет выполнен, никакие другие обращения к таблице/строке будут невозможны". Вот из этой фразы за километр торчат уши копирайтера, который пишет как дорогой Леонид Ильич, по бумажке. Ну неправда же. Если бы так было, то любая БД была бы принципиально однопоточной. SELECT лочит данные в SHARED моде, то есть другие потоки вполне могут читать те же самые данные. А вот с обновлением все верно — myisam не сможет обновить таблицу, из которой идет чтение, пусть даже совсем другой строки.
- "Также была произведена оптимизация работы самой базы данных InnoDB. Например, были оптимизированы параметры:" читатель уж потирает руки и ждет рифмы "розы". "Вот оно, добрались до сути" — думает он. "Сейчас будут практические рекомендации, какая конкретно настройка какой конкретно дала буст к производительности...". Ага, разбежался, наивный. Это промо-статья. Для продвижения компании на хабре. А не для тебя, читатель. Взять самую важную настройку,
innodb_buffer_pool_size. По дефолту, ускоряет работу её увеличение. Но из контекста статьи можно предположить (именно что предположить, поскольку никакой конкретики в ней нет), что во-первых, основные проблемы были с памятью, а во-вторых — наш "хайлоад" проект весь лежит на одном серваке. То есть, возможно, буфер наоборот — подрезали, тем более что БД микрушечная, сотня тыщ строк. Но почему об этом не сказано, как именно была изменена настройка? - Промежуточные результаты. Не слишком впечатляют. Чтобы увидеть разницу на первых двух графиках надо очень сильно приглядываться.
- Апач. Тоже в принципе правильный ход, но мотивация… "Например, Apache приходится каждый раз считывать несколько конфигурационных файлов на сервере". А кто заставляет эти файлы писать-то? И вообще включать
AllowOverride? Опять же, основная проблема Апача — это mod_php, устаревший режим сопряжения с РНР. Но если запускать Апач в threaded режиме вместо prefork, и цеплять пых через тот же php-fpm, то разница практиески нивелируется. Но если фронтом стоит Энжинкс, то в Апаче действительно надобность отпадает. И очень хотелось бы всё это прочитать в статье. - Nginx. Опять это фирменное "в совокупности с перенастройкой Nginx". Какой перенастройкой-то?
- Заключение. И снова графики, на которых надо с лупой что-то разбирать. Ну хоть бы красной линией отметили, где там "до" и "после". Вроде бы, БД "оптимизировали" 27 марта. Но на конечном графике там самый махровый оверлоад. Причем какой-то пик, по краям которого в целом одинаковые крылья. 24 марта на сайт начали лить трафик что ли, из-за которого сайт начал падать? А где об этом сказано? Где цифры посещаемости до и после? Или мы вот реально должны поверить, что спад нагрузки 31-го — это результат "оптимизаций", а не тупо дёрнули рубильник в адсенсе?
Если вам интересно мнение рядового читателя, то я бы рекомендовал статью переделать. Кейс действительно может быть очень интересным и полезным. Если дать фактуру, объяснения брать не с потолка, и как-то более явно отметить достижения.
Вы не представляете, какие бывают франкенштейны с точки зрения времени отклика. Сейчас пытаемся "профилировать" сайт, который в первой версии, к которой мы были привлечены, клался одним пользователем прыжками по F5, а если "аккуратно", то главная страница открывалась 10 секунд, при этом разрабатывали его серьезные люди, микросервисы там, несколько разных СУБД под капотом, ещё куча всякого (контент правда большой), 80 ядер ВМ и т.п.
80 секунд на наиболее посещаемых страницах? Это что вообще? Для того, чтобы это заметить, надо проводить специальное исследование? И с такими цифрами мы говорим о живом бизнесе, серьёзно? На этот сайт кто-то ещё ходил? Но тогда при чем здесь слово «highload»? Может быть 80 — это все-таки опечатка, и речь о 8 секундах?
А вы в новом дизайне хабра откройте комментарии к какой-нибудь наиболее посещаемой странице, где их есть уже тысяча. Всё будет примерно так, как описано.
Ну с одной стороны вы правы. Сейчас посмотрел — где-то 8-10 секунд до начала рендера на 1700 комментариев. Слава богу что улучшаторы пока не забрали у нас десктопную версию.
С другой — все-таки, 8 секунд — не 80.
С третьей — хабр в каком-то роде монополист, и люди терпят. Но будь у него более шустрые конкуренты, как это наблюдается в екомммерсе, то такие цифры очень быстро стали бы критическими.
Нет, ну я могу понять, что унутре там адов битрикс, для которого это действительно значительное достижение, на пределе возможностей.
Вот не люблю я безосновательных наездов. Да, Битрикс во многом ужасен (сам могу воз и не забуду про маленькую тележку примеров того что в нём не так написать), но быстрым он может быть - просто надо уметь его готовить.
У меня сайт на тяжёлой редакции "Эксперт" Битрикса. И связка nginx+apache (ибо мне так удобнее и ничуть не медленнее nginx+php-fpm). Разумеется никакой "композитный сайт" не включен.
Вот страница с кучей фото и видео - хотите протестируйте хоть в webpagetest хоть PageSpeed, хоть на глаз просто по сайту полазьте - быстрее намного чем все сайты на новомодных фреймворках:
Я извиняюсь, но задам нескромный вопрос. Какой объем информации в БД и какая посещаемость на этом сайте? Я так понимаю, что вопрос, в сущности, риторический.
А проблема битрикса в том, что с нагрузкой на динамические сайты он справляется примерно никак. Ключевое слово — динамические. Хорошо когда у тебя сказка про Хрюшу, которую можно закэшировать по самые помидоры. А когда у тебя склад и скидки по 20 критериям и ты должен продать клиенту товар ровно по той цене, которая ему обещана, и не продать тот, который уже закончился — вот тут в такой ситуации покажи мне сайт на битриксе — поговорим.
Связка "nginx+apache" действительно является пожарным решением, которое нивелирует основную проблему mod_php — висящий в памяти процесс Апача, пока медленный клиент забирает свой ответ. Энжинкс же быстренько забирает ответ в свой буфер, и спокойно отдаёт клиенту, сколько надо. Я и сам так делал в своё время, когда надо было сервер спасать, а хтаксессы чистить было некогда. Но при первой же возможности избавился от лишнего звена. Рекомендую. хтаксесс на самом деле не такой важный файл, как кажется :)
На счёт размера базы и отсутствия сложных фильтров соглашусь.
"Скорость" сайта с максимально возможным количеством одновременных подключений, которые сайт держит не связана. Поэтому посещаемость тут не причём (хотя когда мой сайт ддосили тормозить он стал только после 250.000 одновременных подключений).
Почему Вы решили что у меня mod_php ? :) У меня mod_fcgid и апач мне нужен отнюдь не из-за .htaccess. Да и нет у меня необходимости экономить оперативку (хоть попой её ешь) и тесты я проводил - ничуть не медленнее ngin+apache чем nginx+php-fpm (хотя последний вариант меньше памяти расходует, но как писал выше в моём случае это не актуально).
Так что просто согласитесь - сайт мой на Битрикс ? - на Битрикс, сайт быстрый ? - быстрый. :)
Как ускорить сайт в 4 раза, просто перенастроив сервер