Первое время Архитектура?

Question

Мне недавно дали задание восстановить существующую RIA. Новая RIA, которую я разработал, основана на Silverlight, с сервисом WCF для подключения к MS SQL Server. Я впервые делаю что-то подобное, поэтому я не знаю, как спроектировать все это.

По сути, клиент может просматривать графики «акций» (что позволяет клиенту выбирать разные периоды времени, настройки и т. Д.). По сути, я написал целое приложение, но не знаю, как его собрать.

Предполагается, что графики основаны непосредственно на базе данных, и для создания точек данных на графике необходимо выполнить некоторые вычисления (не очень дорогие).

Проблема, которую я имею, состоит в том, чтобы решить, куда поместить вычисления (клиент или сервер? Или пополам?)

Какие факторы мне следует искать, чтобы помочь мне решить, где следует проводить расчеты? И как я могу оптимизировать это (кэширование и т. Д.)?

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

Answer 1

Несколько советов для такого рода приложений.
Положите как можно больше логики на клиента.
Сделайте клиент ответственным за данные сеанса, сделав весь код вашего сервера без состояний.
Постарайтесь минимизировать трафик на сервер и с сервера (большие запросы более эффективны, чем несколько меньших), поэтому объединяйте запросы, когда это возможно.

Answer 2

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

Что касается кэширования, это зависит от ваших входных данных, на какие переменные могут влиять пользователи клиента? Если какие-либо переменные, которые они могут изменить, являются дискретными (то есть они могут быть фиксированным набором значений), тогда они являются кандидатами для кэширования. Например, если пользователь может выбрать диапазон дат изменения запасов для просмотра, то это, вероятно, не очень полезно, если, однако, он может выбрать только год, то вы можете кэшировать свои наборы данных по годам (загрузите каждый набор данных для клиента и выполните расчет). Я бы не стал слишком беспокоиться о кешировании, если вы не обнаружите, что это реальная проблема с производительностью, это только сделает ваш код более сложным, поэтому не добавляйте его, пока не докажете, что он вам нужен.

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

Answer 3

Be ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО осторожно о реализации кэширования на стороне клиента. Кэширование БЕЗУМНО трудно сделать правильно, поддерживая производительность, безопасность и корректность. Обратите внимание, что механизм кэширования вашего DB Server уже, вероятно, будет намного лучше, чем любой механизм локального кэширования, который вы, вероятно, внедрите менее чем за 2 недели!

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

• Если вы собираетесь отфильтровать некоторые данные, возвращаемые вашим сервисом, вы просто потратили тысячи циклов доставки данных, которые никогда не покидали ваш сервер
• Если вы собираетесь сортировать свои данные, ваша БД могла бы выполнить сортировку за вас (часто используя в противном случае неактивные тики ЦП), ожидая, пока данные будут считаны с ее дисков.
• Ваш сервер, скорее всего, имеет больше ресурсов ЦП и ОЗУ, чем ваши клиенты, и имеет удивительное количество «свободного времени», которое можно использовать для сортировки, фильтрации, выполнения встроенных вычислений и т. Д., В то время как он ожидает дисков для чтения секторов и т. Д.

Как предположил Роман: минимизируйте количество поездок между клиентом и сервером в максимально возможной степени.

Но, пожалуй, самое главное:

1. ПРЕЖДЕ ЧЕМ НАЧАТЬ ПРОЕКТИРОВАНИЕ СИСТЕМЫ, сформулируйте свои цели производительности
2. Разработайте то, что, по вашему мнению, позволит достичь этих целей. Постарайтесь найти узкие места в вашем дизайне, особенно в тех областях, где вы делаете блокировку вызовов. Перепроектируйте эти области, чтобы использовать асинхронные шаблоны везде, где вы можете.
3. Создайте желаемое решение
4. Измерьте фактическую производительность под реальной нагрузкой
5. Если вы находитесь в пределах ожидаемых целей производительности, то все готово.
6. Если нет, потренируйтесь там, где вы тратите слишком много времени, и настройте дизайн этой части системы. Перейти к 3.

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

Сейчас они немного устарели, но я предлагаю вам прочитать некоторые из предыдущих постов по адресу http://blogs.msdn.com/richardt, чтобы больше размышлять о проектировании и конструировании сервис-ориентированных и распределенных систем.