Как я могу подать свои заявки масштабироваться хорошо?

Хорошо существует этот блог под названием Высокий Scalibility, который содержит большую информацию об этой теме. Некоторый полезный материал.

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

Простым примером того размера является соединение базы данных. Существуют "лучшие практики" в построении, скажем, левого внутреннего объединения, которое поможет заставить sql выполниться более эффективно. Если Вы ломаете реляционное исчисление или даже смотрите на объяснить план (Oracle), можно легко видеть, какие индексы используются, в котором порядке, и если происходят какие-либо сканирования таблицы или вложенные операции.

Понятие профилирования является также ключевым. Вы должны быть оснащены полностью и при правильной гранулярности через все подвижные части архитектуры, чтобы определить и зафиксировать любую неэффективность. Скажите, например, что Вы создаете 3-уровневое, многопоточное, веб-приложение MVC2 со свободным использованием Ajax и клиентской обработкой наряду с ИЛИ Картопостроитель между Вашим приложением и DB. Упрощенный линейный единственный поток запроса/ответа похож:

browser -> web server -> app server -> DB -> app server -> XSLT -> web server -> browser JS engine execution & rendering

У Вас должен быть некоторый метод для того, чтобы измерить уровень (время отклика, пропускная способность, измеряемая в "материале в единицу времени", и т.д.) в каждой из тех отличных областей, не только в поле и уровне ОС (ЦП, память, диск i/o, и т.д.), но характерный для сервиса каждого уровня. Таким образом на веб-сервере необходимо будет знать, что все счетчики для веб-сервера Ваш используют. В уровне приложений Вам будет нужно это плюс видимость в любую виртуальную машину, которую Вы используете (jvm, сброс, безотносительно). Большинство ИЛИ картопостроители проявляют в виртуальной машине, поэтому удостоверьтесь, что Вы - уделение внимания всем специфическим особенностям, если они видимы Вам на том слое. В DB необходимо будет знать все, что это выполняется и все определенные настраивающие параметры для разновидности DB. Если у Вас есть большие баксы, Патруль BMC является довольно хорошей ставкой для большей части из него (с соответствующими модулями знаний (КМ/СЕК)). В дешевом конце можно, конечно, прокрутить собственное, но пробег будет варьироваться на основе глубины экспертных знаний.

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

Так, учитывая эту проблемную область, какие решения Вы могли принять для помощи с масштабируемостью?

1. Обработка соединения. Это также связывается с управлением сеансами и аутентификацией. Это должно быть максимально чисто и легко, не ставя под угрозу безопасность. Метрика является максимальными соединениями в единицу времени.

2. Обработка отказа сессии в каждом уровне. Необходимый или нет? Мы предполагаем, что каждый уровень будет кластером полей горизонтально под некоторым механизмом выравнивания нагрузки. Выравнивание нагрузки обычно очень легко, но некоторые реализации обработки отказа сессии могут быть более тяжелыми, чем желаемый. Также, ли Вы работаете с липкими сессиями, может повлиять на Ваши опции глубже в архитектуре. Также необходимо решить, связать ли веб-сервер с определенным сервером приложений или нет. В мире дистанционной работы.NET, вероятно, легче ограничить их вместе. При использовании стека Microsoft это может быть более масштабируемо, чтобы сделать 2-уровневый (пропустите дистанционную работу), но необходимо сделать существенный компромисс безопасности. На стороне Java я всегда видел его, по крайней мере, 3-уровневый. Никакая причина сделать это иначе.

3. Иерархия объектов. В приложении Вам нужна самая чистая, самая легкая возможная структура объекта веса. Только принесите данные, в которых Вы нуждаетесь при необходимости в них. Злобно вырежьте любое ненужное или лишнее получение данных.

4. ИЛИ неэффективность картопостроителя. Существует несоответствие импеданса между объектным дизайном и реляционным дизайном. Конструкция many-many в RDBMS находится в прямом конфликте с иерархиями объектов (person.address по сравнению с location.resident). Чем более сложный Ваши структуры данных, тем менее эффективен Ваш ИЛИ картопостроитель будет. В какой-то момент Вам, вероятно, придется сократить приманку в одноразовой ситуации и сделать более... мм... примитивный подход доступа к данным (Хранимая процедура + Уровень доступа к данным) для сжатия большего количества производительности или масштабируемости из особенно ужасного модуля. Поймите включенную стоимость и сделайте ее сознательным решением.

5. XSL преобразовывает. XML является замечательным, нормализованным механизмом для транспорта данных, но человек может он быть огромной собакой производительности! В зависимости от того, сколько данных Вы носите с собой и какой синтаксический анализатор Вы выбираете и насколько сложный Ваша структура, Вы могли легко нарисовать себя в очень темный угол с XSLT. Да, академически это - блестяще очевидный способ выполнения уровня представления, но в реальном мире могут быть катастрофические проблемы производительности, если Вы не обращаете особое внимание на это. Я видел, что система использует более чем 30% времени транзакции только в XSLT. Не симпатичный, при попытке расти 4x база пользователей, не покупая дополнительные поля.

6. Можно ли купить выход из затора масштабируемости? Абсолютно. Я наблюдал, что он происходит больше раз, чем я хотел бы признать. Закон Гордона Мура (как Вы уже упомянули) все еще допустим сегодня. Имейте некоторые дополнительные наличные деньги, удобные на всякий случай.

7. Кэширование является большим инструментом для сокращения деформации на механизме (увеличивающий скорость, и пропускная способность является удобным побочным эффектом). Это прибывает в стоимость, хотя с точки зрения объема потребляемой памяти и сложности в лишении законной силы кэша, когда это является устаревшим. Мое решение состояло бы в том, чтобы запуститься абсолютно чистый и медленно добавлять кэширование только там, где Вы решаете, что это полезно для Вас. Слишком много раз сложности недооценены и что началось как способ решить проблемы производительности, оказывается, вызывает функциональные проблемы. Кроме того, назад к комментарию использования данных. При создании ценности гигабайтов объектов каждую минуту не имеет значения, если Вы кэшируетесь или нет. Вы быстро истратите свой объем потребляемой памяти, и сборка "мусора" разрушит Ваш день. Таким образом, я предполагаю, что еда на дом должна удостовериться, что Вы понимаете точно, что продолжается в Вашей виртуальной машине (создание объекта, разрушение, GCs, и т.д.) так, чтобы можно было принять самые лучшие решения.

Извините за многословие. Просто получил прокрутку и забыл искать. Надеюсь, что часть этого затрагивает дух Вашего запроса и не является слишком элементарным разговором.

Jeff и Joel обсуждают масштабирование в Подкасте Переполнения стека № 19.

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

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

Используйте это, чтобы сфокусировать Ваши усилия по разработке

FWIW, большинство систем масштабируется наиболее эффективно путем игнорирования этого, пока это не будет проблема - Закон Гордона Мура все еще содержит, и если трафик не становится быстрее, чем Закон Гордона Мура делает, обычно более дешево просто купить большее поле (на уровне 2$ или $3 тысяч за поп), чем заплатить разработчикам.

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

Если Вы думаете, что существует высокая вероятность, что Ваше приложение должно будет масштабироваться, это может быть интеллектуально для изучения систем как memcached, или карта уменьшают относительно рано в разработке.

Одна хорошая идея состоит в том, чтобы определить, сколько работы каждая дополнительная задача создает. Это может зависеть от того, как алгоритм структурирован.

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

Один способ приблизиться к этому был бы:

    for each car {
       determine my position;  
       for each car {  
         add my position to this car's map;  
       }
    }

Это кажется простым: посмотрите на положение первого автомобиля, добавьте его к карте любого автомобиля. Затем посмотрите на положение второго автомобиля, добавьте его к карте любого автомобиля. И т.д.

Но существует проблема масштабируемости. Когда существует 2 автомобиля, эта стратегия берет 4, "добавьте мое положение" шаги; когда существует 3 автомобиля, это делает 9 шагов. Поскольку каждое "положение обновляет", необходимо циклически повториться через целый список автомобилей - и для каждого автомобиля нужно его обновленное положение.

Игнорируя, сколько другие вещи должны быть сделаны к каждому автомобилю (например, он может взять постоянное число шагов для вычисления положения отдельного автомобиля), для автомобилей N, он берет ^N2 "посещения автомобилей" для выполнения этого алгоритма. Это не проблема, когда у Вас есть 5 автомобилей и 25 шагов. Но поскольку Вы добавляете автомобили, Вы будете видеть, что система срывает. 100 автомобилей сделают 10 000 шагов, и 101 автомобиль сделает 10 201 шаг!

Лучший подход должен был бы отменить вложение для циклов.

    for each car {  
      add my position to a list;  
    }  
    for each car {    
      give me an updated copy of the master list;  
    }

С этой стратегией количество шагов является кратным N, не ^N2. Таким образом, 100 автомобилей возьмут 100 раз работу 1 автомобиля - НЕ 10,000 раз работа.

Это понятие иногда выражается в "большой нотации O" - количество необходимых шагов является "большим O N" или "большим O ^N2".

Обратите внимание, что это понятие только касается масштабируемости - не оптимизация количества шагов для каждого автомобиля. Здесь мы не заботимся, делает ли это 5 шагов или 50 шагов на автомобиль - главное состоит в том, что автомобили N делают (X * N) шаги, не (X * ^N2).