Хорошо, значит, вы достигли ключевой точки в использовании «большой буквы O». Это одно измерение, которое, безусловно, может укусить вас сзади, если вы не обращаете внимания. Есть и другие измерения, которые некоторые люди не видят сквозь очки «большого О» (но если вы посмотрите поближе, они действительно есть).
Простой пример этого измерения - соединение с базой данных. Существуют «лучшие практики» в построении, скажем, левого внутреннего соединения, которое поможет повысить эффективность выполнения sql. Если вы сломаете реляционное исчисление или даже посмотрите на план объяснения (Oracle), вы легко сможете увидеть, какие индексы используются в каком порядке и выполняются ли какие-либо таблицы или вложенные операции.
Концепция профилирования также является ключевой. Вы должны быть тщательно и точно проинструктированы для всех движущихся частей архитектуры, чтобы выявлять и устранять любые недостатки. Скажем, например, вы создаете 3-уровневое многопоточное веб-приложение MVC2 с либеральным использованием AJAX и обработки на стороне клиента вместе с OR Mapper между вашим приложением и БД. Упрощенный линейный поток запросов / ответов выглядит следующим образом:
browser -> web server -> app server -> DB -> app server -> XSLT -> web server -> browser JS engine execution & rendering
У вас должен быть какой-то метод измерения производительности (время отклика, пропускная способность, измеренная в «материале в единицу времени» и т. Д.) В каждой из этих отдельных областей, а не только на уровне блока и ОС (ЦП, память, диск i). / о и т. д.), но характерно для каждого уровня обслуживания. Поэтому на веб-сервере вам нужно знать все счетчики для веб-сервера, который вы используете. На уровне приложений вам понадобится это плюс обзор любой виртуальной машины, которую вы используете (jvm, clr, что угодно). Большинство сопоставителей OR проявляются внутри виртуальной машины, поэтому убедитесь, что вы обращаете внимание на все особенности, если они видны вам на этом уровне. Внутри БД вам нужно знать все , которое выполняется, и все конкретные параметры настройки для вашего вида БД. Если у вас большие деньги, BMC Patrol - неплохая ставка для большинства из них (с соответствующими модулями знаний (KM)). На дешевом конце вы, конечно, можете кататься самостоятельно, но ваш пробег будет варьироваться в зависимости от вашего опыта.
Предполагая, что все происходит синхронно (никаких событий на основе очередей, которые вам нужно ждать), существует масса возможностей для проблем производительности и / или масштабируемости. Но поскольку ваш пост о масштабируемости, давайте проигнорируем браузер, за исключением любых удаленных вызовов XHR, которые вызовут другой запрос / ответ от веб-сервера.
Итак, учитывая эту проблемную область, какие решения вы могли бы принять, чтобы помочь с масштабируемостью?
Обработка соединений. Это также связано с управлением сеансом и аутентификацией. Это должно быть как можно более чистым и легким, не ставя под угрозу безопасность. Метрика - это максимальное количество соединений в единицу времени.
Отказоустойчивость сеанса на каждом уровне. Нужно или нет? Мы предполагаем, что каждый уровень будет кластером блоков горизонтально под некоторым механизмом распределения нагрузки. Балансировка нагрузки, как правило, очень легкая, но некоторые реализации аварийного переключения сеанса могут быть тяжелее, чем хотелось бы. Кроме того, если вы работаете с липкими сессиями, это может повлиять на ваши параметры в архитектуре. Вы также должны решить, привязывать ли веб-сервер к определенному серверу приложений или нет. В мире удаленного взаимодействия .NET, вероятно, проще связать их вместе. Если вы используете стек Microsoft, может быть более масштабируемым сделать 2-уровневый (пропустить удаленное взаимодействие), но вы должны сделать существенный компромисс безопасности. Что касается Java, я всегда видел его как минимум 3-х уровневый. Нет причин делать это иначе.
Иерархия объектов. Внутри приложения вам нужна максимально чистая и легкая структура объекта. Приносите только те данные, которые вам нужны, когда вам это нужно. Злобный акциз на любое ненужное или лишнее получение данных.
ИЛИ неэффективность картографа. Существует несоответствие импеданса между проектированием объекта и реляционным проектированием. Конструкция «многие ко многим» в СУБД находится в прямом конфликте с иерархиями объектов (person.address vs. location.resident). Чем сложнее ваши структуры данных, тем менее эффективным будет ваше OR ORMAP. В какой-то момент вам, возможно, придется обрезать приманку в одноразовой ситуации и сделать более ... эээ ... примитивный подход к доступу к данным (хранимая процедура + уровень доступа к данным), чтобы выжать больше производительности или масштабируемости из особенно уродливый модуль. Понять стоимость и принять осознанное решение.
XSL-преобразования. XML - замечательный, нормализованный механизм для передачи данных, но человек может быть собакой огромной производительности! В зависимости от того, сколько данных вы носите с собой и какой анализатор вы выбираете, и насколько сложна ваша структура, вы можете легко нарисовать себя в очень темном углу с помощью XSLT. Да, академически это блестяще чистый способ создания презентационного уровня, но в реальном мире могут возникнуть катастрофические проблемы с производительностью, если вы не обращаете на это особого внимания. Я видел, как система потребляет более 30% времени транзакции только в XSLT. Не очень приятно, если вы пытаетесь увеличить базу пользователей в 4 раза, не покупая дополнительные коробки.
Можете ли вы купить выход из варки масштабируемости? Абсолютно. Я наблюдал, как это происходит больше раз, чем я хотел бы признать. Закон Мура (как вы уже упоминали) действует и сегодня. На всякий случай имейте под рукой немного дополнительных денег.
Кэширование - отличный инструмент для снижения нагрузки на двигатель (увеличение скорости и производительности является удобным побочным эффектом). Это требует больших затрат, хотя и с точки зрения использования памяти и сложности при аннулировании кэша, когда он устарел. Мое решение будет начинать с чистого листа и постепенно добавлять кеширование только тогда, когда вы решите, что это полезно для вас. Слишком часто сложность недооценивается, и то, что изначально начиналось как способ устранения проблем с производительностью, приводит к функциональным проблемам. Также вернемся к комментарию об использовании данных. Если вы создаете объекты стоимостью в гигабайты каждую минуту, не имеет значения, кэшируете вы или нет. Вы быстро увеличите объем памяти, и сборка мусора испортит ваш день. Поэтому я думаю, что вы должны убедиться, что вы точно понимаете, что происходит внутри вашей виртуальной машины (создание объектов, уничтожение, сборщик мусора и т. Д.), Чтобы вы могли принимать наилучшие возможные решения.
Извините за многословие. Просто прокатился и забыл посмотреть. Надеюсь, что это затрагивает дух вашего исследования и не слишком элементарный разговор.