Alex TorinУтрированно:
я создаю "Facebook" - его еще нет в природе (предположим), и начало стартапа сейчас, а не в начале 2004...
на чем его ваять, учитывая дальнейшую нагрузку, масштабируемость и т.п...Самое разумное - на том-же.

Получилось-же.

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

Заметьте, что все успешные стартапы используют "плохую" с точки зрения программеров (и хорошую с точки зрения владельцев стартапа) архитектуру.

Они потому и становятся успешными, что не тратят силы и деньги на такую третьестепенную вещь, как "правильная архитектура".
О чём вам тут несколько человек и пытаются рассказать.

Alex TorinСогласен, но ведь расстановка сил в пользу тех или иных технологий все же поменялась в сравнении с 2004. И речь не о бесплатности или мострообразности.
Хотя не совсем согласен на счет "не тратить силы на правильную архитектуру". Ведь тогда ее просто не было - подобные проекты только создавались и набирали силы - и судить о правильности архитектуры можно лишь через время т.е. сейчас... и не факт, что понятие "правильности" и дальше не будет преобразовано временем.Вы говорите о 2004-м году как о глубокой древности - и де архитекутры тогда не было, и компьютеры работали на лампадном масле :-)

Проекты нехилого масштаба, сложности, с большими требованиями к производительности существовали задолго до фейсбука.
Фейсбук вообще только что появился, шесть лет всего прошло, уже и линукс был, и микрософт, и многие другие игроки рынка.

Alex Torinпоэтому с утверждением, что они были успешными, потому как не зацикливались на правильности архитектуры - не согласен! - она была правильная тогда!

Вы "правильность" архитектуры трактуете неправильно, не как архитектор, а как программист.

Архитектура - это план реализации будущей системы, её основные идеи, правила создания.

Правильная архитектура - это такой план, который максимально точно соответствует бизнес-целям владельцев бизнеса (а не целям программиста или кого то ещё).

Так вот, бизнес-цель реализации была - нанять недорого программиста и за месяц сделать прототип.

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

Наверняка какие то мелочи при реализации такого стартапа сегодня изменились бы, т.к. меняется технология, меняется ИТ отрасль, но и сегодня принцип был бы такой-же.

Ну а если на самом деле вы ставите вопрос по другому "а вот если бы я щас переделал файсбук на новую архитектуру, потому что существующая неправильная", тогда так прямо и говорите.

itnoviceИнтересно, а как бы Microsoft Server-s 2008 R2 + ASP.NET + IIS7 + MS SQL 2008 R2 потянул бы такого типа проекты. Как кто думает? может у кого-либо был опыт в создании высоко нагруженных проектов с использованием технологии Microsoft? Поделитесь плз отзывамиКонечно, вот пример: Архитектура MySpace

В более мелких проектах (на порядок меньшая нагрузка) участвовал сам, там достаточно архитектуры попроще, с простым переносом читающих транзакций на отдельные серверы.

itnoviceпросто наткнулся на вот эту ссылку тынц , очень насторожился.

Ладно можно было пропустить мимо глаз есть ли бы проект разрабатывался небольшой конторкой, но при поддержке Microsoft...Да это просто софт плохой.

Про поддержку Microsoft неважно - при наличии любой поддержки плохой софт написать всё равно получится, было бы желание :-)

Кроме того, по ссылке сравниваются результаты синтетического теста с проблемами и сбоями в реально работающим ПО.
Абсолютно разные вещи. Несмотря на "достигнув времени операции порядка 126 микросекунд" в новой системе, ничего не мешает ей во время реальной работы зависнуть часиков на 10

itnoviceпросто в ближайшее время стартует большой и очень высоко нагруженный проект на .NET-e, раньше всегда вояли на JavaEE+Spring+Apache Tomcat+Oracle+Sybase IQ, а теперь вот на .NET новое чудовищеНу, что можно сказать... Зависит от того, как сделано :-)

Понятно, что просадить производительность в сотню раз ничего не стоит - часто народ на производительность забивает - это не кажется чем-то существенным :-)

Вот прикольная статья - Производительность .Net миф или фантастика?

Ну и при работе с MSSQL тоже можно много чего сделать.

DPH3Ну, высоконагруженные системы, в общем-то, все равно на чем делать - все равно все горизонтально масштабируется. Разница - в количестве запросов на сервер, сложностях с поддержкой и стоимостью лицензий и железа, т.е., в конце концов - в стоимости масштабирования и развертывания.Ну как же "всё равно", если вы потом пишите, что разница ровно в стоимости решения :-)

Использовал неправильный оператор в C# - в 10 раз меньше скорость - вместо 20 серверов нужно купить 200