MCP HubMCP Hub
Retour aux compétences

optimize-shiny-performance

pjt222
Mis à jour 2 days ago
2 vues
17
2
17
Voir sur GitHub
Métageneral

À propos

Cette compétence aide les développeurs à profiler et optimiser les applications Shiny lentes ou non réactives en utilisant des techniques telles que la mise en cache, les opérations asynchrones et le contrôle des flux réactifs. Elle fournit des outils pour identifier les goulots d'étranglement et est idéale pour préparer les applications à une mise en production avec une charge concurrente élevée. Les capacités clés incluent profvis, bindCache, memoise, et la gestion des calculs de longue durée avec ExtendedTask.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/optimize-shiny-performance

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Optimize Shiny Performance

Profile + opt: caching, async, reactive graph.

Use When

  • Slow / unresponsive interaction
  • Server resources exhausted under concurrent load
  • Specific ops bottleneck (data load, plot, compute)
  • Prep for prod w/ many users

In

  • Required: Path to Shiny app
  • Required: Perf problem desc (slow load, laggy, high mem)
  • Optional: Expected concurrent users
  • Optional: Server resources (RAM, CPU cores)
  • Optional: DB or API used?

Do

Step 1: Profile

# Profile with profvis
profvis::profvis({
  shiny::runApp("path/to/app", display.mode = "normal")
})

# Or profile specific operations
profvis::profvis({
  result <- expensive_computation(data)
})

ID top bottlenecks:

  1. Data load: initial fetch time?
  2. Reactive recalc: which reactives fire most?
  3. Render: which outputs slowest?
  4. External: DB queries, API, file I/O?

Reactive log for graph analysis:

# Enable reactive logging
options(shiny.reactlog = TRUE)
shiny::runApp("path/to/app")
# Press Ctrl+F3 in the browser to view the reactive graph

→ Clear ID of 2-3 biggest bottlenecks.

If err: profvis not detailed → wrap specific sections w/ profvis::profvis(). Reactlog overwhelming → focus one interaction at a time.

Step 2: Opt reactive graph

Cut unnecessary invalidations.

# BAD: Recomputes on ANY input change
output$plot <- renderPlot({
  data <- load_data()  # Runs every time
  filtered <- data[data$category == input$category, ]
  plot(filtered)
})

# GOOD: Isolate data loading from filtering
raw_data <- reactive({
  load_data()
}) |> bindCache()  # Cache the expensive part

filtered_data <- reactive({
  raw_data()[raw_data()$category == input$category, ]
})

output$plot <- renderPlot({
  plot(filtered_data())
})

isolate() to prevent unnecessary invalidations:

# Only recompute when the button is clicked, not on every input change
output$result <- renderText({
  input$compute  # Take dependency on button
  isolate({
    paste("N =", input$n, "Mean =", mean(rnorm(input$n)))
  })
})

debounce() + throttle() for high-freq inputs:

# Debounce text input — wait 500ms after user stops typing
search_text <- reactive(input$search) |> debounce(500)

# Throttle slider — update at most every 250ms
slider_value <- reactive(input$slider) |> throttle(250)

→ Reactive graph fires only necessary recalcs.

If err: removing dep breaks → use req() for explicit guards instead of implicit reactive deps.

Step 3: Caching

bindCache for outputs

output$plot <- renderPlot({
  create_expensive_plot(filtered_data())
}) |> bindCache(input$category, input$date_range)

output$table <- renderDT({
  expensive_query(input$filters)
}) |> bindCache(input$filters)

bindCache uses inputs as cache keys. Same inputs → cached result returned immediately.

memoise for fns

# Cache expensive function results
load_reference_data <- memoise::memoise(
  function(dataset_name) {
    readr::read_csv(paste0("data/", dataset_name, ".csv"))
  },
  cache = cachem::cache_disk("cache/", max_age = 3600)
)

App-level pre-compute

# In global.R or outside server function — computed once at app startup
reference_data <- readr::read_csv("data/reference.csv")
model <- readRDS("models/trained_model.rds")

server <- function(input, output, session) {
  # reference_data and model are available to all sessions
  # without reloading
}

→ Repeated ops use cache; response time drops.

If err: cache too big → set max_age / max_size. Stale → reduce max_age or cache-clear button. bindCache errors → ensure cache key inputs serializable.

Step 4: Async for long ops

ExtendedTask (Shiny ≥ 1.8.1):

server <- function(input, output, session) {
  # Define the extended task
  analysis_task <- ExtendedTask$new(function(data, params) {
    promises::future_promise({
      # This runs in a background process
      run_heavy_analysis(data, params)
    })
  }) |> bind_task_button("run_analysis")

  # Trigger the task
  observeEvent(input$run_analysis, {
    analysis_task$invoke(dataset(), input$params)
  })

  # Use the result
  output$result <- renderTable({
    analysis_task$result()
  })
}

For Shiny < 1.8.1, promises directly:

library(promises)
library(future)
plan(multisession, workers = 4)

server <- function(input, output, session) {
  result <- eventReactive(input$compute, {
    future_promise({
      Sys.sleep(5)  # Simulate long computation
      expensive_analysis(isolate(input$params))
    })
  })

  output$table <- renderTable({
    result()
  })
}

→ Long ops don't block UI; other users can interact during.

If err: future_promise errors → check plan(multisession) set. Vars unavailable in future → pass explicitly (separate R process).

Step 5: Opt rendering

Cut render overhead.

# Use plotly for interactive plots instead of re-rendering
output$plot <- plotly::renderPlotly({
  plotly::plot_ly(filtered_data(), x = ~x, y = ~y, type = "scatter")
})

# Use server-side DT for large tables
output$table <- DT::renderDataTable({
  DT::datatable(large_data(), server = TRUE, options = list(
    pageLength = 25,
    processing = TRUE
  ))
})

# Conditional UI to avoid rendering hidden elements
output$details <- renderUI({
  req(input$show_details)
  expensive_details_ui()
})

→ Render faster, no UI block.

If err: plotly slow w/ big data → toWebGL() or downsample before plot.

Step 6: Validate

# Before/after benchmarking
system.time({
  shiny::testServer(myModuleServer, args = list(...), {
    session$setInputs(category = "A")
    session$flushReact()
  })
})

# Load testing with shinyloadtest
shinyloadtest::record_session("http://localhost:3838")
shinyloadtest::shinycannon(
  "recording.log",
  "http://localhost:3838",
  workers = 10,
  loaded_duration_minutes = 5
)
shinyloadtest::shinyloadtest_report("recording.log")

→ Measurable improvement in response times / concurrent capacity.

If err: no improvement → re-profile for next bottleneck. Iterative — fix biggest first, re-measure.

Check

  • Profiling IDs specific bottlenecks (not guessing)
  • Reactive graph: no unnecessary invalidation chains
  • Expensive ops use cache (bindCache/memoise)
  • Long ops use async (ExtendedTask/promises)
  • High-freq inputs use debounce/throttle
  • Big data → server-side
  • Improvement measurable (before/after)

Traps

  • Premature opt: profile first. Bottleneck rarely where you think
  • Cache invalidation bugs: stale data → cache key missing inputs. Add deps to bindCache()
  • Future variable scoping: future_promise = separate process. Globals, DB conns, reactive vals → capture explicitly
  • Reactive spaghetti: too complex graph → architectural refactor (modules), not just cache
  • Over-caching: caching all = waste mem. Only expensive ops w/ repeated input patterns

  • build-shiny-module — modular arch for maintainable reactive code
  • scaffold-shiny-app — pick right framework from start
  • deploy-shiny-app — deploy optimized w/ proper resources
  • test-shiny-app — perf regression tests

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/caveman-ultra/skills/optimize-shiny-performance
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

content-collections

Méta

Cette compétence propose une configuration éprouvée en production pour Content Collections, un outil axé sur TypeScript qui transforme des fichiers Markdown/MDX en collections de données typées de manière sûre avec une validation Zod. Utilisez-la lors de la création de blogs, de sites de documentation ou d'applications Vite + React riches en contenu pour garantir la sécurité de typage et la validation automatique du contenu. Elle couvre tout, de la configuration du plugin Vite et de la compilation MDX à l'optimisation des déploiements et la validation des schémas.

Voir la compétence

polymarket

Méta

Cette compétence permet aux développeurs de créer des applications avec la plateforme de marchés prédictifs Polymarket, incluant l'intégration d'API pour le trading et les données de marché. Elle fournit également une diffusion de données en temps réel via WebSocket pour surveiller les transactions en direct et l'activité du marché. Utilisez-la pour mettre en œuvre des stratégies de trading ou pour créer des outils traitant les mises à jour de marché en direct.

Voir la compétence

creating-opencode-plugins

Méta

Cette compétence aide les développeurs à créer des plugins OpenCode qui s'interconnectent avec plus de 25 types d'événements tels que les commandes, les fichiers et les opérations LSP. Elle fournit la structure du plugin, les spécifications de l'API événementielle et les modèles d'implémentation pour les modules JavaScript/TypeScript. Utilisez-la lorsque vous avez besoin d'intercepter, de surveiller ou d'étendre le cycle de vie de l'assistant IA OpenCode avec une logique personnalisée pilotée par les événements.

Voir la compétence

sglang

Méta

SGLang est un framework de service LLM haute performance spécialisé dans la génération rapide et structurée pour les workflows JSON, regex et agentiques grâce à son cache de préfixe RadixAttention. Il offre une inférence nettement plus rapide, particulièrement pour les tâches avec des préfixes répétés, ce qui le rend idéal pour les sorties complexes et structurées ainsi que les conversations multi-tours. Choisissez SGLang plutôt que des alternatives comme vLLM lorsque vous avez besoin d'un décodage contraint ou que vous construisez des applications avec un partage étendu de préfixes.

Voir la compétence