Что будет при подключении около трех тысяч сторонних модулей на сайте?
Надеюсь правильно указал теги...
Добрый день!
Вопрос таков.
Есть сайт к которому нужно привязать большое количество сторонних модулей. Тремя тысячами может не обойтись.
Нужны модули типа чата с поддержкой, сторонних модулей типа бронирования мест в самолете.
Допустим на одном сайте будет таких модулей ну просто огромнейшее количество и при этом будет большой онлайн.
Будет ли сайт выдерживать нагрузки от посетителей, учитывая тот момент, что будут одновременно пользоваться всеми модулями на сайте? И скажется ли вообще такая работа на нагрузку сайта? Вроде бы сервисы сторонние, но работа одновременно нескольких тысяч таких модулей на одном сайте наводит на вопрос...
Нужно экспертное мнение.
Сам не технарь, заранее прошу прощения если что-то указал не так.
Пишите дополнительно, если будут уточняющие вопросы.
Леонид Роженцев, Сайт у нас построен на битриксе вообще, но мы хотим избавиться от этого монстра и перейти либо на Laravel, либо October CMS (он тоже на Laravel построен). Что думаете по этой технологии?
DevUse, смело выбирайте october cms или laravel (особой разницы нет). Оба движка отлично подойдут для проектов любой сложности. Если хотите, могу посоветовать специалистов, которые вам сделают перенос сайта с bitrix на laravel/october
Леонид Роженцев, Пока не хочу лишний раз сторонние ресурсы привлекать.
Идёт согласование по работам и окончательного принятия решения пока нет.
Но то, что явно стоит смотреть в сторону Laravel как возможность сделать высоконагруженный сайт, это приму во внимание и переговорю со своими партнёрами.
Леонид, как думаете, если эти сторонние модули привязаны к другим источникам и они не связаны будут с будущим сайтом (кроме как отображения), может ли вообще одновременная работа огромного количества модулей сказаться на сайте, который их только отображает? Или какие могут быть подводные камни в таком решении?
DevUse, October недавно перестал быть бесплатным, что раскололо его сообщество и испортило перспективы. Будьте осторожны.
Если у вас портал будет делать все подряд и заодно приносить кофе, сразу имеет смысл максимально изолировать "модули" друг от друга, вплоть до выделения их в отдельный сервис с внешним API. Так при увеличении нагрузки вы сможете разнести их с одного сервера на разные.
Но как раз предположение о тысячах модулей на одном сайте наводит на другой вопрос... вы вообще понимаете, что планируете?.. Больше похоже на "хочу сделать свой фейсбук с букингом, подскажите бесплатный хостинг".
DevUse, что касается сторонних модулей, то если они не будут связаны с сайтом, то почему бы их не удалить? К тому же при переписке на laravel нужно будет менять архитектуру проекта
Adamos, Добрый день, ваш вопрос логичен)) И спасибо за уточнение по October.
Но то, что мы планируем, ясно видим перед собой. Вопрос только в том, каким образом будет реализовано и какой вариант будет максимально практичен из возможных.
Если касательно моего вопроса у вас есть экспертное мнение или версия как это можно реализовать, то буду рад выслушать. В дальнейшем как всё согласуется и будут рассмотрены варианты, готовы будем предложить сотрудничество. Наша задача не только разобрать этот вопрос, но и найти исполнителей для реализации функционала.
Леонид Роженцев, Ну если можно назвать связью работу с модулем и выбор мест в самолёте, то это всё же связь.
Интересует вопрос, как распределяется нагрузка на сервера у сайтов, которые имеют большое количество модулей...
DevUse, то, что заказчик "ясно видит перед собой", может вынудить исполнителя рвать на себе волосы от бессилия объяснить, что в этой вселенной это невозможно ;)
Экспертное же мнение, высказанное на основании столь скудных данных, можно выбрасывать на помойку, не читая.
Adamos, То что видит заказчик, не всегда реализуемо и может быть не так. Это я знаю не по наслышке)
Со мной разработчиком приятно работать (говорю по их фидбэкам). Как раз за это меня и оценили, что стараюсь понимать их и вести проекты.
Как я и писал в вопросе, "Пишите дополнительно, если будут уточняющие вопросы.". Чтобы можно было детально разобрать всё и разложить по полочкам.
Значит не до конца прочли моё сообщение)), раз акцентируете внимание на скудных данных)
Мы с коллегами получили версии ответов и то, как может быть реализован функционал.
Будем копать дальше.
Доброго дня)
DevUse, я дочитал, но сам вопрос беспредметен, как "хватит ли мне автобуса, чтобы развести работников со смены". Уточнять нужно - вообще все ;)
Насчет реализации функционала все-таки еще раз посоветую не городить комбайны по образцу Битрикса, с ними трудно жить, если правда повезет с нагрузкой. Те же места в самолете может раздавать совершенно отдельный сервер, ему нужно только передать порцию действительно нужной для этого дела информации и получить в ответ другую порцию. Совершенно незачем глубоко интегрировать его в какую бы то ни было CMS. От неповоротливости сильно связанных монстров, увы, не спасает никакая архитектура.
Adamos, Хорошее замечание. Спасибо вам, что потратили время на меня и объяснили. И чтобы в будущем не сделать "комбайн" как Битрикс, будем следить и не допустим этого. Мы наоборот хотим от подобных монстров избавиться. Передам всё своим партнерам и будет думать как сделать лучше! Спасибо ещё раз )
Вам не вопросы надо на Тостере задавать, а написать ТЗ и получить предложения компаний или, хотя бы, фрилансеров с подтвержденным опытом успешной разработки проектов такого же масштаба.
Подключить можно и десять тысяч модулей, и в зависимости от количества работы каждого модуля в одну и ту же секунду, мощности сервера, разница может быть от "все летает" до "система навернулась и подниматься не хочет"
Большой онлайн у разных людей это тоже разные цифры.
Ваш вопрос явно не подходит под этот ресурс. Нужно либо полная конкретика со всеми уточнениями, а тогда это тянет на полноценное обсуждение ТЗ с правками.
Либо задавать более простые технические вопросы.
По вашему вопросу - если модули интегрировать как независимые сервисы, их можно будет впоследствии разнести на разные машины, позволяя масштабировать как угодно. Как именно все это будет интегрировано - лучше с исполнителем согласовывать.
Средний
Средний
