Программы
ЛИРА АВС-4 Антивирус Скачать AutoCAD Видео Архитектура Битрикс ZwCAD ФОК-ПК фундаменты STARK ES Дизайн Firewall Геодезия ArchiCAD Документооборот Microsoft AutoCAD Civil 3D САПФИР UserGate Сайт Проектирование CorelDRAW SANA МОНОМАХ Шкаф серверный Traffic Inspector Revit Механика MapInfo Adobe Windows СПДС Электрика Consistent Software Помощь покупателю ePochta Artlantis UPS ЭСПРИ УПРЗА Эколог Источники бесперебойного питания PROMT Строительная лицензия Photoshop ZW3D KVM V-Ray GeoniCS Топоплан-Генплан-Сети-Трассы Стабилизатор ЭЛЬФ Инвертор 3D Max Vault СпИн Office ПРУСК Allklima for AutoCAD Profilmaker GeoniCS ЖЕЛДОР НДС ОДИССЕЙ стать партнером Kerio iPad Maya ABBYY Project StudioCS Электрика ИНЖКАД Civil HP WhatsApp ПЛАНИКАД Pagemaker GLASER -isb cad MechaniCS ЭЛЬФ проектирование ИНФОКАД IP модуль ТОПОКАД GeoniCS MechaniCS Express Revit MEP Инвент-ГРАД Inventor AutoCAD MEP Сервер MechaniCS Оборудование Allplan DEREK-INFO Project StudioCS Доставка AutoCAD Revit Architecture GeoniCS Изыскания БЕТА ArCon ElectriCS Рейтинг программ ЧПУ Project StudioCS Водоснабжение Еврокоды Borland GeoniCS Инженерная геология ПК МОНОМАХ EnergyCS Softimage КАД РЕЛЬЕФ 3DMax САПР ЦВК Project StudioCS Конструкции ЗЕМКАД CAD RTR ViTerminal ПК Металл TDMS iPfone
Авторизация
Логин:
Пароль:
Забыли свой пароль?
Войти как пользователь:
Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:
Получать новости
Статистика сайта

Hits
1389469
1017

Hosts
124236
169

Visitors
417068
585
1

Почему умирают сайты?

Почему умирают сайты?

Нестабильные системы
Любой аппаратный комплекс, программа или сетевые системы создаются в расчете на определенные нагрузки. Нас не удивляет, когда покрышки автомобилей испытываются на максимально допустимую скорость и продаются с четким указанием допустимых величин. Но крайне редко приходится встречать подобное отношение к программно-аппаратным комплексам.
Очень редко компании перед запуском проекта в эксплуатацию проводят нагрузочное тестирование сервера и определяют максимально допустимую посещаемость. Кстати, в рамках тестирования легко выявляются наиболее частые ошибки и слабые места, и в результате производительность сервера увеличивается в несколько раз.
Но мы поговорим о причинах, по которым обычный веб-сервер в результате нагрузочного тестирования или реальных пиковых нагрузкок прекращает нормальное функционирование.

При больших нагрузках проект может прекратить нормальное функционирование по следующим причинам:
   1. Нехватка оперативной памяти для нормальной одновременной работы процессов веб-сервера и базы данных. В большинстве систем на каждый запрос к сайту открывается отдельный процесс веб-сервера. Обычный размер процесса Apache с подключенным PHP-модулем и работающим приложением может составить порядка 20-30 мегабайт. В результате пиковых нагрузок происходит одновременный запуск очень большого числа процессов (иногда больше нескольких сотен процессов). И как следствие, начинается свопирование процессов, а это неизбежно сказывается на производительности базы данных, и производительность всей системы в целом резко снижается.
   2. Нехватка процессорных ресурсов для одновременного выполнения процессов и обеспечения адекватного для пользователя времени реакции. Данная ситуация может возникнуть в том случае, если в результате большого числа запросов к вашему серверу число одновременно выполняемых запросов превысит процессорные мощности сервера. И даже если у вас достаточно оперативной памяти и первая проблема не проявила себя, вы можете обнаружить, что система перестала адекватно отвечать на запросы, время выполнения страниц увеличилось в несколько раз, база данных перегружена очень большим числом запросов. Все это может привести к тому, что все без исключения пользователи не смогут работать с сервером.
   3. Недостаточная производительность базы данных при одновременных конкурентных запросах, невозможность полностью использовать ресурсы сервера. Данная ситуация очень часто возникает при работе с MySQL. Надо отметить, что обычно MySQL использует формат таблиц MyISAM. Это очень простой и эффективный вариант работы, но, к сожалению, при большом числе одновременных запросов такая база данных становится критически узким местом в производительности системы в целом. Во время вставки данных, обновления и некоторых других запросах, происходит эксклюзивное локирование таблиц и, как следствие, все запросы выполняются только последовательно, а не одновременно. В результате, при росте нагрузки, время генерации страниц возрастает необоснованно резко и в итоге становится неприемлемо большим. Менее всего подвержены подобным проблемам проекты, использующие Oracle или MSSQL, MySQL с форматом таблиц InnoDB.
   4. Общая несбалансированность веб-системы при пиковых нагрузках и быстрая регрессия производительности даже при незначительных стрессах. При пиковых нагрузках вся система испытывает перегрузки. В дополнение к перечисленным проблемам возможно возникновение проблем в дисковой подсистеме. В итоге, если под одной из составляющих начинается потеря производительности, то существенно падает производительность всей системы, начинается падение производительности в других частях и, в итоге, еще больше снижается работоспособность, производительность системы регрессирует и иногда наступает полная остановка в работе.
Оперативная память: большие процессы
Остановимся чуть подробнее на вопросе использования веб-сервером оперативной памяти.
Как мы уже упоминали, в большинстве конфигураций на каждый запрос пользователя к сайту веб-сервер запускает отдельный процесс-обработчик. Вместе с загруженными модулями, интерпретатором PHP и исполняемым приложением каждый процесс может занимать 20-30 мегабайт, а иногда и более.
10 запущенных процессов будeт потреблять уже 200-300М, а запущенные 100 процессов приведут к сильнейшему свопингу системы с объемом оперативной памяти в 1Г, так как для работы всех процессов потребуется порядка 2-3Г памяти.
Как показывает практика, именно нехватка оперативной памяти для всех процессов может стать ключевым фактором нестабильности при пиковых нагрузках.
Также стоит отметить, что в обычной конфигурации веб-сервер обрабатывает все запросы к PHP-страницам, к графическим файлам, бинарным файлам, таблицам стилей и другим составным частям сайта.
На одну страницу сайта может приходиться от нескольких десятков до нескольких сотен графических элементов. Загрузка бинарных файлов, XML-файлов, таблиц стилей также выполняется веб-сервером в обычных конфигурациях.
Теперь, если вспомнить, что обычный процесс веб-сервера занимает 20-30М, то получается, что для выдачи статических элементов сайта полностью не используется функциональность по обработке PHP, а память при этом используется, и процесс занят обработкой запросов. Получается, что до 90% времени процесс, находящийся в памяти, будет обрабатывать именно статические документы, неэффективно используя ресурсы.
Проблема выдачи статического контента настолько существенна, что одной из важнейших задач является минимизация числа статических запросов, обрабатываемых веб-сервером.
Оперативная память: медленные каналы
Еще один аспект проблемы – это медленные каналы пользователей вашего сайта по меркам веб-сервера. Казалось бы, какое отношение эта проблема может иметь к владельцу сайта? Оказывается, не просто имеет отношение, но и может стать причиной больших проблем.
Например, время генерации страницы может составлять 0.01 секунды, а время передачи страницы клиенту даже с компрессией может занимать от 5 до 50 секунд и более.
В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных, но не сможет высвободить память и высвободиться сам, чтобы обработать другой запрос.
Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.
Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.
В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю.
Предположим, что на каждый сайт поступает по 100 запросов в секунду.
Система А: обработка 100 запросов в секунду потребует одновременной работы 100 самостоятельных процессов веб-сервера! "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы. Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 10Г оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.
Система Б: за первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час. Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 200М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.
Очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.

Заголовок окна браузера:  Почему умирают сайты?

Возврат к списку


Материалы по теме:


Поиск
Новости
Статьи

Инструкция по установке “SANA-2015”

ЛИРА-САПР 2018. Предварительный анонс.

Новое в АВС-4 2018.1 2 квартал 2018 г.

АВС 2018 дополнения и изменения.

Связь Tekla Structures — ЛИРА-САПР — Tekla Structures

Экспертиза проектов строительства передана в частный сектор

ЛИРА САПР 2016 новые возможности и функции

В РК внедряются Еврокоды взамен устаревших СНиПов

WebSite X5 Professional

Office 2016

ParticleShop добавит физические кисти в Photoshop

Скачать ArchiCAD

Forefront TMG миграция

Traffic Inspector Enterprise

АВС-5.3.2 по вопросу внедрения ресурсного метода ценообразования

ЛИРА 10.4

AutoCAD под ОС Windows 8 и 8. 1

AutoCAD 2015 for Mac

Autodesk постепенно переходит от реализации бессрочных лицензий AutoCAD к схеме Подписки.

УПРЗА Эколог 4.0. ПДВ-ЭКОЛОГ 4.60

Corel VideoStudio X8 — пакет для редактирования видео

55% пользователей смартфонов забывают о бэкапах

Новые возможности системы ГРУНТ для определения параметров жесткости грунтового и свайного оснований

ЛИРА-САПР 2015 новая система документирования.

SANA обновлена часть Выпуска 15 к СНиР.

Недорогой аналог АвтоКАД

facebook-logo.png v_k_logo.jpg odnoklassniki_logo.jpg mail_ru_logo.jpg tweeter_logo.jpg