Comments 56
Как всё знакомо :)
В оптимизации php+mysql проектов схема всегда примерно одинаковая.
А вот сталкивался кто-нибудь с оптимизацией IIS+ASP.NET+MSSQL?
Такая инфа на ХАБРе вроде бы еще не проскакивала. Если бы кто рассказал — закидал бы плюсами ;)
А вот сталкивался кто-нибудь с оптимизацией IIS+ASP.NET+MSSQL?
Такая инфа на ХАБРе вроде бы еще не проскакивала. Если бы кто рассказал — закидал бы плюсами ;)
поддерживаю по asp.net+mssql
Да все вышесказанное можно отнести и к 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 и т.п.
1. asp.net связан с IIS (особенно в 7-м) достаточно плотно, поэтому опускаем момент по fastcgi
2. т.к. .net все компилирует в машинный код, аналог eAccelerator нам не нужен
3. Индексы в базе и профилирование запросов никто не отменял для хорошей производительности любого приложения
4. Вместо Memcached можно данные кэшировать как на уровне сессии (если сессия настроена на память) или в Application, а по-хорошему есть класс System.Web.Caching.Cache
5. Можно так же рулить параметрами IIS (Максимальное число рабочих потоков в пуле, Максимальное число I/O потоков в пуле и т.п.)
Ну а далее архитектура, несколько серверов в loadbalansing и т.п.
Получается, вся оптимизация делается встроенными средствами IIS & .NET Framework?
Не вся. База оптимизируется отдельно. IIS & .NET «из коробки» дают:
1. Классы поддержки кэширования (не просто key-value, а с зависимостями и т.п.)
2. Архитектура .NET в целом дает нам компиляцию в native код процессора + кэширование этого кода.
3. В IIS7 обработка ASP.NET встраивается в конвейер обработки запроса и этот конвейер можно достаточно гибко настраивать.
4. Начиная с IIS6 можно настроить авторестарт приложения при превышении определенного порога памяти и/или использования процессора, а так же по расписанию.
А вообще нужно думать при написании своего приложения т.к. можно написать так, что никакие средства не помогут.
1. Классы поддержки кэширования (не просто key-value, а с зависимостями и т.п.)
2. Архитектура .NET в целом дает нам компиляцию в native код процессора + кэширование этого кода.
3. В IIS7 обработка ASP.NET встраивается в конвейер обработки запроса и этот конвейер можно достаточно гибко настраивать.
4. Начиная с IIS6 можно настроить авторестарт приложения при превышении определенного порога памяти и/или использования процессора, а так же по расписанию.
А вообще нужно думать при написании своего приложения т.к. можно написать так, что никакие средства не помогут.
— Вместо Memcached можно данные кэшировать как на уровне сессии (если сессия
— настроена на память) или в Application, а по-хорошему есть класс System.Web.Caching.Cache
Memcached тоже нужен для IIS+ASP.NET
Если сайт хоститься на фарме то сессию приходится складывать в базе. Прикрутив Memcached для кеширования мы получили зничительное увеличение производительности.
— настроена на память) или в Application, а по-хорошему есть класс System.Web.Caching.Cache
Memcached тоже нужен для IIS+ASP.NET
Если сайт хоститься на фарме то сессию приходится складывать в базе. Прикрутив Memcached для кеширования мы получили зничительное увеличение производительности.
Собственно в .NET сессии «из коробки» уже умеют работать в нескольких режимах:
InProc — это понятно, в процессе приложения
SQLServer — это тоже понятно — в базе, как раз для ферм, но тормознуто и базу нужно чистить регулярно
StateServer — это в отдельном процессе, подходит для веб-ферм (типа Memcached)
Ну а для истинных гурманов — Custom — самому написать провайдер сохранения сессий.
InProc — это понятно, в процессе приложения
SQLServer — это тоже понятно — в базе, как раз для ферм, но тормознуто и базу нужно чистить регулярно
StateServer — это в отдельном процессе, подходит для веб-ферм (типа Memcached)
Ну а для истинных гурманов — Custom — самому написать провайдер сохранения сессий.
на фарме сессию лучше складывать в StateServer, а не в базу
Респект автору! Очень полезная статья, обязательно пригодится — в закадки.
А вышеописанные способы оптимизации применимы к IIS7/7.5 + mysql + php5?
По поводу поиска и обновления индекса sphinx, посмотрите в сторону дельта индексов.
Вода. Можно ограничиться чтением заголовков.
UFO just landed and posted this here
Отличная статья, и стиль написания великолепен)
Да знайте же, что есть такая книга, как «Реактивные веб сайты» и тогда не будет с каждым разом на одного админа больше, который повторял все то же самое уже миллионов таких же)
Здорово, хоть и ничем подобным не занимаюсь, но прочитал с интересом. Приятно было видеть как улучшения приходят постепенно, шаг за шагом улучшая производительность.
Очень позитивная статья, написанная легким языком. Получил наслаждение и прослезился. Плюс вам!
Полезная «карта», такой «туду-лист» для вебдевелопера.
Спасибо и успехов.
Спасибо и успехов.
Для меня видится закат всех моих наработок
Думаю, эта студия, у которой заказали новый сайт напишет так, что придется вам все по-новой оптимизировать. Я более чем уверен в этом. Мало кто может написать достойное приложение под высокие нагрузки.
А что за сайт? Дайте ссылку плиз, заодно протестируете хабраэффект
К сожалению, сайт локальный и доступен лишь пользователям провайдера :(
Отличная работа. Кто здесь пишет что это есть вода — лицемер. Уверен что такие люди сами это не проходили а лишь имеют частичное представление. Автору мое уважение проделан длинная и честная качественный работа.
порядок пунктов удивляет, eAccelerator (APC) это первое что нужно делать, про индексы вы тоже как-от поздно вспомнили, разделение php-mysql мне больше нравится отдельный мастер на запись + слейвы чтение на нодах с php.
П.С. встроенное кешерование запросов в mysql надеюсь не пропустили? :)
П.С. встроенное кешерование запросов в mysql надеюсь не пропустили? :)
Я потому и сделал заметочку, что я только разбирался во всем и о существовании php-акселераторов не знал. Начни я это делать сейчас, с текущим багажом знаний, порядок был бы совершенно иным, но статья же все-таки в первую очередь история развития :)
Насчет встроенного кеширования конечно же не забыл. Вообще очень много было убито времени на подборки оптимальных конфигов системы, nginx, php-fpm и очень много на mysql. Но я почему-то не посчитал нужным добавить это в статью, через это в любом случае проходить каждому и это очевидный факт :)
Насчет встроенного кеширования конечно же не забыл. Вообще очень много было убито времени на подборки оптимальных конфигов системы, nginx, php-fpm и очень много на mysql. Но я почему-то не посчитал нужным добавить это в статью, через это в любом случае проходить каждому и это очевидный факт :)
Последний тег к статье особенно хорош ^_^
Кстати, я в последнее время перешёл от eAccelerator к APC.
На моих сайтах получилось чуть более эффективно.
На моих сайтах получилось чуть более эффективно.
а автор так и не прочитал замечания про mysql в tmpfs, а мог бы не делать велосипед с квадратными колесами
Я читал Ваши замечания. Если вы про стандартные средства MySQL, то тут все просто — все таблички MyISAM, а Innodb нам не подходит.
Почему не подходит? Просветите, пожалуйста.
у нас:
— очень много SELECT'ов и INSERT'ов в большие таблицы
— частые COUNT
— отсутствие LIKE (как уже говорил, знаю что зло, но за переделку огромной груды кода взяться не было возможности)
Еще на заре ресурса я хотел перейти на InnoDB… вроде и время позволяло и мощностей было прилично, отключил страницы где используется LIKE и запустил… железо продержалось 10 минут, при это время критичных запросов резко возросло…
Будь у текущего ресурса будущее, скорее всего, взялся бы за переписку многих вещей и пошел бы на встречу к InnoDB. И дошел бы медленно, но верно — к более надежной БД. Но теперь смысла нет.
— очень много SELECT'ов и INSERT'ов в большие таблицы
— частые COUNT
— отсутствие LIKE (как уже говорил, знаю что зло, но за переделку огромной груды кода взяться не было возможности)
Еще на заре ресурса я хотел перейти на InnoDB… вроде и время позволяло и мощностей было прилично, отключил страницы где используется LIKE и запустил… железо продержалось 10 минут, при это время критичных запросов резко возросло…
Будь у текущего ресурса будущее, скорее всего, взялся бы за переписку многих вещей и пошел бы на встречу к InnoDB. И дошел бы медленно, но верно — к более надежной БД. Но теперь смысла нет.
Вопрос. Как отразились все Ваши оптимизации на времени отклика для пользователей? Серверу стало «лучше», это замечательно. Но насколько лучше стало посетителям сайта?
Ну вот смотрите. Пример — главная страница:
— Состоит из 20 блоков, почти в каждом блоке есть 1-2 sql-запроса. При добавлении отсутствующих индексов, время выполнения запроса уменьшается. Соответственно страница генерируется быстрее.
— Содержимое многих блоков обновляется не часто, поэтому имеет смысл кешировать это содержимое. В результате полное избавление от sql-запроса при обращении к странице и как следствие страница генерируется еще быстрее.
Так же без тюнинга sysctl количество открытых соединений с сервером становится огромным. В результате в часы пик, пользователь может получить страницу сгенерированную за 0,09 секунд лишь через секунды 2. Настройка сетевой системы серверов, от этого избавляет.
Вообще каждое улучшение сразу же заметно конечному пользователю по времени генерации страницы. Да и банальная связь, в часы пик, когда сервера перегружены они и отдают контент медленнее, когда им «полегчало» — они отдают контент быстрее.
— Состоит из 20 блоков, почти в каждом блоке есть 1-2 sql-запроса. При добавлении отсутствующих индексов, время выполнения запроса уменьшается. Соответственно страница генерируется быстрее.
— Содержимое многих блоков обновляется не часто, поэтому имеет смысл кешировать это содержимое. В результате полное избавление от sql-запроса при обращении к странице и как следствие страница генерируется еще быстрее.
Так же без тюнинга sysctl количество открытых соединений с сервером становится огромным. В результате в часы пик, пользователь может получить страницу сгенерированную за 0,09 секунд лишь через секунды 2. Настройка сетевой системы серверов, от этого избавляет.
Вообще каждое улучшение сразу же заметно конечному пользователю по времени генерации страницы. Да и банальная связь, в часы пик, когда сервера перегружены они и отдают контент медленнее, когда им «полегчало» — они отдают контент быстрее.
А сколько баллов YSlow выдаёт?
Понятно. Ваш ответ наводит на определенные мысли. :)
Жалко нет возможности посмотреть на сам сайт, я бы мог высказаться более конкретно.
Спасибо.
Жалко нет возможности посмотреть на сам сайт, я бы мог высказаться более конкретно.
Спасибо.
Еще можно добавить рамдиск используя при этом обычное файловое кэширование. Отпадает необходимость в memcached для кэширования общих данных, но все же хорош для кэширования пользовательских данных, тех же сессий к примеру. Также кэширование на уровне nginx, очень гибкие настройки. На одном очень нагруженном проекте с огромной динамикой (ежеминутное обновление) схема прекрасно работала.
Sign up to leave a comment.
История развития и оптимизаций одного высоконагруженного ресурса