История развития и оптимизаций одного высоконагруженного ресурса

[@odmin4eg]

Как всё знакомо :)

[@region23]

В оптимизации php+mysql проектов схема всегда примерно одинаковая.

А вот сталкивался кто-нибудь с оптимизацией IIS+ASP.NET+MSSQL?
Такая инфа на ХАБРе вроде бы еще не проскакивала. Если бы кто рассказал — закидал бы плюсами ;)

[@Muxa]

поддерживаю по asp.net+mssql

[@ETCDema]

Да все вышесказанное можно отнести и к IIS+ASP.NET+MSSQL за исключением некоторых моментов:
1. asp.net связан с IIS (особенно в 7-м) достаточно плотно, поэтому опускаем момент по fastcgi
2. т.к. .net все компилирует в машинный код, аналог eAccelerator нам не нужен
3. Индексы в базе и профилирование запросов никто не отменял для хорошей производительности любого приложения
4. Вместо Memcached можно данные кэшировать как на уровне сессии (если сессия настроена на память) или в Application, а по-хорошему есть класс System.Web.Caching.Cache
5. Можно так же рулить параметрами IIS (Максимальное число рабочих потоков в пуле, Максимальное число I/O потоков в пуле и т.п.)

Ну а далее архитектура, несколько серверов в loadbalansing и т.п.

[@region23]

Получается, вся оптимизация делается встроенными средствами IIS & .NET Framework?

[@ETCDema]

Не вся. База оптимизируется отдельно. IIS & .NET «из коробки» дают:
1. Классы поддержки кэширования (не просто key-value, а с зависимостями и т.п.)
2. Архитектура .NET в целом дает нам компиляцию в native код процессора + кэширование этого кода.
3. В IIS7 обработка ASP.NET встраивается в конвейер обработки запроса и этот конвейер можно достаточно гибко настраивать.
4. Начиная с IIS6 можно настроить авторестарт приложения при превышении определенного порога памяти и/или использования процессора, а так же по расписанию.

А вообще нужно думать при написании своего приложения т.к. можно написать так, что никакие средства не помогут.

[@andrikos]

— Вместо Memcached можно данные кэшировать как на уровне сессии (если сессия
— настроена на память) или в Application, а по-хорошему есть класс System.Web.Caching.Cache

Memcached тоже нужен для IIS+ASP.NET
Если сайт хоститься на фарме то сессию приходится складывать в базе. Прикрутив Memcached для кеширования мы получили зничительное увеличение производительности.

[@ETCDema]

Собственно в .NET сессии «из коробки» уже умеют работать в нескольких режимах:
InProc — это понятно, в процессе приложения
SQLServer — это тоже понятно — в базе, как раз для ферм, но тормознуто и базу нужно чистить регулярно
StateServer — это в отдельном процессе, подходит для веб-ферм (типа Memcached)
Ну а для истинных гурманов — Custom — самому написать провайдер сохранения сессий.

[@atd]

на фарме сессию лучше складывать в StateServer, а не в базу

[@andrikos]

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

[@This_man]

Респект автору! Очень полезная статья, обязательно пригодится — в закадки.

[@jack7277]

А вышеописанные способы оптимизации применимы к IIS7/7.5 + mysql + php5?

[@DevMan]

Частично применимы (для того что из вышеописанного кроссплатформенно).

[@FaKiR]

Да, меняешь IIS на Nginx и применяешь все вышеописанные способы ))

[@fuCtor]

По поводу поиска и обновления индекса sphinx, посмотрите в сторону дельта индексов.

[@Georg]

Там сейчас появились real time индексы, но правда я их не тестировал и боюсь что не так уж быстро они работают

[@fuCtor]

Ага, на том же ресурсе увидел их описание, но пока не обновлил работающий sphinx до последней версии.
Работает, не тронь =)

[@Georg]

Прописная истина!

[@Ackrite]

Вода. Можно ограничиться чтением заголовков.

[@Wendor]

Если так судить, книгам хватит и одного оглавления.

[@jack7277]

на ИТ все пытаются сэкономить ))

[@basken]

Так и есть… Начинают вкладываться только тогда, когда что-то перестает работать

[@i360u]

Но такие ситуации ведь и делают работу интересной!

[@linux2000]

Отличная статья, и стиль написания великолепен)

[@Kakysha]

Да знайте же, что есть такая книга, как «Реактивные веб сайты» и тогда не будет с каждым разом на одного админа больше, который повторял все то же самое уже миллионов таких же)

[@DevMan]

Эта книга совсем не о том.

[@Zubchick]

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

[@orloffkirill]

Очень позитивная статья, написанная легким языком. Получил наслаждение и прослезился. Плюс вам!

[@rubyrabbit]

Полезная «карта», такой «туду-лист» для вебдевелопера.

Спасибо и успехов.

[@Bonch]

Для меня видится закат всех моих наработок

Думаю, эта студия, у которой заказали новый сайт напишет так, что придется вам все по-новой оптимизировать. Я более чем уверен в этом. Мало кто может написать достойное приложение под высокие нагрузки.

[@Wendor]

Возможно так оно и будет. Спасибо за поддержку ;)

[@bar_boss]

А что за сайт? Дайте ссылку плиз, заодно протестируете хабраэффект

[@Wendor]

К сожалению, сайт локальный и доступен лишь пользователям провайдера :(

[@DanilShirokikh]

А я вот, например, тоже в Барнауле живу. Было бы интересно все же узнать что это за ресурс. Перебираю в голове варианты — чтобы был доступен только для локальных пользователей, чтобы наполнялся пользователями и был высоконагружен и не могу сообразить… форум?

[@Wendor]

Т.к. я раскрыл некий план дальнейшего развития ресурса, мне пока не хотелось бы называть его.
Возможно в следующей статье по оптимизации уже новой CMS я расскажу о нем более открыто. Если уж очень интересно, расскажу в ЛС ;)

[@insa]

Какой-нибудь торрент трекер? ,-)

[@JeanLouis]

Отличная работа. Кто здесь пишет что это есть вода — лицемер. Уверен что такие люди сами это не проходили а лишь имеют частичное представление. Автору мое уважение проделан длинная и честная качественный работа.

[@standov]

порядок пунктов удивляет, eAccelerator (APC) это первое что нужно делать, про индексы вы тоже как-от поздно вспомнили, разделение php-mysql мне больше нравится отдельный мастер на запись + слейвы чтение на нодах с php.

П.С. встроенное кешерование запросов в mysql надеюсь не пропустили? :)

[@Wendor]

Я потому и сделал заметочку, что я только разбирался во всем и о существовании php-акселераторов не знал. Начни я это делать сейчас, с текущим багажом знаний, порядок был бы совершенно иным, но статья же все-таки в первую очередь история развития :)

Насчет встроенного кеширования конечно же не забыл. Вообще очень много было убито времени на подборки оптимальных конфигов системы, nginx, php-fpm и очень много на mysql. Но я почему-то не посчитал нужным добавить это в статью, через это в любом случае проходить каждому и это очевидный факт :)

[@merk]

Последний тег к статье особенно хорош ^_^

[@akzhan]

Кстати, я в последнее время перешёл от eAccelerator к APC.

На моих сайтах получилось чуть более эффективно.

[@Masterkey]

а автор так и не прочитал замечания про mysql в tmpfs, а мог бы не делать велосипед с квадратными колесами

[@Wendor]

Я читал Ваши замечания. Если вы про стандартные средства MySQL, то тут все просто — все таблички MyISAM, а Innodb нам не подходит.

[@Darx]

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

[@Wendor]

у нас:
— очень много SELECT'ов и INSERT'ов в большие таблицы
— частые COUNT
— отсутствие LIKE (как уже говорил, знаю что зло, но за переделку огромной груды кода взяться не было возможности)

Еще на заре ресурса я хотел перейти на InnoDB… вроде и время позволяло и мощностей было прилично, отключил страницы где используется LIKE и запустил… железо продержалось 10 минут, при это время критичных запросов резко возросло…

Будь у текущего ресурса будущее, скорее всего, взялся бы за переписку многих вещей и пошел бы на встречу к InnoDB. И дошел бы медленно, но верно — к более надежной БД. Но теперь смысла нет.

[@Tikonderoga]

Вопрос. Как отразились все Ваши оптимизации на времени отклика для пользователей? Серверу стало «лучше», это замечательно. Но насколько лучше стало посетителям сайта?

[@Wendor]

Ну вот смотрите. Пример — главная страница:
— Состоит из 20 блоков, почти в каждом блоке есть 1-2 sql-запроса. При добавлении отсутствующих индексов, время выполнения запроса уменьшается. Соответственно страница генерируется быстрее.
— Содержимое многих блоков обновляется не часто, поэтому имеет смысл кешировать это содержимое. В результате полное избавление от sql-запроса при обращении к странице и как следствие страница генерируется еще быстрее.

Так же без тюнинга sysctl количество открытых соединений с сервером становится огромным. В результате в часы пик, пользователь может получить страницу сгенерированную за 0,09 секунд лишь через секунды 2. Настройка сетевой системы серверов, от этого избавляет.

Вообще каждое улучшение сразу же заметно конечному пользователю по времени генерации страницы. Да и банальная связь, в часы пик, когда сервера перегружены они и отдают контент медленнее, когда им «полегчало» — они отдают контент быстрее.

[@kovyrlo]

А сколько баллов YSlow выдаёт?

[@Wendor]

YSlow же измеряет скорость загрузки всей страницы с ее компонентами… Т.е. он анализирует заголовки, сжатие, попадания в кеш и прочее… а статья о времени генерации страницы… т.е. о скорости обработки php скриптов

Но все же, на разных страницах по разному… от 71 до 83

[@kovyrlo]

Я читал статью и считаю её весьма полезной, но комментарий то, на который вы ответили, был про отклик для пользователей, вот и решил узнать про YSlow.
А эти цифры с CDN?

[@Wendor]

без

[@Tikonderoga]

Понятно. Ваш ответ наводит на определенные мысли. :)
Жалко нет возможности посмотреть на сам сайт, я бы мог высказаться более конкретно.

Спасибо.

[@winbackgo]

Еще можно добавить рамдиск используя при этом обычное файловое кэширование. Отпадает необходимость в memcached для кэширования общих данных, но все же хорош для кэширования пользовательских данных, тех же сессий к примеру. Также кэширование на уровне nginx, очень гибкие настройки. На одном очень нагруженном проекте с огромной динамикой (ежеминутное обновление) схема прекрасно работала.