Функции CFSpreadSheet, использующие память для больших наборов данных

Question

У нас есть приложение Coldfusion, которое выполняет большой запрос (до 100 тыс. Строк) и затем отображает его в HTML.Затем пользовательский интерфейс предлагает кнопку «Экспорт», которая инициирует запись отчета в электронную таблицу Excel в формате .xlsx с использованием тегов cfspreadsheet и функции электронной таблицы, в частности, spreadsheetSetCellValue для построения значений столбцов строк, функций spreadsheetFormatRow и spreadsheetFormatCell для форматирования.Затем ssObj записывается в файл, используя:

<cfheader name="Content-Disposition" value="attachment; filename=OES_#sel_rtype#_#Dateformat(now(),"MMM-DD-YYYY")#.xlsx">
<cfcontent type="application/vnd-ms.excel" variable="#ssObj#" reset="true">

, где ssObj - это объект SS.Мы видим размер файла около 5-10 МБ.

Однако ... использование памяти для создания этого отчета и записи файла увеличивается примерно на 1 ГБ.Сложная проблема заключается в том, что память не освобождается сразу после завершения экспорта с помощью Java GC.Когда несколько пользователей запускают и экспортируют отчеты такого типа, объем памяти продолжает расти и достигает выделенного размера кучи, что снижает производительность сервера до такой степени, что он отключает сервер.Перезагрузка обычно необходима, чтобы очистить его.

Это нормальное / ожидаемое поведение или как мы должны решать эту проблему?Можно ли легко освободить использование памяти этой операцией по требованию после завершения экспорта, чтобы другие, выполняющие отчет, могли легко получить доступ к свободному пространству для своих отчетов?Является ли этот тип использования памяти для файла размером 5-10 МБ общим с функциями cfspreadsheet и записью объекта?

Мы попытались временно удалить дорогостоящие функции форматирования, и все же использование памяти велико для создания и записифайл .xlsx.Мы также пытались использовать подход spreadsheetAddRows и тег cfspreadsheet action = "write" query = "queryname", передаваемый в объект запроса, но это тоже занимало много памяти.

Почему эти функции так плохо работают с памятью?Каков оптимальный способ создания файлов Excel SS без этой проблемы нехватки памяти?

Я должен добавить, что сервер работает в контейнере Apache / Tomcat в Windows, и мы используем CF2016.

Answer 1

• Сколько памяти вы выделили для своего экземпляра CF?
• Сколько экземпляров вы запускаете?
• Почему вы разрешаете кому-либо просматривать записи 100 000 в HTML?
• Почему вы разрешаете кому-либо экспортировать столько данных на лету?

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

Начните с настроек памяти.Вы можете получить повышение по всем направлениям, удвоив или утроив то, что выделено приложению.Также убедитесь, что вы используете последнюю версию поддерживаемого JDK для вашей версии CF.Это также может иметь огромное значение.

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

Это приложение также обрабатывало безумное количество данных, и пользователи постоянно хотели "всего этого".Нам пришлось форсировать результаты поиска и определенные наборы данных, чтобы уменьшить количество, отображаемое на экране.БД была вполне довольна этим решением.Экспорт данных был перемещен в очередь, чтобы они могли создавать эти большие файлы Excel вне обычных запросов страниц.Может быть, они получили свои данные немедленно, может быть, некоторое время ждали, чтобы получить уведомление.В любом случае, приложение работало лучше по всем направлениям.