Настройка сервера отчетов для освобождения ресурса с веб-сервера

Question

Yay, первое сообщение на SO! (Хорошая работа Jeff и др.)

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

Наша инфраструктура выглядит следующим образом: 1 сервер работает как веб-сервер/DbServer (ColdFusion 7 и MSSQL 2005)

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

В часы пик при создании отчетов он приводит к неприемлемой скорости веб-приложения и внешнего интерфейса из-за SQL Server, используя ресурсы для огромных запросов, а затем ColdFusion генерирует многостраничные PDF-файлы.

Мы не совсем уверены, что наилучшей практикой было бы удаление какой-либо нагрузки, но ограничение доступа к отчетам на данный момент не является вариантом.

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

Итак, мы собираемся получить второй сервер и использовать его в качестве «сервера отчетов» с реплицированной копией нашей БД, на которой будут выполняться запросы. Это устранит одну проблему, но вторая остается: генерация PDF-файлов является ресурсоемкой.

Мы также хотели бы передать эту задачу серверу отчетов, но, находясь в защищенном веб-приложении, мы не можем просто запускать HTTP GET для создания PDF-файлов с пользователем, зарегистрированным в веб-приложении с сервера 1 и отображая его в веб-приложении, но генерируя/получая его на сервере 2 без проверки учетных данных пользователя ...

У кого-нибудь есть опыт? Заранее спасибо Переполнение стека!

Answer 1

«Мы также хотели бы передать эту задачу серверу отчетов, но, находясь в защищенном веб-приложении, мы не можем просто запускать HTTP GET для создания PDF-файлов с пользователем, зарегистрированным в веб-приложении с сервера 1 и отображать его в веб-приложении, но генерировать/извлекать его на сервере 2 без проверки учетных данных пользователя ... »

Почему вы не можете? вы используете самый простой в мире язык для написания веб-сервисов. вот мои предложения.

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

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

сейчас для самих PDF-файлов. один из методов, которые я сделал в проходе, генерирует хэш на основе некоторых переданных параметров (учетные данные пользователя и сгенерированный sql для запуска запроса), а затем, как только PDF создается, вы присваиваете хэш имени файла pdf и сохранить его на диске. теперь у вас есть простая система кэширования, где вы можете посмотреть, существует ли файл PDF, и если да, верните его, иначе сгенерируйте его и кешируйте.

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

Answer 2

Самая простая практика заключается в отсутствии сервера веб-сервера и сервера db на одном и том же оборудовании. Я бы начал с этого.

Answer 3

В дополнение к рекомендации для отдельных веб & серверов БД, я пытался:

а) перемещения запросов в хранимые процедуры, если вы не используете их еще;

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

Надеюсь, это поможет.

Answer 4

Вы должны отделить восприятие между созданием PDF и выполнением вычислений. Оба являются отдельными шагами.

Что вы можете сделать, это

1) Создание отчета вычисленную таблицу, которая будет работать ежедневно и заселена она со всеми расчетными значениями для всех отчетов.

2) Когда кто-то запрашивает отчет в формате PDF, попросите отчет выполнить простой запрос предварительно рассчитанных значений. Это будет гораздо меньше усилий db, чем вычисление «на лету». Вы можете использовать coldfusion для создания PDF-файла, если он использует модные настройки PDF. В противном случае вы сможете уйти с использованием необработанного формата PDF (он похож на html-разметку) в текстовой форме или использовать другую библиотеку (cfx_pdf, подходящую библиотеку java и т. Д.) Для их создания.

Если пользователям не нужно загружать и нужно только просматривать/распечатывать отчет, не могли бы вы уйти с флэш-бумагой?

Альтернативой является также создание очереди отчетов. Если вы разместите его на втором сервере или нет, что может сделать CF, если вы можете с ним справиться, вы можете отправить запросы отчетов в очередь и отправить их пользователям по мере их обработки.

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

Как уже упоминалось выше, выполнение хранимой процедуры также может помочь, и убедитесь, что ваши индексы правильно установлены в MySQL. У меня когда-то был 3-минутный запрос, который я сбил до 15 секунд, потому что забыл объявить дополнительные индексы в каждой таблице, которые были в большой степени использованы.

Дайте нам знать, как это происходит!