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

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 - но не агрессивное

Option1

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

Option2

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

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

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

Answer 3

Мне в голову приходят два важных числа:

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

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

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

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

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