Роман Петров предложил . Ну, чем богаты, тем и рады.
Делали мы как-то новостной сайт с высокой посещаемостью. Естественно, много думали о скорости работы сайта.
[spoiler]
Есть такая кавказская пословица:
Один сын -- это не сын. Два сына -- это полсына. Три сына -- это сын.
Оказалась очень верной.
Один сын -- это не сын
Ну, казалось бы, что там. Много новостных лент на морде и на страницах тематических разделов, сейчас подчистим штатные битриксовые компоненты, наладим кеширование, и всё будет летать. Подчищать не стали, конечно, переписали с нуля, ни единого лишнего запроса к базе нет, кешируется как надо. Были очень довольны собой.
Два сына -- это полсына
А потом импортировали базу сайта. На четверть ляма записей в одной только таблице новостей, не считая картинок и комментариев. Сайт на нашем VPS сказал "кря" и работать перестал. Перенесли разработку сайта на боевой сервер, благо он был мощнее.
Уяснили для себя то, что давно знали в теории: в лоб работать с инфоблоком на 250 тысяч элементов нельзя -- LIMIT елозит по всей выборке, нужно ограничивать объём выборки через IBLOCK_ID или DATE_ACTIVE_FROM (в нашем случае годилось это, в вашем случае могут потребоваться другие решения). Приняли меры, чтобы всё начало летать (увеличили скорость сборки страниц более чем на два десятичных порядка, с 40-60 сек. до 0.3-0.15 сек.). Были очень довольны собой.
А потом сайт начали тестировать на боевом хостинге.
Спасибо коллегам из Битрикса: Игорю Усольцеву, Сергею Рыжикову, Максиму Смирнову, Денису Шаромову. Было очень много тонкостей в настройке серверного окружения.
Например, из-за неправильной настройки SMTP добавления комментария к новости ставило сайт раком на 60 секунд.
Например, из-за особенностей InnoDB при добавлении новости сайт мог умереть минут на 15.
Три сына -- это сын
А потом сайт выкатили под реальную нагрузку.
И парились с ним ещё около месяца.
Например, из-за не совсем подходящей настройки nginx/apache 404 ошибка обрабатывалась ядром битрикса, и сайт вставал колом -- потому что было много паразитных запросов к несуществующим картинкам.
Например, если у вас 50М записей в b_search_content_stem, и несколько человек желают одновременно что-то найти, то слюниксовая машина умирает, потому что дисковый массив ставит её раком. Ну, умирала, потом Максим Смирнов облегчил запрос к базе, стало получше.
И тому подобное.
Напоминаю ключевые моменты:
* сначала много думать;
* потом смотреть на реальных данных;
* потом быть готовым к реальной нагрузке.
Делали мы как-то новостной сайт с высокой посещаемостью. Естественно, много думали о скорости работы сайта.
[spoiler]
Есть такая кавказская пословица:
Один сын -- это не сын. Два сына -- это полсына. Три сына -- это сын.
Оказалась очень верной.
Один сын -- это не сын
Ну, казалось бы, что там. Много новостных лент на морде и на страницах тематических разделов, сейчас подчистим штатные битриксовые компоненты, наладим кеширование, и всё будет летать. Подчищать не стали, конечно, переписали с нуля, ни единого лишнего запроса к базе нет, кешируется как надо. Были очень довольны собой.
Два сына -- это полсына
А потом импортировали базу сайта. На четверть ляма записей в одной только таблице новостей, не считая картинок и комментариев. Сайт на нашем VPS сказал "кря" и работать перестал. Перенесли разработку сайта на боевой сервер, благо он был мощнее.
Уяснили для себя то, что давно знали в теории: в лоб работать с инфоблоком на 250 тысяч элементов нельзя -- LIMIT елозит по всей выборке, нужно ограничивать объём выборки через IBLOCK_ID или DATE_ACTIVE_FROM (в нашем случае годилось это, в вашем случае могут потребоваться другие решения). Приняли меры, чтобы всё начало летать (увеличили скорость сборки страниц более чем на два десятичных порядка, с 40-60 сек. до 0.3-0.15 сек.). Были очень довольны собой.
А потом сайт начали тестировать на боевом хостинге.
Спасибо коллегам из Битрикса: Игорю Усольцеву, Сергею Рыжикову, Максиму Смирнову, Денису Шаромову. Было очень много тонкостей в настройке серверного окружения.
Например, из-за неправильной настройки SMTP добавления комментария к новости ставило сайт раком на 60 секунд.
Например, из-за особенностей InnoDB при добавлении новости сайт мог умереть минут на 15.
Три сына -- это сын
А потом сайт выкатили под реальную нагрузку.
И парились с ним ещё около месяца.
Например, из-за не совсем подходящей настройки nginx/apache 404 ошибка обрабатывалась ядром битрикса, и сайт вставал колом -- потому что было много паразитных запросов к несуществующим картинкам.
Например, если у вас 50М записей в b_search_content_stem, и несколько человек желают одновременно что-то найти, то слюниксовая машина умирает, потому что дисковый массив ставит её раком. Ну, умирала, потом Максим Смирнов облегчил запрос к базе, стало получше.
И тому подобное.
Напоминаю ключевые моменты:
* сначала много думать;
* потом смотреть на реальных данных;
* потом быть готовым к реальной нагрузке.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
