Я пишу бизнес-план, и мне нужно смоделировать стоимость, когда мой сайт будет посещать 500 000 уникальных посетителей.
Каждая страница выполняет 50 запросов + -
Для выполнения этого расчета мне нужно выполнить 3000 запросов в секунду ... какой сервер может это обработать?
Проблема в том, что на самом деле мой сайт посещает 2000 человек в день и имеет - + 150/200 запросов в секунду ... начиная с этого момента, я ожидаю 50 000 запросов в секунду.
Сколько серверов в кластере или репликации справляются с этой задачей?
Раньше я работал в компании, занимающейся электронной коммерцией, с веб-сайтом, который посещал несколько миллионов страниц в день. У нас был один DELL PE 1750 с 2 одноядерными процессорами и 2 ГБ оперативной памяти, размер базы данных прибл. 4ГБ. В часы пик этот сервер обрабатывал до 50 тыс. Запросов в секунду.
Сказав это: база данных была хорошо структурирована, все запросы были точно настроены (у нас были еженедельные сеансы, анализирующие журналы медленных запросов и исправление запросов и индексов), а также настройка сервера. Кэширование - определенно хорошая идея, но MySQL все равно это делает, вам просто нужно проанализировать производительность, а затем точно настроить, как используется ваша память (кеш запросов по сравнению с другими параметрами).
Исходя из этого опыта, я могу сказать вам, что наибольшее влияние оказывают отсутствующие индексы, неправильные индексы и плохой дизайн базы данных (например, длинные строковые поля в качестве первичных ключей и тому подобное).
Все зависит от того, насколько сложен запрос, сколько памяти у серверов и насколько быстрые диски.
Если запросы очень простые или очень хорошо настроены, то с этим справится один большой сервер базы данных. Однако если запросы очень сложные (или простые, но плохо настроенные), вам понадобится несколько серверов.
Это действительно невозможно оценить, ничего не зная о конкретных запросах, которые вы выполняете, схеме базы данных и ее размере.
Простой SELECT для индексированного столбца: вполне другой зверь из пары JOIN, основанных на неиндексированных ... и, конечно, все сильно меняется, если задействованные таблицы содержат 1K записей или 1M.
Также:
Как заметил Игнасио, вы можете изучить кеширование. В cms или возможно даже перед стеком. 50+ запросов на каждую (каждую!) Страницу - это действительно много.
Судя по вашим комментариям, самым большим фактором будет размер вашего набора данных или, по крайней мере, размер «горячего» набора данных. 3 000 qps или даже 8 000 qps на 16-ядерном сервере вообще не проблема, если серверу редко приходится обращаться к диску, чтобы удовлетворить запрос. Как только активный набор данных превысит объем памяти, который InnoDB использует для его кеширования, ваша производительность быстро упадет.
Для больших «горячих» наборов данных, вероятно, стоит потратить время на преобразование в схему «больших данных», это то, для чего они нужны. Например, если вам нужно получить огромное количество данных, но вы никогда не переписываете, а только добавляете новые данные, взгляните на Apache Hive. Поищите вокруг, это обычно вариант, который вы можете достаточно легко связать с существующим кодом, что также предотвратит изжогу из-за нехватки места в кеше.
Слишком много вещей, которые могут повлиять на ваши запросы в секунду, пожалуйста, не доверяйте моим данным, не проверив себя. Я публикую свой результат теста скорости здесь, чтобы помочь кому-то оценить qps с текущей (2018-09) базой данных mysql и машиной. В моем тесте размер данных меньше памяти сервера (это резко снижает ввод-вывод и значительно повышает производительность).
Я использую один процессор 3,75 ГБ памяти, 100 ГБ ssd, экземпляр облачного сервера mysql gcp и получаю: