Відкриваємо масштабний проект. Потрібно зоорієнтуватись, на чому краще робити.
Потрібен дуже потужний сайт з інтерфейсом для користувача та адміністратора. Повинен тримати навантаження в 20 000 хостів в день.
Що можете порадити з програмної частини проекту ? На чому краще реалізувати ?
П.С.: виникла опечатка. Не 20 000, а 200 000 — це середне значення. В пікові моменти плануються до 500 000
Пока что я увидел только одно требование к “масштабному проекту”:
Повинен тримати навантаження в 500 000 хостів в день.Больше никакой информации: нужно ли хранить какие-то данные и сколько? нужно ли что-то считать или какие-нибудь данные обрабатывать? Какая вообще предметная область?
<title>Есть много денег, куда потратить?</title>
Нашли овердофига денег, нужен совет, как лучше их потратить. Подскажите, пожалуйста, кому их можно дать.
микроасемблер, думаю это лучший вариант....
А если серьездно, выберать язык нужно по многим факторам:
1. Тип програми.
2. Платформы.
3. Знание языка в команде.
4. Наличие персонала на рынке.
скажите, из чего мне построить дом?
планируется разместить до 1500 человек.
если каждый захочет привести гостей, дом должен выдерживать до 15 тыс человек
архитектора нет, строительные бригады еще не набирали.
может, бетон? или кирпич? дерево? гвозди? цемент?
а еще я слышал, штукатурка — очень важна. это так?
Лол. Как раз большинство известных проектов для микросервисов сделаны на джаве. Netflix даже заопенсорсил свой стек — Netflix OSS stack.
Я теряюсь понять как микросервисы связаны с подземными ходами.
Это прямая аналогия. Не один монолит в 12 этажей, а 12 коттеджей которые общаются по одному протоколу.
Но протокол же не обязательно подземный тунель, а вполне могут быть ухоженные дорожки с скамейками.
качество тонелей может быть тoже сомнительным.
Микросервисы это не бесплатный сыр. Иногда распределять сервисы только ради распределения глупо. Как миниум из за latency и оверхеда на сериализацию.
Я не пропонент микросервисов, но думается сериализация редко является затыком. Вон люди на тормозных эрлангах и питонах програмируют, и ничего.
вай нот? если постоянно холодный климат(тоннели) и камень достать сложнее, чем дерево — нормальный вариант.
в зависимости от требований, такой план может быть как феерическим провалом, так и безусловным win’ом.
так же, как и топикстартер, я намеренно писал в отрыве как от функциональных требований(у нас всего 2 сотки земли под постройку), так и не функциональных(все это находится на острове и доставка материалов удорожает их в два раза)
Думаю здесь подойдет «небесный город» в Токио. Представьте себе небоскреб, в котором под одной крышей объединены парки и скверы, жилые дома и офисы, в котором может разместиться 130 тысяч человек? Готовьте примерно 20 триллионов долларов :-) domamira.su/...nebesnyj-gorod
и тут я добавляю требование: у нас проблемы с грунтом — постоянные оползни в месте дислокации. норм? :)
можно сделать на плавучей платформе в Черном море. Правда размеры платформы мне пока неизвестны, думаю 100×100 км будет нормально, но это приблизительные размеры. Сами понимаете платформа добавит...еще столько же к цене. Масштабные проекты требуют масштабных инвестиций, «по-другому не моги» ©.
Подскажите пожалуйста, как решить задачу.
Необходимо создать программу, которая будет считывать с текстового файла логин и пароль аккаунта, заходить по ним в инстаграм >> переходить в указанный аккаунт >>> подписываться на подписчиков этого аккаунта с частотой 1 подписчик/3 сек. Дальше выходить из аккаунта.
Имхо, это слишком похоже на спам.
Предвкушаю следующий вопрос типа: «Подскажите, что такое IDE».
Да тебе же в спамерсокм аду гореть
В Инстаграмме не дебилы сидят и жить твоему эккаунту от 3 суток до 2 недель, зависимо насколько руки прямые. А судя по наивным представлениям, запросто запалишь весь сервис и он будет забанен навечно.
PS. Может тебе ещё и капчу распознать?
Можно еще через тор прогонять с рандомизатором выходов. Тогда чуть дольше продержится. Но контент тоже сильно рандомизировать придется. )
«Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова...»
я думаю, нужно использовать JSP (Tomcat). PHP не выдержит.
Сервер не сможет обрабатывать запросы и клиенты не будут видеть результат. Простой расчет: VPS сервер на php / symfony 2 + apc cache способен отдавать результат динамической страницы за 300 мс. Это значит что он способен обрабатывать 288000 запросов в сутки, а нужно порядка 500 000 хостов * количество страниц на 1 хост (примерно 10) = 5 млн запросов в день. Tomcat способен отдавать результат за 30 — 100 мс, что в 3 — 10 раз быстрее. Это мои данные. если у вас есть другие — можете привести.
да ладно?) вы посчитали стоимость железа и т.д. и т.п?)
и вообще nginix держит до 2000 запросов в секунду(на старом железе). А выдать нужное время обработки дело прямоты рук программиста.
Не понял ваш вопрос. Объясните более подробно. Tomcat легко устанавливается на любой VPS. VPS сейчас можно купить за 30 USD в месяц. Если взять Amazon EC2 medium, то он обойдется примерно в 50 USD в месяц.
Если запущен один fpm worker, то расчёты может и правильные. Но кто ж один запускает. В общем всё зависит от количества ядер, worker’ов, да и масштабировать проблем нет.
p.s. о том что java более производительна, вопросов нет.
Особенно их дебажить [злодейский смех]
до 1 миллиона можете не париться и реализовать на любой стандартной более менее известной технологии. зенд и симфони на пхп, мвц на си шарпе и тд.
советую си шарп, в силу своей простоты.
Однозначно на github.com/...aster/readme.md
Мільйон хітів на звичайному сервері витримає легко. Для нарощування функціоналу все необхідне є. Для автоматичного тестування та деплойменту теж все є.
о хитах никто речь не ведет.
... только не повторяйте ошибок Диаспоры, скопировавшей не глядя стек работы с данными Фейсбука там, где это категорически не должно было использоваться.
Вообще, прийдя по ссылке, я ожидал хотя бы 10 строчек описания (вообще-то, пол станицы), а не 4 ))) Так никто ничего конкретного не скажет. Будет стопицот вариантов (в лучшем случае).
В свое время был такой совет для начинающих изучать Linux:
— Берите тот дистрибутив, который использует ближайший гуру.
Вот и мой совет:
— Возьмите ближайшего качественного программиста и сделайте свой проект с ним, что бы он заработал и начал приносить хоть какие-то деньги. Сейчас Вашу нагрузку выдержит любая технология при правильном проектировании.
— Когда выйдете на доход, вы уже поймете где у Вас узкие места и что надо оптимизировать.
Мои личные предпочтения: Erlang/OTP + n2o, Perl + PSGI + Plack. В чем хранить данные выбирайте сами :-)
Возьмите для начала на работу архитектора проекта, который и будет отвечать за выбор технологии. Неужели Вы действительно начнете проект на том, что здесь насоветуют? Еще в фейсбуке можно спросить или в одноклассниках. Эффективность советов будет сопоставима.
Каких программистов найдете, на том и будет 1ая версия.
А как взлетит, станет понятно и на какие технологии переходить.
Может вообще будете выбирать из:
C++ фреймворки для разработки Web-приложений
Начиная с .net 3.5 производительность С# и С++ одинакова, нет смысла писать на С++
Managed C++ over .NET I guess
зачем вообще? ну, есть преимущества.
зачем в данном случае? не знаю. я ж только предположил, что об этом речь — а так только Igor Barinov знает, что он имел в виду.
чисто гипотетически, скомпилированный в натив С++ код вполне может быть такой же по скорости, как выполнение .Net байт-кода. все, что надо для этого — сложная логика, чтоб время расчетов было больше времени процессинга байт-кода.
В .NET байткод не выполняется, а компилируется в машинный код
оу, опростоволосился.
тогда тем более — не понятно, с чего бы .NET(и C#, в частности) не быть таким же скорым, как Native C++ - можно подумать, ассемблерные вставки в каждую программу вставляются(что, кстати, чревато).
Это ложное утверждение многократно опровергалось.
Но, можете профессиональным плюсовикам объяснить что ручное распределение памяти, особенно в стеке не даёт никаких особых выгод по производительности
дает.
можно я поспорю «концептуально», при том что ни плюсовиком, ни дотнетчиком не являюсь?
какой должна быть программа(я имею в виду, какую задачу она должна решать?), чтоб тормоза были не из-за конкретного алгоритма или косяков логики(локи, например), а именно из-за выделения памяти или gc?
вполне допускаю, что интерпретируемые языки проигрывают компилируемым вчистую.
но если речь идет о байт-коде и прекомпиляции — откуда возьмутся тормоза? наоборот, можно реализовать узкозаточенную оптимизацию именно под текущую архитектуру. а как с этим у «нативных бинарников»?
но если речь идет о байт-коде и прекомпиляции — откуда возьмутся тормоза?из алгоритмов и архитектуры.
риторические вопросы конечно :)
не так давно очередное рассуждение встретил:
Так почему же языки вроде С и С++ зачастую быстрее управляемых (т.е. использующих GC)?
Ответ не так прост:
5. И, наконец, главное! Тем что в С и С++ большая часть данных размещается вовсе в куче, а на стеке!
rsdn.ru/...sophy/5833094.1
от себя добавлю — или на стекоподобной куче, где не происходит освобождения памяти. сам такие на С реализовывал :)
наоборот, можно реализовать узкозаточенную оптимизацию именно под текущую архитектуруэффект от этой заточки будет зависеть — а что собственно отличает эту текущую архитектуру от других. Конечно, код SSE эффективней аналогичного на общих регистрах.
а как с этим у «нативных бинарников»?если отличия значимые — в составе приложения просто несколько бинарников.
так и сейчас. те же бытовые видеоконвертеры. Некоторые имеют в составе библиотечку работы с Nvidia CUDA. Но я сомневаюсь что компиляторы байткода такие умные, чтобы оптимизировать итоговый код с учетом таких особенностей текущей архитектуры.
5. И, наконец, главное! Тем что в С и С++ большая часть данных размещается вовсе в куче, а на стеке!Подучи матчасть и не позорься уже en.wikipedia.org/...mple_.28Java.29
и с чего ты кулхацкер решил что эта фича JVM мне неизвестна? ;)
Escape analysis не позволяет учитывать специфику алгоритма.
Поэтому в Rust, дабы повыситить безопасность распределения памяти, при сохранении эффективности и детерменированности ее освобождения, вынесли на уровень языка обязанность контроля выхода переменной за scope.
потому что, кулхацкер, ты не поверишь, scope бывает не только синтаксический, а и семантический.
Приведи пример «семантического скопа» с выделением на стеке.
подсистема, когда мы уверены что после возврата управления из нее, нам не нужно сохранять ее данные, только результат ее работы.
в итоге — в ней используется выделение в стеке(нашем, а не аппаратном), а на выходе из нее — указатель устанавливается на начало стека.
при этом, чистенький стек можно отдать другой подсистеме.
в итоге — их будет несколько.
и т.д.
Сишники в курсе.
дофига кода будет.
меня эти требования показать код часто и умиляют.
если не поняли идею, то на пальцах:
есть подсистема, то есть семантически самостоятельная часть программы.
состоящая из N функций (процедур, методов объектов)
порядок вызовов которых в общем случае — неизвестен. определяется входящими данными
синтаксический анализ может определить только время жизни данных внутри функции.
но программист то знает, что эти данные нужны только для работы внутри этих N функций.
вот он и будет — семантический скоуп.
Я так и думал что что-то подобное будет.
в мире ЯП с ручным управлением памяти — обычное дело.
управление памятью — часть дизайна.
чего лишены джависты и дотнетчики.
для интересующихся, что предлагает Rust
Understanding Pointers, Ownership, and Lifetimes in Rust
Но то что джава как и цпп может на стеке обьекты создавать у тебя я так понимаю заблуждений уже не осталось благодаря моему ликбезу.
какому твоему ликбезу?
про struct на стеке в C# у Рихтера написано не скажу точно сколько лет тому.
как и про эскейп анализ в серверной JVM.
тоже не помню когда прочел
Новые оптимизации компилятора VM. Часть 2: Escape-analysis
точно помню что тогда у них еще свой сайт был. и Sun не был еще куплен.
ты кулхацкер как всегда столь высокого о себе мнения что вещая известное для мало-мальски интересующихся.
На Си же я писал в середине 90ых. и то что я назвал семантическим скоупом — обычная работа мозга сишного программиста.
а ты видать упоротый джавист решил что эскейп-анализ работу мозга заменит?
Ну не я же выше лапшал что ц++ быстрее джавки потому что на стеке умеет данные размещать.
с своей лапшей на глазах разбирайся сам.
вначале поста я сразу указал на мозг программиста —
из алгоритмов и архитектуры.
откуда берутся тормоза у ...
код для иллюстрации семантического скоупа на неизвестном языке
func first() {
var a = new A
a.x = new X
ret a
}
func second() {
var b = new B
b.a = first()
ret b
}
func third(inpData) {
if (inpData has blue) ret first().md5()
ret second().md5()
}
func main() {
while (...) {
var data = ...
init_mem(’scope_f_s_t’) // get memory when first run
result_out(third(data))
release_mem(’scope_f_s_t’) // set pointer to head
}
}
с своей лапшей на глазах разбирайся сам.Чувак, там в верху твоя цитата на счет стека, все ходы записаны.
именно потому что записана, я и спокоен.
а проблемы твои кулхацкер, с глазами, или мозгами всему доу и без этого случая известны.
интересно через сколько лет блевать то на форуме перестанешь :)
НУ так обьясни, в чем неправильность моего понимания твоей цитаты. А то пока что блюешь ты.
а ты видать упоротый джавистсудя по комментам в разных топиках таки да...
Упоротость просьба обосновать. Где именно я оказался не прав?
откуда берутся тормоза у сортировки пузырьком в сравнении с qsort?если б я хотел чисто посраться, я бы намекнул на то, что всему свое место и даже сортировка подсчетом имеет преимущества перед остальными на определенных данных.
5. И, наконец, главное! Тем что в С и С++ большая часть данных размещается вовсе в куче, а на стеке!перечитал и оригинал. так и не уверен — хорошо, что в стеке? или хорошо, что в куче? вот, так, одна опечатка — и нифига не понятно :(
вне зависимости от head/stack based allocation можно написать логику так, что она будет быстрее или медленнее.а теперь представьте что ЯП запрещает что-то.
например — ручное управление распределением памяти.
на ЯП с автоматическим распределением памяти оно — запрещено.
хотя, варианты обойти есть. у JVM это недокументированные функции запроса памяти у ОСи или из non-blocking I/O
можете прояснить этот момент?какой именно?
как работает аппаратный стек? как работает классическая куча? как работает сборщик мусора, и в чем отличие от подсчета ссылок?
что именно прояснить?
или результаты пояснить?:
C++ g++ vs Java
На одном из моих очень старых проектов 1 Nginx боевой + 1 запасной и 4 томката под ним держали нагрузку 20 000 stream-ов в час, даже если 3 томката отваливались, система не падала, но ее capacity проседала до 7000. Серваки были обычные насколько я помню 8 гб + 1 дешевый 6 ядерный Xeon частоту не помню, вроде 2 ггц, stream content provider был удаленный. Nginx вообще на простеньком ПК крутился.
В этой связи используйте горизонтально масштабируемые решения, тогда вы можете легко нарастить серверов, увеличив производительность практически пропорционально их количеству, хотя нужно изучать глубже.
Пока что я увидел только одно требование к “масштабному проекту”:
Повинен тримати навантаження в 500 000 хостів в день.Больше никакой информации: нужно ли хранить какие-то данные и сколько? нужно ли что-то считать или какие-нибудь данные обрабатывать? Какая вообще предметная область?
Банальное разделение фронтэнда и бекэнда по разным физическим серверам уже способно решить проблему. Ну и оба сервера должны быть вполне себе норм серверами. На моей прошлой работе сайт висел на двух полудохлых блейдах и нормально качегарил до 250 к в сутки. Так что можно писать, но том, что умеете, а потом уже задумываться над проблематикой, если таковая встанет.
«Вы не любите собачье мясо? Может вы просто не умеет его готовить?». Ребята правильно пишут, вы немного не от тех целей отталкиваетесь. У вас программисты всезнайки? Могут сплясать на всем, что вы им скажете?
Как правило такие проекты имеют чёткое функциональное разделение. То есть независимые части, которые с лёгкостью переползут на отдельный сервер при масштабировании. Посему — не парься и делай на чём умеешь. Первым делом ответвишь статическую нагрузку с помощью ngnix. И на первые пару лет этого будет достаточно.
Интерфейс администратора нагрузки не создаёт.
Вообще насчёт масштаба не раскатывай губу. Набрать полмиллиона юзеров в день — дело небыстрое и не бесплатное. Это сравнимо с нагрузкой киевского метро.
И ты понятия не имеешь, какая именно часть твоего проекта выстрелит, а какая загнётся. Потому не парься с масштабированием, достаточно просто разделить функционал и не завязывать сервисы сильно друг на друга, ограничив их чрезмерное общение между собой.
Любой современный язык + бд при правильном подходе к масштабированию потянет 200 000 хостов в день (вообще неудачная на мой взгляд метрика).
Но если хотите именно масштабный проект то java + oracle на aws :)
Прошу вибачення. Виникла суттєва опечатка. Не 20 000, а 200 000 ))
В любом случае, мне кажется вы слишком много внимания уделяете не-функциональным требованиям — нагрузке, кол-ву хостов и т.п.
В то время как архитектура приложения пляшет именно от функциональных требований. Язык программирования, база данных, веб-сервер, технологии это все детали реализации. Соотвественно вам нужно сначала сконцентрироваться на том как реализовать требования заказчика в вашей системе, и уже потом вокруг этого создать инфраструктуру которая будет поддерживать ваши нефункциональные требования — количество пользователей к примеру.
Приведу пример, делаете допустим вы простенький интернет магазинчик, у заказчика есть к нему требования по функциональности — корзина, добавление товара в каталог, поиск.
Соотвественно функциональность не измениться, если им пользуется 10 человек и 10 000 человек. Таким образом количество пользователей это вопрос скорее инфраструктуры, а не архитектуры приложения.
Но тот же интернет-магазинчик может вполне себе перерасти в интернет гипермаркет, у которого есть маркетинговая, учетная, статистическая, административная функциональность. Соотвественно функционал такой системы может быть просто громадным, а нагрузка может довольно маленькой. ( А может быть и громадной )
Следует признать что жесткая зависимость инфраструктуры от функционала справедлива не во всех случаях и бывает такой экстрим когда предявляются очень жесткие требования к мастшабированию, пропускной способности (throughput), отзывчивости (latency) и т.п.
Тогда это безусловно накладывает отпечаток на архитектуру системы. Но функциональные требования и возможность их наращивания все равно должны стоять на первом месте в силу того что система которая «не работает быстрее» бесполезна.
Вывод: В разработке сложных enterprise/web/real-time систем все в большей степени зависит от предметной области и самого приложения чем от инфраструктуры или технологий.
200к уников в день тянет вордпрес на сервере за 500 евро в месяц .
В любом случае, акцент нужно делать не кол-во уников.
не кол-во униковне на кол-во уников.
selffix
лол маштабный
20К в день будет наверно на разбери пае работать на пехапе
Если серьезно- на том на чем знаете, эти цифры смешные
На том что знаете, на том и делайте.
Вообще веб-сайты это очень просто с точки зрения архитектуры, масштабирования. Соотвественно я бы выбрал веб-стек вроде RoR или Django.
Другое дело если бы это был проект с интеграцией в кучу систем, реал-таймовым процессингом, множеством сущностей и свервисов и т.п. Тогда это была бы совсем другая история.
Если у вас именно веб-сайт, то повторюсь смело выбирайте фреймворк вроде RoR/Symfony/Django/* и в его архитектурном стиле и пишите.
p.s. 20к хостов в день это не нагрузка.
Масштабное? Берите Hybris. Будет ну очень
потужний сайт
Лучше и то и другое вместе, чтобы наверняка. Вдруг использованием только Hybris — недостаточно мощный сайт получится.
И между ними Enterprise Service Bus, чтобы наверняка.
Да, и обязательно использовать 2 базы одновременно Oracle и MongoDB, часть объектов в одной, часть в другой, чтобы было «надежней».
В итоге только на лицензии в год будет уходить $100к+. Думаю это будет достаточно
потужний сайт
На том, на чём быстрее и дешевле получится реализовать.
Тут в комментариях сейчас народ напишет то на чем он пишет) Поэтому наверно важно знать а какой выбор есть, тогда и ответы будут более конкретные.
В том-то и суть ) Все технологии примерно равны — пишите на том, что лучше знаете )
садовник-таможенник
нет конечно же, спасибо, исправил
может я чего-то не понимаю но как
Відкриваємо масштабний проект.
Потрібен дуже потужний сайтсочетается с
Повинен тримати навантаження в 20 000 хостів в деньтакую нагрузку даже вордпрес на дохлом серваке выдержит
DOU зроблений на Django і тримає навантаження в 20 000 хостів в день.
На чому краще реалізувати ?
На тому, на чому умієте самі або що знає Ваш кофаундер/CTO/знайомий програміст etc.
-
через WSGI чи напряму без nginx/apache?
Через WSGI.
а що використовували? якщо не секрет...
Не знаю, чи достатньо інформативною є така картинка:
i.imgur.com/sSrrY2z.png
дякую, доволі інформативно...
де саме на ДОУ використовується node.js ?
Здається, використовується тільки для компіляції LESS-файлів і для типографа.
взагалі, те як організований ДОУ, було б цікаво почитати)
не зовсім. Точніше, зовсім не це))
Магазин с 200К хостов это же просто мечта! :)
Ruby/Rails ;-)
А до нього в додачу що ще можете порадити ?
кроме javascript ничего впридачу не нужно будет
голый javascript явно недостаточно, нужно выбрать framework (en.wikipedia.org/...ript_frameworks)
node.js + какой-нибудь angular на фронте
чем этот совет вредный? Энтерпрайзщики негодуют?
да, эта конфигурация часто используется
vanilla-js.com на фронтенде и на бекенде
Beaver Green
Serge Ribalchenko
Ivan Levchenko
Георгий Каркузашвили
Євген Козлов
Sergii Voloshyn
reality_hacker
anonymous
Євген Козлов
Oleg Kariakin
Roman Melkumov
Volodymyr Kholoshenko
Олексій Пєніє
Tim Tretyak
Ivan M
Константин Белоус
Oleh Kuchuk
Константин Белоус
Ivan Levchenko
Valeriy Shvets
oleksandr dubyna
Руслан Шеремет
Vitaly Chernooky
Dmytro Shchurov
Oleksii Radetskyi
Oleg Androshchuk
undefined pointer
Igor Barinov
Artyom Krivokrisenko
undefined pointer
NewOne NewOne
Oleg Kariakin
Непочатов Станислав
Yaroslav Nelin
Олексій Пєніє
Java Adept
Макс Матюхин
Олег Высоцкий
Нестор Иванович
Вадим
reality_hacker
Igor Yatsenko
Eugene Kyba
Eugene Kyba
Нестор Иванович
Mike Gorchak
Sergii Voloshyn
Volodymyr Spodaryk
Oleg Androshchuk
Sergii Khomenko
Artyom Krivokrisenko
Алексей Лукьяненко
Andy W
Найкращі коментарі пропустити