Какой стек технологии выбрать для сайта объявлений с посещаемостью до 500.000 в день?

Question

[Fifeco]

Привет! Мы хотим создать сайт объявлений с нуля, для страны с небольшим населением (~ 5 миллионов) ․ Ожидается 200-500 тысяч посетителей в день (до 10-12 миллионов просмотров страниц в день)․ 1-2 миллиона активных объявлений. Речь идет о максимально возможной посещаемости, которая прогнозируется в будущем.

Основные возможности сайта такие же, как на платформах Avito или Olx.

Хочу услышать мнения экспертов о том, какие технологии и языки программирования рекомендовали бы использовать для создания системы. Мы хотим с самого начала выбрать правильное направление, чтобы через год не столкнуться с проблемой перепрограммирования с нуля. Очень важно скорость работы ресурса.

Мы рассматриваем язык программирования PHP и фреймворк Laravel, но опасаемся, что Laravel будет работать очень медленно в случае такой посещаемости.

Финансирование есть, небольшое (~ 8000 долларов в месяц).

У нас есть 1 год на первоначальную версию сайта.

У проекта есть отдельное финансирование за рекламу и маркетинг, так что с этим проблем нет. Посещаемость точно будет.

Заранее извиняюсь за безграмотный русский, это мой второй язык. Заранее спасибо

Comments

[Денис Юрьев]

как правило, медлено работают не фреймворки, а говнокод на который их натягивают

[Дмитрий]

Начните с ларавель, первая версия нормально получится, специалистов много, хотя их качество не всегда топ

[FanatPHP]

следующий вопрос автора:"у меня в базу данных объявление не добавляется, подскажите, отчего это может быть?"

[Fifeco]

Прочитал все комментарии. Спасибо за активное участие. Хочу добавить несколько фактов.

Данные берутся из цифр, что в той же стране есть сайт, который функционально очень скромен (очень простой, имеет несколько возможностей и все) ․ Эти числа взяты из данных о посещаемости этого сайта + прогноз, что добавление некоторых функций приведет к определенному увеличению трафика (подсчитано, что сайты объявлении имеют больше трафика каждый год).

Я в курсе, что Avito использует PHP.
Имею опыт программирования на PHP (простые сайты).
На мой взгляд, основные функции сайтов объявлений не представляют своих сложных функций, и, на мой взгляд, PHP полностью удовлетворяет этот тип функций. Разработка вебсайтов на PHP происходит быстрее, чем, например, на GoLang или Java.

Я понимаю, что такие посещения невозможны с первого дня. Но по крайней мере хотелось бы сделать правильный выбор языка. Если нам нужно переключиться на другой язык программирования с определенной посещаемости, лучше начать с этого языка с самого начала.

Мы имеем в виду вариант горизонтального масштабирования, но мы не хотим, чтобы это масштабирование привело к очень высоким затратам в будущем из-за неправильного выбора языка.

Сотрудников пока нет! После выбора технологий мы должны найти соответствующих специалистов.

Когда я говорю, что мы можем потратить 1 год на программирование, я имею в виду, что мы можем профинансировать столько времени только для того, чтобы получить хороший сайт. Смысл того, что я сказал, в том, что средств хватит на это время.

Что касается финансирования. Программную часть финансирую из собственных средств. Маркетинг и рекламау финансируется моим партнером.

[Сергей Горностаев]

Fifeco,

Я в курсе, что Avito использует PHP.

А так же Go, Python и Java. И всё это поверх сложной инфраструктуры, которая как раз и обеспечивает работу под нагрузками.

[Boris Köln]

Данные берутся из цифр, что в той же стране есть сайт..․ Эти числа взяты из данных о посещаемости этого сайта

У-у-у, какие мы оптимисты! Все эти люди сразу же всё бросят и побегут к вам?

+ прогноз, что добавление некоторых функций приведет к определенному увеличению трафика

Где-то я это уже видел...

Answer 1

[Lillipup]

но опасаемся, что Laravel будет работать очень медленно в случае такой посещаемости.

А вдруг не будет такой посещаемости?
Я б выбрал laravel, потому что преждевременная оптимизация — корень всех зол.

Comments

[Roman K]

Лентюй, удивляюсь, как люди умудряются цитату про экономию байтиков приплести в виде оправдания говнокоду

[Lillipup]

Roman Kitaev, Где я призывал говнокодить? Я имел ввиду, что сейчас нет смысла переживать о большой посещаемости, когда даже mvp не готово.

[Александр Фалалеев]

ИМХО - да пофигу на стек технологий - в чём лучше разбираетесь на том и делайте.
С такой посещаемостью всё-равно придётся кластер серверов ставить, а там уж без разницы n серверов или n+1 будет :)

Answer 2

[Roman K]

Зачем брать PHP для создания с нуля?

12млн просмотров в день, если вспомнить типичное распределение нагрузки, выльется в пиковые 500-1500 RPS. При этом, большая часть времени будет тратиться на ожидание IO — базы данных и кэши. Что уже говорит о том, что язык должен поддерживать асинхронность, гринтреды, акторы или что-то подобное. Причём, 1000 RPS — это уже достаточно много, чтобы задумываться об оптимизациях и, возможно, горизонтальном масштабировании. И это, пожалуй, единственное требование для вашего продукта.

Я бы брал Golang, как хороший компромисс между производительностью, надёжностью и скоростью разработки. Но нужно понимать, что плохо написать можно на любом инструменте.

UPD.
Я не рассматриваю Golang, как "преждевременную оптимизацию", а наоборот, как инструмент, который позволит отсрочить необходимость оптимизации.

Comments

[N]

Если учесть, что проект "с нуля", то мне кажется наоборот нужно упор сделать на бизнес-логику приложения, а потом уже "вводить" все эти "крутости" для повышения RPS...
А то выйдет так, что они будут больше времени тратить на изучение всяких других технологий(тот же Golang) и при этом толкового ничего получаться не будет...а на том же PHP вполне реально под такие нагрузки делать проекты...вопрос в том: смотря как готовить...

Тот же AVITO, точнее основная бизнес-логика, написан на PHP...а какие-то части (высоконагруженные) вынесены на другие языки (в том числе и на Golang)...

[Roman K]

N, если вопрос ставится "какой стек взять", видимо, не подразумевается, что команда уже есть и команда пишет на PHP. Резонно взять изначально лучший инструмент, под него собрать команду, которая уже будет уметь использовать этот инструмент. Если команда есть, то ответ всегда "пишите на чём умеете", это здесь обсуждалось раз тысячу точно.

Если рассматривать golang не как "крутости для повышения RPS", а как основной рабочий инструмент на замену PHP, то не вижу проблемы. Golang даёт всё то же, что даёт PHP, только даёт ещё кучу плюшек сверху в виде лучшей производительности, хорошей системы типов и т.п. На го на проблемы горизонтального масштабирования приложения можно забивать гораздо дольше, а это важно для стартапа — писать код, а не думать о том, как его ускорить, оптимизировать так, чтобы он утилизировал все ресурсы или "переписать высоконагруженные части", потому что gateway timeout или service unavailable.

[N]

Roman Kitaev, Это всё имеет место быть. Но, я думаю, не зря отмечен тег - PHP...

[N]

Лентюй, "Там" - это где?)
Если в будущем проекте автора вопроса, то мы "изначально верим в успех посещаемости" :)
От этого и "пляшем" :)

[N]

Лентюй, Будет или не будет...ответ всё равно один: что умеете лучше готовить, то и готовьте... :)
Я по простому сужу.

[Roman K]

Лентюй, простая математика:

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 миллионов в сутки, но мы же исходим из того, что верим автору вопроса, а не что это очередной стартап, который загнётся на первой тысячи посетителей, а команду разгонят ссаными тряпками

[Roman K]

Лентюй, Я исхожу из данных, которые мне дают. ТС сказал — 12кк просмотров в день, значит это 12кк просмотров в день. Значит, он уже как-то прикинул среднюю глубину просмотров, оценил сезонность и в целом что-то сделал, чтобы эту цифру получить. Я оперирую ей. Ты не отвечаешь на вопрос ТСа, а говоришь, что он ошибся в расчётах. Это вполне может быть правдой, это даже скорее всего правда. Но ты отвечаешь на вопрос, который ТС не задавал.

Answer 3

[Ромзес Панагиотис]

Если будет хорошо продумана архитектура и грамотно реализовано, то язык имеет не первостепенную роль. Как уже уже было отмечено, асинхронность - важный атрибут в работе с ресурсами.
Не нужно стремиться к идеальному стеку технологий. Начните с Laravel или другого фреймворка и решайте проблемы по мере их поступления. Но важно заранее планировать работу всех компонентов и иметь в развитии видение системы.
По мере роста посетителей сможете заменять проблемные участки кода и улучшать.

Answer 4

[Konstantin]

Как сказал коллега выше - преждевременная оптимизация - корень всех зол. Вопрос не в языке и не в фреймворке. Каждый из современных языков и фреймворков можно оптимизировать. Возьмите то, с чем вы будете испытывать меньше трудностей. Можно ведь пилить бесконечно идеальный продукт, и никогда его не выпустить. Fail fast, fail cheap.
Оптимизацией лучше заниматься тогда, когда возникает в этом необходимость и там, где возникнет эта необходимость. Пилить сразу большой проект на чистом GO, я думаю будет очень сложно человеку, не знакомому с языком, и возможно не знакомому с инфраструктурой микросервисов. Go это ведь не только синтаксис. Да и даже в больших проектах на GO выносят только отдельные микросервисы, требующие оптимизации. (*так по крайней мере было на моей практике).
за 8к вы точно не найдете достаточно программистов чтобы пилить приложение на go-микросервисах, k8s эксперта который правильно будет деплоить и поддерживать k8s инфраструктуру вместе с ci-cd. А если всем заниматься самому, то хорошего из этого ничего не выйдет, глаз начнет дергаться.

Comments

[Roman K]

Но ведь k8s, микросервисы и инфраструктура быстрее понадобится php, чем го

[Konstantin]

Если вы предлагали писать монолит на GO, мне кажется вы переоцениваете его, не лучший подход.

[Roman K]

kot999, монолит монолиту рознь. Если писать проект в виде монолита в его классическом, неверном и негативном понимании, то да. Но в этом случае и (микро)сервисы ничего хорошего не сулят кроме дополнительных проблем в виде распределённых транзакций, необходимости оверинжиниринга в виде кубернетисов на пустом месте, лагов сети, ретраей и всего такого, что очень свойственно распределённым системам.

Если же монолит воспринимать как композицию сервисов в модулях, придерживаться чистой архитектуры, то проекту будет вообще плевать, как общаются между собой сервисы — внутри одного процесса, по шине событий, по HTTP или по gRPC, это всё легко отделяется от монолита чуть ли ни копипастой модуля в соседний репозиторий, а на его месте останется делегат, который будет реализовывать взаимодействие. В этом случае монолит имеет много преимуществ перед горячо любимыми всеми "микросервисами". И микросервисы начнут выигрывать только в случае, когда компания станет гигантом

[N]

Roman Kitaev, Да в любом "стеке" решают архитектура и умение всё это готовить...поэтому можно не спорить тут никому...все правы в какой-то степени...

Качественный монолит всегда можно распилить на "микро"...

Answer 5

[Леонид]

основная проблема будет не на чем делать сайт а как раскрутить для такого количества поетителдей
Я уже не говорю что людям которые не знают какой стек выбрать вряд ли стоит начинать делать такой сайт

Comments

[Fifeco]

Мне нужен совет от того, у кого есть опыт. Тогда зачем задавать вопросы здесь? Иногда теория и практика не совпадают. Дело не в том, что я не знаю что выбрать. Просто хочется усилить разные мнения и обозначение этого.