Я хотел бы определить оптимальную настройку SQL Server Reporting Services для использования в качестве интегрированного инструмента отчетности для веб-приложений SaaS. Все отчеты предварительно определены, поэтому пользователи выбирают отчет и вводят некоторые параметры в веб-интерфейсе. Затем параметры передаются в отчет, который извлекает данные, форматирует результаты и возвращает файл PDF или Excel в веб-приложение.
Хотя у нас есть существующие SQL-серверы, поддерживающие наши веб-приложения, ни на одном из них не установлены службы Reporting Services. Варианты включают:
1) добавить службы Reporting Services в существующий экземпляр SQL Server
2) создайте новый экземпляр на физическом сервере, на котором уже работает SQL Server, и используйте этот новый экземпляр SQL для служб Reporting Services.
3) иметь отдельный физический сервер для служб Reporting Services
Хотя №3 является оптимальным, он также требует дополнительной лицензии SQL Server, что недешево. Не знаю, сильно ли я выиграю с вариантом №2, кроме некоторой стабильности. Вариант №1 может быть путем наименьшего сопротивления, но я понимаю, что SSRS вызывает значительные накладные расходы, и не хочу слишком большого снижения производительности.
Кому-нибудь нужно сделать что-то подобное? Анекдоты и мнения приветствуются.
Вы не указали, какая версия SQL Server. Имейте в виду, что SSRS 2005 требует, чтобы на компьютере был установлен IIS. SSRS 2008 - нет. Он изначально использует HTTP.SYS. Оптимальный ответ - №3, однако он действительно зависит от существующей нагрузки на физический сервер, а также от типа отчетов, которые вы будете запускать. # 1 / # 2 - по сути тот же вариант в отношении производительности.
По правде говоря, не зная тактико-технических характеристик, никто здесь не подскажет лучший вариант. Лучший способ - получить хорошее представление о том, как работают ваши SQL-серверы сегодня, настроить небольшую среду SSRS для разработки и профилировать ее при тестировании отчетов, а затем принять решение. Если вы не знаете, с чего начать получение профиля производительности на своих серверах SQL, позвольте мне порекомендовать:
Я думаю, что значительные накладные расходы лежат на глазах смотрящего. Например, одним из серверов, которым я управляю, является хранилище данных SQL Server 2000 с экземпляром SQL Server 2005 для хранения служб Reporting Services. Я бы не сказал, что SSRS имеет для нас значительные накладные расходы, но это во многом связано с тем, как мы его используем. Мы объединяем их в один экземпляр SQL Server 2008 по умолчанию по многим причинам, в основном из-за того, насколько малы размеры SSRS для нас по сравнению с хранилищем данных. У нас меньше 50 отчетов, и подавляющее большинство из них запланировано. Мы также не делаем кэширования и снимков. Так что в нашем случае консолидация - определенно правильный путь.
Мы идем по пути №1, пока не получим несколько бесплатных лицензий на выделенный сервер rs / as / mirroring. Я ограничил использование памяти iis для пула приложений. Благодаря этому и разумным тайм-аутам мы надеемся уменьшить влияние на движок db.
Я бы не допустил никакого adhoc (построителя отчетов) в системе №1.
Я бы действительно настаивал на №3. Вы также можете использовать его для зеркального отображения баз данных Critcal или для запуска ssis.
На прошлой неделе мы обслужили 3600 отчетов за 4 дня - объем памяти составляет около 300-1500 МБ.
Мы используем виртуальные серверы ESX с лицензиями центров обработки данных и лицензиями на ЦП SQL, поэтому у нас нет проблем с количеством размещаемых экземпляров SQL, поэтому мой ответ ...
Храните службы отчетов на отдельном сервере. Основная причина, по которой мы делаем это, заключается в том, что SSRS, как правило, является службой обновления до «последней и лучшей» версии, которая первой получает максимальную выгоду от новой функциональности (SSRS и Visual Studio 2008).
Наш SSRS - это SQL 2008 - большинство баз данных по-прежнему SQL2000 / и 2005
Также полезно, если вы можете хранить данные на отдельном сервере. Мы обнаружили, что загруженный сервер SSRS с базой данных в той же системе замедляет просмотр веб-страниц другими пользователями системы. Это было не так, когда мы переместили данные на выделенный сервер «данных отчетов».