Лучший способ улучшить производительность (и включить как-то отказоустойчивость) - PullRequest
7 голосов
/ 21 августа 2009

У нас есть приложение, в котором IIS и SQL находятся на одной машине. Это стандартный сервер windows2003 с 4 гигабайтами оперативной памяти, работающей на виртуальной машине.

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

Я думал о разделении IIS и SQL на 2 разных компьютерах с 64-битной Windows2008 и не менее 6 ГБ ОЗУ для каждой машины, но также должно быть решение для восстановления после отказа.

Можете ли вы порекомендовать некоторые сценарии решения проблемы производительности и восстановления после отказа?

Спасибо

пс:

Только для информации: сейчас мы используем управление состоянием inproc в IIS, но я думаю, что будет лучше перейти на sqlstatemanagement.

EDIT

Я расширил вопрос до точки отработки отказа. Поскольку наш клиент не хочет тратить слишком много денег на серверные и SQL-лицензии. Было бы хорошо, если бы у вас была репликация на второй сервер SQL и использовать ее в качестве аварийного переключения? Знаете ли вы какие-нибудь лучшие "дешевые" решения?

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

Ответы [ 6 ]

2 голосов
/ 22 августа 2009

Прямо сейчас у вас есть 32-битная ОС на ВМ, я полагаю. Поскольку Standard Edition не допускает AWE на двух серверах (IIS и SQL), SQL Server будет загружать максимум, что может около 1,8 ГБ, и оставит много оперативной памяти для IIS и ОС. Но как только вы перейдете на 64-битную ОС, все изменится, поскольку SQL Server займет всю оперативную память для своего буферного пула (~ 5 ГБ, если доступно 6 ГБ), а затем начнет возвращать ее ОС, когда уведомит . Это поведение можно настроить, настроив SQL Server параметры памяти . Разделив IIS и SQL на отдельные виртуальные машины, вы оставляете всю память на виртуальной машине SQL для ее буферных пулов, и это хорошо. В идеале у вас должно быть достаточно оперативной памяти, чтобы SQL мог загружать всю базу данных в память (включая базу данных tempdb) и касаться диска только для записи журнала и когда ему необходимо проверить контрольную точку базы данных. Другими словами, больше оперативной памяти означает более быстрый SQL. Это, безусловно, самый важный аппаратный ресурс, который SQL требует для производительности, и он принесет самый большой выигрыш.

Теперь вернемся к широкому вопросу о «отказоустойчивости». В SQL Server решения для высокая доступность разделены на две категории: автоматический и ручной . Для автоматического аварийного переключения у вас действительно есть только несколько решений:

  • Кластеризация . Традиционно это довольно дорого для реализации из-за высокой стоимости оборудования, поддерживающего кластеризацию, но с виртуальными машинами это совсем другая история. Standard Edition SQL поддерживает два кластера узлов. Кластеризацию сложно развернуть, но она довольно проста в управлении и не требует никаких изменений приложений для поддержки. При кластеризации единицей отработки отказа является весь экземпляр SQL Server (т. Е. Каждая база данных, включая master / tempdb / model и msdb, все имена входа, все задания агента SQL и т. Д. И т. Д.). Кластер является , а не решением для повышения производительности, так как резервный сервер просто бездействует в случае сбоя основного. Вы можете использовать резервную виртуальную машину, развернув так называемый «активный-активный» кластер. Это означает, что вы развертываете два кластера, один активный на VM1 и резервный на VM2, другой активный на VM2 и резервный на VM1. В случае аварийного переключения одна из виртуальных машин должна будет принять на себя нагрузку в обоих экземплярах, и именно поэтому иногда активно-активные развертывания не одобряются. Учитывая, что вы планируете развертывать на виртуальных машинах не на (дорогом) металле, я бы рекомендовал против этого, поскольку нет огромных затрат на «амортизацию».
  • Зеркальное . Это сохранит горячее резервное зеркало вашей базы данных (не экземпляр). Зеркалирование предпочтительнее кластеризации из-за более низкой стоимости развертывания (без специального оборудования), меньшего времени отработки отказа (в секундах, а не минут при кластеризации) и возможностей геораспределения (зеркалирование поддерживает распределение узлов по отдельным сторонам, кластеризация поддерживает только небольшое расстояние сто метров между узлами). Но поскольку единицей восстановления после отказа является база данных , зеркалирование не обеспечивает простоты использования кластеризации. Большая часть ресурсов, необходимых приложению , а не , находится в базе данных: имена входа, задания агента, планы обслуживания, почтовые сообщения базы данных и т. Д. И т. Д. Поскольку происходит сбой только базы данных, отработка отказа должна быть тщательно спланирована, чтобы приложение продолжало работать после отработки отказа (например, должны быть переданы имена входа). Приложение также должно знать о развертывании зеркального отображения, чтобы оно правильно подключалось . В Standard Edition вы сможете развернуть зеркалирование только в режиме высокой безопасности .
  • Аппаратное обеспечение Зеркальное отображение. Я не буду вдаваться в подробности этого, для этого требуется специальное оборудование SAN, способное к зеркалированию на уровне диска.

Если вы рассматриваете решения по отказоустойчивости вручную, есть еще несколько альтернатив:

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

  • Тиражирование. Это действительно не решение высокой доступности. Репликация - это решение для предоставления копий данных и / или обмена обновлениями данных между сайтами. Хотя его можно использовать для развертывания какого-либо высокодоступного временного «решения», с этим связано много проблем, и в основном это не дает никаких преимуществ. По сравнению с доставкой журналов и зеркалированием, у него есть ряд дополнительных недостатков, поскольку единица отработки отказа - это даже не база данных, а только кусочки данных в базе данных (некоторые таблицы). Метаданные, такие как права доступа пользователя и безопасности, не возвращаются при сбое, изменения схемы необходимо выполнять в режиме с поддержкой репликации , а некоторые изменения даже нельзя реплицировать. По контракту и зеркальное отображение, и доставка журналов предоставляют резервную копию, идентичную производственной базе данных, которая автоматически покрывает любое изменение, внесенное в базу данных.

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

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

1 голос
/ 21 августа 2009

Вы должны обратиться к этим 2 статьям по проекту кода для настройки производительности ASP.Net

1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx

Я лично применил эти методы в своих приложениях asp.net и получил более 30% повышения производительности.

Кроме того, вы можете обратиться к этой статье за 99,99% времени безотказной работы вашего приложения.

3. http://www.codeproject.com/KB/aspnet/ProdArch.aspx

1 голос
/ 21 августа 2009

Звучит так, будто вы действительно спрашиваете, стоит ли вам помещать БД на отдельную машину. Это может не улучшить производительность (на самом деле она будет уменьшаться при увеличении задержки), но улучшит масштабируемость (что, я полагаю, то, что вам действительно нужно).

Производительность <> масштабируемость.

Однако в игру вступают другие проблемы - если вам не хватает производительности ОЗУ, может уменьшиться наличие БД на одном компьютере - SQL-сервер любит использовать ОЗУ.

Вот почему для таких вещей, как TFS, использующих сервер SQL, для небольшого числа пользователей Microsoft рекомендует, чтобы все они были установлены на 1 машине, но для большего числа пользователей Microsoft рекомендует, чтобы БД находилась на другом сервере.

Вы можете прочитать о параметрах развертывания для TFS здесь .

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

Звучит так, будто вам действительно нужно выяснить, какое первое место имеет производительность. По моему опыту это обычно в БД.

Вы рассматривали стандартные методы оптимизации ASP.NET, такие как кеширование? Microsoft предоставляет руководство по настройке приложений , которое также может быть полезно для вас.

Если вы используете SQL Server в сценарии веб-приложения, если вы используете SQL Server 2005 и выше, вы можете прочитать о Изоляция моментального снимка . Иногда отказ от его использования является причиной проблем с производительностью в веб-приложениях.

1 голос
/ 21 августа 2009

SQL Server всегда работает лучше, если это «ТОЛЬКО», работающий на машине. Вы получите быструю, простую и хорошую выгоду от этого. Кажется, ему нравится все контролировать, и он всегда счастлив, когда может:)

0 голосов
/ 21 августа 2009

Естественное разделение IIS и SQL-сервера является первым шагом. Sql-сервер действительно хочет иметь полную машину для себя.

Вторым важным моментом является анализ приложения во время его работы. Никогда не пытайтесь оптимизировать производительность вашего приложения, не имея реальных данных об использовании, потому что вы, вероятно, просто тратите время на оптимизацию того, что редко вызывается. Одна из техник, которую я успешно использовал в прошлом, заключается в создании System.Diagnostics.Stopwatch в Request_Begin в global.asax, а затем в контекстной переменной

.
var sw = new Stopwatch();
sw.Start()
HttpContext.Current.Items["stopwatch"] = sw;

В Request_End вы получаете агин секундомера

sw = HttpContext.Current.Items["stopwatch"];
sw.Stop();
Timespan ts = sw.Elapsed;

А затем запишите в таблицу журнала, сколько времени потребовалось для обработки запроса. Также регистрируйте URL-адрес (как с параметрами строки запроса, так и без них) и все виды материалов, которые помогут вам проанализировать производительность.

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

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

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

0 голосов
/ 21 августа 2009

Разделение слоев может помочь. Зачастую настройка машины для БД довольно специфична, поэтому это разумное первое усилие.

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

Две вещи, которые вы можете рассмотреть:

  1. Можете ли вы принять подход "хранилища данных"? Иметь второй БД ручную подачу из первого. Новая БД, где тяжелые пользователи делают свою работу. Конечно, их статистика будет немного устаревшей, но концептуально это всегда будет правдой - к тому времени, когда они посмотрят на ответы, которые переместит мир.
  2. Контроль количества запросов статистики, которые вы разрешаете в любое время. Возможно, их отправили в очередь как «работу». Запустите их с низким приоритетом.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...