Поскольку, присутствует вариант конфигурации 2 ядра до 5 ГГц, то стоит рассмотреть данный вопрос в двух плоскостях: теоретической и практической. В контексте старый, но жирный и современный, но урезанный.
В теоретической плоскости надо смотреть на характер нагрузки:
1. Требуется ли специфичные вычисления, например AVX2 инструкции, шифрование и т.д., если да. то лучше взять современное железо, иначе же прироста в 5Ггц не будет много. В данном случае (CMS), скорее 2 вариант подойдет.
2. Требуются ли сложные однопоточные вычисления? Например, какой-то сложный алгоритм обработки запроса, и т.д. если да, то одно производительное ядро будет лучше, чем много слабых, В данном случае (CMS), тоже, скорее 2 вариант
3. Сколько параллельных запросов выполняется? Запрос включает в себя обработку веб сервером, бэкендом, СУБД и т.д. Если требуется обработать десятки-сотни запросов в секунду (RPS), то лучше больше слабых ядер, чем мало производительных т.к. переключение контекста тоже занимает определенное время, по моим тестам до количества ядер производительность растет практически линейно, дальше количество параллельных потоков начинает тормозить общую производительность, не сильно, но 10 потоков выполнения на 1 ядро съедает под 30% общей производительности. В вашем случае (3000 DAU) скорее всего, хватит трети 2 конфигурации, но под потенциальный рост количества пользователей лучше 2 вариант
4. Количество обрабатываемых данных, если требуется активная работа с оперативной памятью, то 1 конфиг будет быстрее за счет более современного стандарта памяти, но 10ГБ RAM позволит хранить в памяти больший кусок базы данных, файлового кеша, и не обращаться к диску каждый раз, 2ГБ даже с быстрым процессором при сопоставимой нагрузке будет постоянно нехватать, свопиться, вычитывать данные из БД и чаще скидывать записи на диск + каждый запрос пользователя это RAM, на 3000 DAU не критично, а вот на 3000 пользователях онлайн 10ГБ оперативки будет давать стабильную производительность по БД, а вот 2ГБ начнет "колбасить" при большом количестве JOIN в запросах и большом количестве записей в таблицах. У меня были случаи, когда запросы к БД начинали обрабатываться 10 секунд вместо 50мс как раз таки за счет того, что СУБД начинала сбрасывать на диск промежуточные вычисления. На будущее, 2 вариант лучше
Практическая составляющая:
1. Буквально на днях вышла статья на пикабу на тему того, что хостер продает старые процессоры под видом новых (в системе виртуализации можно передать любые значения в гостевую машину), т.е. вместо 2 ядер по 5ГГц есть шанс получить 2 ядра по 3.2ГГц, да и 5ГГц в бусте тоже не факт, что можно получить если это не выделенный сервер.
2. Для VPS в отличие от дедиков (выделенных серверов) часто есть лимит про процессору (т.к. его продают по нескольку раз - читаем теорию массового обслуживания), часто можно получить максимальную мощность в течение короткого времени (секунды - минуты), а если грузить процессор под 100% все время, то либо отключат виртуалку, либо снизят произвоодительность до 10-15-20% - если это не ваш личный сервер с известными вам характеристиками турбобуста процессора, то за несколько тысяч рублей в месяц ожидать, что ваши арендованные 2 ядра будут часами жарить на 5ГГЦ как минимум странно.
По поводу нагрузки и масшабирования
- На 1 пользователе отдавать страницу будет быстрее 1 вариант за счет теоретически более быстрого однопоточного режима (но, я бы сказал, что в браузере это будет условно 248 мс вместо 250-252мс, т.е. с учетом сетевых расходов, работы планировщика ОС, и т.д. конечные гигагерцы имеют не такую разницу), но учитывайте практическую часть ответа.
- На десятках пользователей онлайн уже 2 вариант может быть немного быстрее (особенно за счет большего количества оперативной памяти)
- На сотнях пользователей 2 вариант будет стабильней и быстрее
Но сказать конкретно сейчас сложно т.к. надо проводить нагрузочное тестирование конкретной конфигурации железа и софта с конкретной версией ПО и конкретным набором данных, но, лично из моей практики - если это простой сайт, а не сложный IT проект с кучей серверов, то выбираем хостинг с возможностью легкой смены тарифа и начинаем с условных "2 ядря 2 гига", а потом по мере роста нагрузки добавляем ресурсы, нормальные хостинги позволяют вертикально масштабироваться (увеличением мощности, а не количества) по каждому из ресурсов (RAM, CPU, HDD) отдельно и при перезагрузке, отстающие имеют жеские тарифы (у нас не хватало места под файлы и приходилось покупать еще и CPU, т.к. каждый следующий тариф имел всего больше) и требуют не только перезагрузки, но и переноса конфигурации, соответственно даунтайм уже не минуты, а часы. Поэтому гибкие тарифы у современных хостеров рулят и масштабироваться легче. (я не говорю тут про поднятие кубера с балансировкой, автоскейлингом, грин-блю деплойментом и прочими фишками доступности 99.9999%)
