Странная история обнаружилась. Плагинов немного (все легкие, кроме Recall и Ultimate), сама тема (300.000 скачиваний) включает кучу настроек (файл css 1,5 Мб).
Сервер 8 Гб облако, 4 ядра у известного хостера.
Делаем нагрузочное тестирование через loader.io - при 30 одновременных входах на страницу срок ее открытия возрастает с 1,5 секунды до 6 секунд. Начинаются ошибки (от 5% до 17%, пару раз было 30%). Php очень долго обрабатывается. Вопрос 1. Кто-то тестировал работу плагина при высоких нагрузках? К сожалению, уже нет возможности деактивировать его (3500 страниц он скрывает). Насколько сильно именно работа плагина сказывается на загрузке страницы?
Вопрос 2. Если ставить плагин кэширования, то А) юзеры "не могут" авторизоваться (хотя, система приняла их данные) - после ввода логина и пароля видят ту же страницу для неавторизованных (висит кнопка Авторизоваться вместо имени автора, комментарии не видны и т.п. вещи для авторизованных); Б) после авторизации юзер видит страницу со скрытым контентом в таком же виде как неавторизованные: то есть видит не контент, а текст, предлагающий авторизоваться и купить. А авторизованный ранее юзер, оплатив, видит страницу для оплаты, а не контент. Кто-то сталкивался с такими проблемами, как боролись?
По сути кэширование нужно отключать, иначе оно скрывает 3500 страниц для оплативших. Но без него сайт падает уже при 35-40 одновременных входов (сейчас на другой платформе у нас одновременных входов (в секунду - в момент выхода новой статьи / новости) около 350-400. В ближайших планах около 1.000. При кэшировании ВП это держит, без кэширования только 15-17 - чистыми без ошибок и со скоростью загрузки около 3 секунд на страницу (это "предел терпения" юзера).
Ребята, если кто-то знает, куда копать, чтобы сайт нормально открывался при большом количестве пользователей (одновременный вход на одну страницу - это происходит при рассылке уведомления), направьте, пожалуйста, на путь истинный. Я понимаю, что дело может быть совсем не в плагине (просто, пытаюсь понять и узнать другой опыт использования данного плагина). Спасибо.
Андрей, если поделитесь пиковыми нагрузками Вашего сайта (в секунду), буду очень благодарен. Он же ж работает на Ultimate.
Я могу допустить, что в режиме скрытия публикаций из выдачи может наблюдаться нагрузка, тк для скрытия нужных публикаций функционал должен выяснить к каким именно публикациям текущий пользователь доступа не имеет, чтобы исключить их из цикла WP, это может быть затратно для ресурсов сервера.
Думаю, можно включить кеширование для гостей, а для авторизованных пользователей отключить его, только так функционал будет работать корректно.
Пиковые нагрузки для этого сайта - >150 секунду, конфигурация: 1 гб, 2х2,4 ггц, кэширование не используется
Спасибо за ответ, Андрей.
Я пробовал отключать кэширование для авторизованных. Это работает. К сожалению, при выходе новости / статьи юзеры впервые секунды массово заходят (а юзеров несколько тысяч). 40 авторизованных зайдя одновременно (в секунду) просто положат сайт 🙁
Не знаю, куда копать. Просто смешно, что такой сервер держит нормально всего 15 одновременных входов ... Видимо, в облаке хостер режет очень сильно 4 ядра на всех.
Здравствуйте.
Вставлю свои 5 копеек.
Дело в том что в e-commerce и других областях связанных с финансами, с какими-то разграничениями прав и привилегий ни в коем случае нельзя отдавать кеш залогиненному пользователю.
Я так понимаю у вас самый простой вид кеширования - страничный. В high load всегда кешируют объектами. И к кешу объектов подходят с умом. Например никогда не кешируют все что связано с балансом и финансами. Можно кешировать виджеты: кто онлайн, кто недавно был в сети, последние записи и комментарии. Но в случае последних 2х вы столкнётесь с вероятностью показать запись (пусть даже заголовок и краткое вступление), или не нужный комментарий. т.е. такие вещи они очень индивидуальны и не делаются с помощью одного магического супер плагина кеширования. high load это всегда привлечение специалиста в этой области. Он настроит вам кеширования - это индивидуальный подход. Такой специалист должен понимать в серверных механизмах (redis, memcached), должен понимать принципы такого интересного бага как race conditions, дабы при настройке не допустить такого эффекта когда данные списались - но из-за кеша произошло это вникуда или произошло 2 события, но в бд зафиксировалось одно. Конечно они будут проводить нагрузочное тестирование самостоятельно и устранять узкие места.
У вас выхода 2: отключать кеш для залогиненных и наращивать мощности. Это дорого и постоянно
или нанять специалиста по high load который вам настроит всё как нужно. Это дорого - но работы не постоянные.
p.s. вы говорите о пиках ,когда выходят новые записи. Значит надо пуши или рассылки не выдавать разом - а разносить порциями. Этим 1000 пользователей немедленно. Следующей пачке юзеров спустя некоторое время. А может быть есть смысл вводить понятие не подписки на отдельную запись, а на дайджест в конце недели. Пусть пользователи сами выбирают какие виды доставки им удобней.
dm1 сказал(а)
Делаем нагрузочное тестирование через loader.io - при 30 одновременных входах на страницу срок ее открытия возрастает с 1,5 секунды до 6 секунд. Начинаются ошибки (от 5% до 17%, пару раз было 30%)
а вы делали тоже самое но с дефолтной ВП темой? Если тема монстр - с такими то объемами css я полагаю у нее и настроек вагон (а т.к. таблица wp_options по умолчанию с флагом autoload true - то вся масса настроек ложится в оперативную память. Это проблема если юзеров много). И конечно не показатель, что тему качали 300 000 раз. Это могут быть мизерные сайты которые не работают на высоких нагрузках. Вообще все high load проекты пишут свои темы т.к. именно они источник боли. Вы в теме уже настроили всё как надо - а значит что у вас есть 100% требований к теме. Наймите того, кто сделает вам реплику темы с отсутствием тонны настроек и вагона css/js. Есть студии или отдельные ребята которые именно этим занимаются.
Otshelnik-Fm сказал(а)
У вас выхода 2: отключать кеш для залогиненных и наращивать мощности.
Да, вот, хотелось бы понять, даст ли прирост железа решение проблемы или хотя бы такой же линейный прирост производительности.
Уведомления, в ту же секунду уходящие одновременно всем, отключить не можем. Ибо это основа бизнес-модели - скорость получения финансовой информации.
Код пока оптимизировать то же не можем (лишнее из css убрать). Так как, как только юзеры поработают на сайте пару месяцев, станет понятно, что им интересно, что нет, где лучше, что поправить - после этого уже буду "лицо" сайта допиливать. Поэтому пока настройки убрать нельзя. И да, их не просто много, очень много (больше 1000 - для каждого вида каждого параметра любого блока, которых больше 50, для разных гаджетов и т.п.).
Оффтоп.
Одним из элементов, сдерживающих загрузку главной страницы, еще гугл-анализатор показывает:
>>> ... rcl-awesome/rcl-awesome.min.css?ver=5.1.1
ВПРеколл я использую только ради работы Ultimate, платежей через Яндекс и создания поста. Больше его внешне нигде не видно (ЛК юзерам не доступен). Можно ли как-то отключить этот rcl-awesome.css? Чтобы он не подгружался (если это не создаст рисков для работы системы).
Андрей CS сказал(а)
Выпустил обновление 1.7.4, в нем оптимизирована проверка привилегий пользователя на одиночной странице.
Андрей, обновился. Теперь страницы со скрытым контентом, которые должны показывать форму оплаты, показывают ошибку 404.
Перестал срабатывать пункт Настроек: "Порядок скрытия из выдачи". Стоит "Только на архивных страницах" и не работает. Поправьте, пожалуйста.
Спасибо. Потестировал еще раз loader.io.
Сделал 12 тестов для 3 страниц (главная, статья без картинок и статья с картинками) ДО и ПОСЛЕ обновления плагина (по 2 теста на каждый вариант).
Улучшение скорости загрузки около 2-4%. Среднее время загрузки лучше на 2%. И максимальное время загрузки лучше на 4%.
Дождусь, когда в репозитории ВПРеколл появится обновление 1.7.5 и буду рыть дальше.
Спасибо всем огромное за помощь и подсказки.
Андрей, еще один вопрос. Не тестировали плагин Ultimate с известными плагинами кэширования? Или, возможно, знаете, о чужом опыте. Не может произойти так, что первым зайдет в платную (скрытую) статью - юзер, у которого есть доступ, и в кэше сохранится платный контент. Далее анреги или авторизованные без платного доступа будут видеть платный контент, обращаясь к этой странице следом за платным юзером?