|
|
|
| Интересно было бы узнать, на каком языке пишется CMS типа той, что используют http://professionali.ru/ (300 тысяч просмотров и 25 тысяч постов в день, 4 миллиона пользователей)?
В какую сумму может обойтись разработка такой системы?
Сколько серверов нужно для обслуживания такой системы? | |
|
|
|
|
|
|
|
для: Владимир55
(05.03.2013 в 16:25)
| | Такие вещи проще на FrameWork-ах и то не всегда, любая готовая система шаг в определенную строну, не всегда туда, куда нужно.
Серверов меньше сотни. При остром желании можно в 10 уложиться (от мощности серверов зависит).
>В какую сумму может обойтись разработка такой системы?
Команда нужна под это, просто суммы денег мало. | |
|
|
|
|
|
|
|
для: cheops
(05.03.2013 в 19:50)
| | "Серверов меньше сотни. При остром желании можно в 10 уложиться "
А если делать на РНР, то, вероятно, и сотни серверов будет недостаточно?
>В какую сумму может обойтись разработка такой системы?
Команда нужна под это, просто суммы денег мало.
Большая команда? Дело на год растянется?
А если сделать масштабирующуюся систему?
Сначала на РНР и на одном сервере. Тысяч до 50 посетителей он потянет. А потом, по мере разрастания базы и усложенния функционала, фрагментарно заменять наиболее нагруженные области кода на более быстрые решения, и добавлять серверов. Это разумно? Или утопия? | |
|
|
|
|
|
|
|
для: Владимир55
(06.03.2013 в 11:18)
| | >А если делать на РНР, то, вероятно, и сотни серверов будет недостаточно?
Да, нет от чего же... вы же только серверную часть будете на PHP делать, т.е. PHP будет только небольшим кусочком слоенного пирога, который будет задействоваться только при острой необходимости, при этом на разных уровнях, в том числе на уровне PHP у вас будут кэши. Кэши для статики, кэши для запросов, кэши для HTML, кэши для всего чего только можно.
>Большая команда?
Нет, большие команды программистов обычно не сколачивают. 7 человек - это нечто на грани ненормального, 3-5 человек (очень большую задачу могут разбить на несколько команд, сама же команда резко теряет эффективность, когда выходит за пределы 7 человек). Это если брать только разработчиков. Понятно, что дизайнеры, SEO, модераторы, системные администраторы сюда уже могут не входить (а могут входить).
>Дело на год растянется?
Растянется. Если каждый член команды представляет что делать и настроен работать без "раскачки" можно уложиться в меньший срок.
>А если сделать масштабирующуюся систему?
>Сначала на РНР и на одном сервере. Тысяч до 50 посетителей он потянет. А потом, по мере разрастания базы и усложенния
>функционала, фрагментарно заменять наиболее нагруженные области кода на более быстрые решения, и добавлять
>серверов. Это разумно? Или утопия?
Если опыта нет, то довольно трудно будет на одном сервере построить масштабируемую систему (это и с опытом не просто на нескольких серверах). Минимум на двух, пусть послабже. Масштабирование может происходить в разные стороны (в ширь, в глубь, по каналу, по мощности, по базе данных - много чего требуется масштабировать и узкие места могут появляться в разных ситуациях). Например, Web-сервера масштабируются очень хорошо и просто (особенно, если вы выделяете сразу всю графику и CSS на отдельный поддомен), а вот с базой данных уже хуже. Нужно сразу выбирать стратегию, если вы выбираете репликацию, вам нужно либо разделять INSERT/UPDATE/DELETE и SELECT-запросы на уровне движка, либо перехватывать их на уровне серверов (толковый системный администратор, который плавает в *nix как рыба в воде), либо связываться с кластером (а там тоже свои особенности, не все запросы выполняются, без остановки нод). | |
|
|
|
|
|
|
|
для: Владимир55
(05.03.2013 в 16:25)
| | Вероятно на фреймворке.
CMS тут не пахнет.
По замаху можно сдлеать на битриксе или modx revolution, обе системы способны выдержать такую нагрузку, но делать подобные проекты на конкретных cms нет смысла.
Кроме того закрытые части сайта, вероятно могут написаны вообще на C/C++. например модули статистики и отчетов для различных целей, которые ресурсозатратны. | |
|
|
|
|
|
|
|
для: ols
(06.03.2013 в 05:58)
| | Не уверен на счет Bitrix - сложно из него скорость будет выжить, если не знать досконально, там же все запрятано внутрь и фиг чего исправишь, даже явные ошибки - будет затерто при обновлении. А базу данных запрятали за ORM так, что следа не осталось (ну и понятно, фиг чего оптимизируешь, когда скорость нужна).
PS Напильником если обработать, то любую CMS можно подогнать. Мне показалось, что к Bitrix напильник применять очень сложно. Он сам кого хочешь обпилит под себя.
>Кроме того закрытые части сайта, вероятно могут написаны вообще на C/C++. например модули статистики и отчетов для
>различных целей, которые ресурсозатратны.
Модули для сервера в таком случае пишут (но все реже и реже) или просто выносят всю статистику в отдельную подсистему, с которой общаются через какой-нибудь memcached или NoSQL. На C/C++ написать, чтобы не текло и не глючило без многолетнего опыта очень сложно. Лучше отлаженными серверами пользоваться, тем более их как грязи и довольно хороших. | |
|
|
|