- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте. Суть проблемы заключается в том, что масштабируемость на сервере не может подняться более 64 страниц в секунду. Тестовый сервер работает при режиме работы LSAPI.
Точно такой же сайт, при режиме работы FastCGI(nginx + php-fpm) выдает масштабируемость более 800 страниц в секнду. Тесты проводим на 2-х выделенных серверах, с установленной ispmanager панелью. На одном установлена lite версия, на втором business c установленным cloudlinux.
Самое интересное что мы заметили, это то, что когда идет тестирование масштабируемости на FastCGI, нагрузка на сервере поднимается до 16-20la, а вот на сервере с LSAPI(cloudlinux) нагрузка не превышает 1-2 la, хотя все ограничения cloudlinux были отключены в панели управления с помощью команды:
db_governor - выключен.
Bitrix, как и любая другая система, может в любые лимиты упираться. Их много, от софтовых до хардовых. Что грузит процессор, какой процесс. Дальше смотрите strace.
slizh, кэширование-то отключено на обеих серверах?
Bitrix, как и любая другая система, может в любые лимиты упираться. Их много, от софтовых до хардовых. Что грузит процессор, какой процесс. Дальше смотрите strace.
На серверах стоит одна версия php, mariadb, выставлены все идентичные параметры. Разница только в режиме работы php.
Мы полагаем, что проблема именно в режиме работы LSAPI, и у него есть где-то ограничение.
---------- Добавлено 08.04.2019 в 10:34 ----------
slizh, кэширование-то отключено на обеих серверах?
Мы тестировали с кэшированием и без него на обоих серверах, разогнали процессор на обоих серверах т.к bitrix работает лучше при высокой частоте. Но все-равно на режиме LSAPI выше 64 масштабируемость не поднимается. На FastCGI идет до 1000, но среднее значение 800.
Возможно упираетесь в lsapi_backend_children
Возможно упираетесь в lsapi_backend_children
Пробовали увеличивать лимиты "lsapi_backend_children". Это еще описано в документации, но также не помогло.
В error_log смотрели?
глобальный и конкретно виртуалхоста
Я ещё бы включил debug в mod_lsapi