Вот например https://www.avito.ru/sankt-peterburg/noutbuki/nout... Я на подобном (на самом деле даже слабее, был i3) программировал вплоть до 2016 года. У ленов известная проблема — слабые петли. Если на этом сломались — клеевой пистолет, два болта с гайками + паяльник и у тебя всё хорошо.
Если не авито, то есть разные локальные доски объявление в вк
Shandy, бп — это последняя проблема, о которой стоит переживать. Павербанк может и подойдёт, но как ты себе представляешь свои действия? Вот пришёл ты на пару, из рюкзака вытаскиваешь: малину, клавиатуру, мышь, банку, экран, всё подключаешь, занимая половину аудитории. Экран надо как-то держать, всё плывёт, потому что корпуса нет, в глазах всё плывёт, потому что не возьмёшь же ты экран 10+ дюймов для малины (а если возьмёшь, какой и как его питать?).
В общем, если хочется погрызть кактус — лучше взять устройство, которое собрано не руками из известно чего и палок, а заботливыми китайцами — карманный ноутбук, нетбук или что-то подобное.
Но лучше, конечно, взять живой б/у ноут с любого авито, это будет дешевле и удобней
cicwak, можно ещё сэкономить, хотя на одном объекте экономия вряд ли будет. Заменить Names.objects.get(name=name).count на Names.objects.values_list("count", flat=True).get(name=name)
Это позволит джанге не строить тяжеленные объекты её ORM
Лентюй, Я исхожу из данных, которые мне дают. ТС сказал — 12кк просмотров в день, значит это 12кк просмотров в день. Значит, он уже как-то прикинул среднюю глубину просмотров, оценил сезонность и в целом что-то сделал, чтобы эту цифру получить. Я оперирую ей. Ты не отвечаешь на вопрос ТСа, а говоришь, что он ошибся в расчётах. Это вполне может быть правдой, это даже скорее всего правда. Но ты отвечаешь на вопрос, который ТС не задавал.
kot999, монолит монолиту рознь. Если писать проект в виде монолита в его классическом, неверном и негативном понимании, то да. Но в этом случае и (микро)сервисы ничего хорошего не сулят кроме дополнительных проблем в виде распределённых транзакций, необходимости оверинжиниринга в виде кубернетисов на пустом месте, лагов сети, ретраей и всего такого, что очень свойственно распределённым системам.
Если же монолит воспринимать как композицию сервисов в модулях, придерживаться чистой архитектуры, то проекту будет вообще плевать, как общаются между собой сервисы — внутри одного процесса, по шине событий, по HTTP или по gRPC, это всё легко отделяется от монолита чуть ли ни копипастой модуля в соседний репозиторий, а на его месте останется делегат, который будет реализовывать взаимодействие. В этом случае монолит имеет много преимуществ перед горячо любимыми всеми "микросервисами". И микросервисы начнут выигрывать только в случае, когда компания станет гигантом
12_000_000 / 24 = 500_000 в час
500_000 / 60 = 8_333 в минуту
8_333 / 60 = 139 в секунду
Но распределение запросов далеко не равномерное и пик, куда входят ~70-85% запросов приходится на дневные 4-5 часов. Таким образом,
(12_000_000 * 0.7) / 5 / 3600 = 466 RPS в лучшем случае
(12_000_000 * 0.85) / 4 / 3600 = 708 RPS в нормальном случае
708 * 2 = 1416 RPS — вполне возможные всплески
Конечно, тут стоит вопрос о достоверности этих 12 миллионов в сутки, но мы же исходим из того, что верим автору вопроса, а не что это очередной стартап, который загнётся на первой тысячи посетителей, а команду разгонят ссаными тряпками
N, если вопрос ставится "какой стек взять", видимо, не подразумевается, что команда уже есть и команда пишет на PHP. Резонно взять изначально лучший инструмент, под него собрать команду, которая уже будет уметь использовать этот инструмент. Если команда есть, то ответ всегда "пишите на чём умеете", это здесь обсуждалось раз тысячу точно.
Если рассматривать golang не как "крутости для повышения RPS", а как основной рабочий инструмент на замену PHP, то не вижу проблемы. Golang даёт всё то же, что даёт PHP, только даёт ещё кучу плюшек сверху в виде лучшей производительности, хорошей системы типов и т.п. На го на проблемы горизонтального масштабирования приложения можно забивать гораздо дольше, а это важно для стартапа — писать код, а не думать о том, как его ускорить, оптимизировать так, чтобы он утилизировал все ресурсы или "переписать высоконагруженные части", потому что gateway timeout или service unavailable.
Если быть честным, то и бизнес-логику на го писать удобней, чем на том же питоне. Даже из-за типизации. А то что го в ~40 раз быстрее выходит на CPU задачах — приятный бонус
