Каковы наилучшие методы ускорения работы блестящего приложения?

Данные:

У меня есть блестящее приложение панели мониторинга, и мой набор данных составляет около 600 МБ. Каждый месяц он набухает на 100 МБ. Мои данные хранятся локально в MySQL.

MenuItems:

У меня есть 6 - 7 боковых меню на моей панели инструментов, и каждый из них имеет 10-12 различных выходов - диаграммы и таблицы. Каждая из этих вкладок имеет 3 - 6 входов, таких как selectizeInput, ползунок, диапазон дат и т.д. Для фильтрации данных.

Подмножества данных:

Так как я не могу загрузить все данные в память, для каждого элемента меню я создаю подмножество данных на основе диапазона дат, сохраняя диапазон дат всего в 2 - 3 дня от системной даты.

Например:

df1 <- reactive({df[df$date >- dateinput[1] & df$date <- dateinput[2], ]})

Приведенные выше данные для моего первого пункта меню и в зависимости от selectInput или других входов, я далее фильтрую данные. Например, если у меня есть selectInput для Gender (male and female), то я далее подмножество df1:

df2 <- reactive({
       if(is.null(input$Gender)){ 
          df1 
       } else if(input$Gender == "Male") 
          {df1[df1$Gender == "Male",]} 
       )}

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

Чем больше количество элементов menuItem я создаю больше подмножеств для соответствия фильтрам и анализу.

Я сталкиваюсь с двумя проблемами:

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

После первого набора нагрузки данных диаграммы и таблицы получают более быстрое реагирование на реактивные изменения.

Чтобы противостоять этому, я попытался переместить все общие и повторяющиеся параметры и библиотеки в global.R.

У меня есть два вопроса:

1. Существуют ли какие-либо основные гигиенические факторы, которые следует учитывать при добыче данных в R, особенно через блестящие (Mining in R очень быстро).

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

Обратите внимание: я исследователь, а не программист, но научился использовать блестящие и хост-приложения в облаке или недавно недавно.

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

Ответы

Ответ 1

Это очень интересный вопрос и заслуживает более правильных ответов, а не комментариев. Я хотел бы рассказать о своем опыте и мыслях. Я создал коммерческое приложение R+shiny с Shiny Server Pro, используя базы данных и множество других трюков.

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

Проблема

Shiny - одностраничное приложение. Поэтому сложное приложение с множеством вкладок, загруженными для заполнения некоторых меню и селекторов и т.д., Начинается с начального времени загрузки.

UI возможные смягчения

  • Используйте динамические компоненты пользовательского интерфейса (мудро), чтобы добавить сложность после запуска. Например, конкретное меню может начинаться очень просто с нескольких элементов, а затем добавлять дополнительные элементы на более позднем этапе.
  • Джо Чэн предложил insertUI и removeUI, когда мое приложение было почти закончились, поэтому я не стал их использовать, но они также могли способствуют созданию более простой страницы для запуска.

Использование базы данных

Мое приложение использовало MonetDB и позже PostgreSQL. Производительность MonetDB была хорошей, но у меня был конфликт с несколькими пользователями (сложная проблема, которую я не могу описать здесь), и это заставило меня перейти на PostgreSQL в качестве альтернативы. PostgreSQL было хорошо, но для начала потребовалось драматическое время из-за проблемы с потерей кеша. Конструкция, необходимая для загрузки при запуске нагрузок данных в DB: плохая конструкция.

СУРБД задерживает возможные смягчения

Думаю, я пробовал большинство трюков с переменным успехом.

  • Ограничение использования РСУБД. Поскольку я решил с самого начала использовать data.table для ускорить манипуляции данными без ограничений путем копирования, я также использовал fread для любого типа чтения csv. В то время fwrite (еще от data.table) даже не был на горизонте, в противном случае это заслуживает серьезных соображений.
  • Реконструкция приложения. архитектура приложения имеет много общего со степенью интенсивности, используемой СУБД. Я убежден, что время может быть сохраненный дизайном, который может принимать во внимание R+shiny (главным образом R) ограничения.
  • Теперь MonetDB имеет R функции, встроенные в код, поэтому он должен быть даже быстрее, чем раньше. Это, безусловно, заслуживает хорошего взгляда. С другой вручную многопользовательские функции должны быть тщательно протестированы: большинство из R код базы данных не учитывается для использования в многопользовательском режиме среды, предлагаемой Shiny. Может быть, RStudio должен делать что-то еще об этом. Честно говоря, они уже начались, экспериментальное введение connection pools, и это здорово.

Чрезмерное использование реактивности

Я думаю, что здорово играть с продвинутой инфраструктурой, например, Shiny, и реактивность - это много интересного для изучения. С другой стороны, широкое и сложное приложение может легко выйти из-под контроля.

Чрезмерная реактивность возможных смягчений

  • Отладка каждой функции дает точное представление о том, сколько раз определенная функция Shiny, и любая реактивная функция называемых обычно более одного раза. Конечно, все это сжигает процессорное время, и требуется, по крайней мере, держать под контролем.
  • Конструкции типа observeEvent теперь имеют такие параметры, как ignoreInit: разумное использование этих параметров может сэкономить, по крайней мере, время инициализации.

По моему опыту мы только поцарапали поверхность того, что можно сделать с Shiny. С другой стороны, существует предел из-за единственного процесса процесса R. С помощью Shiny Server Pro можно предусмотреть использование балансировщика нагрузки и распространение нескольких пользователей на разных серверах. С другой стороны, чтобы попасть на эти территории, нам понадобится какая-то система обмена сообщениями в разных случаях. Уже знаю, что я вижу необходимость этого в сложных приложениях Shiny Server Pro (например, при необходимости управлять разными классами пользователей, но в то же время общаться между ними). Но это выходит за рамки этого вопроса SO.