Сколько пользователей достаточно, чтобы сделать большую нагрузку для веб-приложения

Question

У меня есть веб-приложение, которое в последние дни сильно загружено. Приложение работает на одном сервере с 8-ядерным процессором Intel и 4 ГБ оперативной памяти. Программное обеспечение: Drupal 5 (Apache 2, PHP5, MySQL5) работает на Debian.

После достижения 500 аутентифицированных и 200 анонимных пользователей (одновременно), приложение резко снижает свою производительность до полного отказа. Наибольшая нагрузка исходит от аутентифицированных пользователей, которые выполняют действия, вызывающие вставку / обновление / удаление на БД. Я думаю, что MySQL является узким местом. Это нормально, чтобы замедлить такое количество пользователей?

РЕДАКТИРОВАТЬ: я забыл упомянуть, что я сделал какое-то профилирование. Я запускал команды top, htop и они показали мне, что вся память используется MySQL! Через некоторое время MySQL начинает работать ужасно медленно, сайт отключается, и нам приходится перезапускать / останавливать apache, чтобы уменьшить нагрузку. Администраторы сказали, что на тот момент было около 200 активных подключений mysql.

Хуже всего то, что нам нужно решить это как можно скорее, я не могу провести глубокий анализ профилирования / рефакторинг кода, поэтому я рассматриваю 2 способа:

• мои таблицы MyIsam, я слышал, что они используют блокировку на уровне таблиц, которая очень медленная, верно? Могу ли я изменить его на Innodb без беспокойства?
• что если я возьму MySQL и перенесу его на выделенную машину с большим количеством оперативной памяти?

Answer 1

Невозможно указать конкретное количество пользователей, которое могло бы вызвать замедление работы любого случайного приложения. Это полностью зависит от того, что делает приложение и как оно запускается. Есть несколько вещей, на которые можно посмотреть.

1. Профиль. Запустите ваше приложение через профилировщик с максимально возможным использованием в реальных условиях. Лучше всего использовать автоматический тест или серию модульных тестов, которые проходят через все слои, чтобы сделать сеанс профилирования максимально повторяемым. Даже если вы профилируете свое приложение под более низкой нагрузкой, вы можете выявить узкие места и улучшить их. Вы должны профилировать как код приложения, так и код SQL.

2. Узкие места Профилирование скажет вам, какой код и / или запросы занимают больше всего времени, и исправление этих проблем очень поможет, но вы также хотите найти архитектурные узкие места, которых вы можете избежать. У вас есть пользователи, ожидающие записи, которые им не нужно ждать? Можно ли использовать очередь производителя / потребителя для постановки в очередь определенных некритических записей, чтобы приложение могло быстрее реагировать на запросы пользователей и лениво сбрасывать эти данные в БД. Существуют ли какие-либо длительные запросы, ожидающие других внешних ресурсов, которые могут извлечь выгоду из асинхронной обработки?

3. Кеширование Есть ли какие-то запросы или данные, которые можно кэшировать? Даже если это не является узким местом, максимально поможет снижение нагрузки на сервер. В частности, если у вас много конфликтов с базами данных и вы можете кэшировать некоторые часто используемые данные в приложении, тогда вы можете избежать некоторых обходов базы данных.

4. Данные памяти. Посмотрите, как ваше приложение использует базу данных, и посмотрите, есть ли что-то, что действительно не должно быть в базе данных. Если это так, перемещение этих данных в структуры данных в памяти (или даже в базу данных в памяти) значительно повысит производительность. Это обычно не возможно, но когда это так, это огромная выгода.

Answer 2

Быстрые заметки, как исправить вашу проблему

предложенный

• Отключить модуль статистики

• Удалите все не критичные модули

необходимое условие

• Установите APC - или что-нибудь подобное

• Включить кэширование Drupal, но не агрессивное

Опция 1

• Memcache + Memcache API - Установите Memcache API. Это разгрузит БД, обрабатывая сеансы для авторизованных пользователей.

Option2

• Cacherouter Установите Cacherouter. Это заменит кеш получает / устанавливает из БД в желаемую опцию (Memcache или, если у вас заканчивается память - файловая система)

• Кэш для авторизованных пользователей. Установите Authcache. Отлично работает с cacherouter, но только для 6x. Плюс это требует некоторого редизайна (но был проект под названием EasyAuthCache, который мог бы пригодиться)

• Обновление до 6.x В основном в версии 6.x есть несколько удобных модулей для разгрузки базы данных путем кэширования (и они очень помогут в этом случае). Я подозреваю, что ваш медленный выбор происходит из представлений.

Answer 3

Есть 2 важных числа, которые приходят мне в голову:

1. Точка ухудшения: Количество пользователей, когда приложения замедляются.
2. Точка разрыва: количество пользователей, которые вызывают сбой приложения.

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

Ваши комментарии указывают на то, что вы нашли точку деградации и считаете, что ваша база данных - это точка разногласия. Есть 2 параметра запуска MySQL, которые могут помочь вам проверить ваше предположение, а именно:
--log-медленно-запросы
--log-запросы-не-с использованием индексов-

Контролируйте свои процессы с помощью "ps", чтобы определить, какие из них потребляют больше памяти, а процессор - чтобы определить, какие части вашей архитектуры потребляют больше ресурсов. Еще одним хорошим подтверждением данных для вашего анализа будет вывод vmstat, возможно, каждые 60 секунд.

Короче говоря, запускайте мониторы с помощью ps и vmstat, нагружайте свое приложение, увеличивая количество пользователей, когда приложение замедляется, останавливайте свои мониторы и графически отображайте процессор и память процесса вместе с количеством активных пользователей на данный момент, с этой точки вы может определить, является ли ваша проблема ЦП или памятью, как только вы поймете, что вы просто выберете 10 лучших процессов для данного ресурса, и они будут кандидатами на конкуренцию. Просмотрите журналы MySQL, чтобы определить, куда можно добавить новые индексы, и определить, можно ли переписать некоторые из медленных запросов.