0

I have a Shiny app which uses two mysql queries to retrieve data and the app works well when run from RStudio. (one of the queries is taking around 8 minutes)

But when I move it on a Shiny Server and access http://ip/myapp/, the page it's loading for a while and the I get "Problem loading page" .

I assume it's because the long query. Is there some good way to deal with this situation, when long queries have to be made from Shiny app?

-- (running locally app.R from RStudio, works fine)

Info about the app:

  • Location: /srv/shiny-server/myapp

  • Filename: app.r

  • File structure:

    -- load libraries

    library(shiny)

    ...

    -- Connection and queries

    con <- dbConnect(MySQL(),
                 user = '#',
                 password = '#',
                 host = '#',
                 dbname='#')

tickets<-dbGetQuery(con, "Select * from table")
dbDisconnect (con)
con <- dbConnect(MySQL(),
                 user = '#',
                 password = '#',
                 host = '#',
                 dbname='#')
-- long query
issues_speed_unique<-unique(na.omit(dbGetQuery(con,"Select * from table2")))
dbDisconnect (con) 

some aggregations....

    -- Server code

    shinyServer(
  function(input,output){
     ...

    -- ui code

    shinyUI(fluidPage(
     ...

shinyApp(ui = ui, server = server)
adlisval
  • 341
  • 1
  • 7
  • 17
  • 1
    Check [this](http://docs.rstudio.com/shiny-server/#application-timeouts) page out on shiny server administration. My guess is it's timing out due to taking more time than the server allows so it's timing out. – Andrew Taylor Dec 23 '16 at 12:44
  • if the problem will persist, I would suggest to change the app architecture. You can either: a) use faster DBs (monetdb comes to mind, or any in-memory db); b) try to load everything in memory at startup (e.g. using data.table library); c) or chunk your queries somehow (ultimately fetching less data). As a variant of a. you can experiment with out-of-core techniques like using ff library or similar tools (definitely no-sql though!). My favourite would be either a. or b. depending on use case. – Enzo Dec 23 '16 at 16:10

0 Answers0