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