I have created an R shiny app to create some output. When I run it in local the app generates and downloads output instantaneously.
But when I publish it on a free R shiny server, it takes almost 20-30 mins to download the same file. The file size is 10MB.
Can you tell me the reasons for this?
Is there a work around ? Do I need to purchase a premium Rserver or something?
There is no common measures between a desktop computer and a web server especially mutualized servers such as free offering from cloud servers. Your desktop computer is often far more powerfull (memory/cpu/network).
Beside this the download is handled by the internal web server of shiny (httpuv to name it). It is quite good but not as good as full blown web servers that are built for this (apache, nginx, ...)
Moreover R is mostly single threaded (that means it does one thing at a time). Handling a download and responding to the user through UI are separate tasks.
Related
For security reasons, I need to run a Shiny app on an internal server. I am able to talk to IT about getting it there, but I am one of two people at my company who use R, so IT has never come across this situation before.
I have been looking online for ways to support a shiny app internally, but I have not been able to really find anything useful that has been posted recently. I know R changes frequently and is constantly improving, so articles from 2010 or 2014 aren't as helpful as I'd like.
I am looking for information I can bring to my IT department to help them get my app onto the internal server without them having to do a lot of research into R.
The answer very much depends on your needs, depending on the complexity of the app and the number of simultaneous users. Since this is only internal, you may not need to go through the lengths described in Pork Chop's comment.
In the most basic instance, you can load RStudio on an existing server and use runApp (the normal way of initializing a shiny app). In the top left corner you will see an internal http address, as well as an "Open in Browser" button. Any user connected to the server can navigate to the internal address and use the app. If you are unlikely to have concurrent users, and don't mind dedicating an RStudio instance to the app, then this is the easiest way for IT to deal with it. Note that this implementation is very limited.
The next level up would be an open source Shiny Server Community Edition, which is free to use. The process to set it up is more complex, but is covered here: http://docs.rstudio.com/shiny-server/ Please note that this is the documentation for the pro version, however I believe that it is the same documentation for the open source version. All of the open source guides link to it on shinyapps.io. To download Shiny Server Community Edition visit here: https://www.rstudio.com/products/shiny/download-server/ or you can look at the differences in products here: https://www.rstudio.com/products/shiny/shiny-server/
This question isn't code-specific, however I believe the question is widely applicable to a large audience (anybody who cares about the scalability of hosting R Shiny apps), and hope it doesn't get closed.
The title addresses the question fairly well here. I am building a fairly detailed R Shiny app that I plan to launch as a full-fledged web application, with hopes that the number of users of the app will be fairly large. Per this post - Does R-Server or Shiny Server create a new R process/instance for each user? - open source shiny server uses only 1 R process for my app, and even shiny server pro uses only 10-20 processes. In a reddit thread I posted asking about RShiny / ShinyServer's scalability, I was hit the the following response: There is zero chance you can scale to thousands of concurrent users using shiny server.
So here's my question: was that reddit answer correct? In particular, I currently have an EC2 instance (the smallest, free tier t2.micro) with my app that works fine (I have not released my app to the public yet). Could I use multiple, more powerful EC2 instances (each with ShinyServer installed, and the code for my apps on the instances), as well as an ELB to balance traffic, in order to improve the scalability of my RShiny app? If each instance has the free, open-source ShinyServer, could I do this without needing ShinyServer pro? I could probably pay for hundreds of EC2 instances before the cost would exceed that of 1 year of ShinyServer Pro.
Thanks in advance!
I can not avoid windows at work. As such, I have a second machine that I use to do all of my heavy lifting and data analysis. In an ideal world, I could create a Shiny app and access it from another computer on my work's local network.
The solution that my IT folks proposed was using Remote Desktop, which COULD work, but I don't really want other users locking the machine.
Does anyone have insight as to how I can allow computers on my network to view my Shiny apps? I should have admin rights on my 2nd machine in case I need to tweak a few settings.
EDIT: While my ideal use case is Shiny, I would also want to access other R-based reports like Slidify presentations, compiled R Markdown reports, and perhaps, Gitbooks compiled to stand-alone websites.
Thanks in advance.
It should be sufficient to set the host argument to 0.0.0.0 to allow it to broadcast beyond localhost, e.g.
runApp("app_name",host="0.0.0.0",port=3168)
Then you can visit http://machine2DNSname:3168 to see it.
I'm interested in using a statistical programming language within a web site I'm building to do high performance stats processing that will then be displayed to the web.
I'm wondering if an R compiler can be embedded within a web server and threaded to work well with the LAMP stack so that it can work smoothly with the front-end and back-end of the web site and improve the performance of the site.
If R is not the right choice for such an application, then perhaps there is another tool that is?
The general rule is that webserver should do NO calculations -- whatever you do, it will always end in a bad user experience. The way is that the server should respond to calculation request by scheduling the job for some worker process, give the user some nice working status and then push the results obtained from worker when they are ready (most likely with AJAX polling or some more recent COMET idea).
Of course this requires some RPC protocol to R and some queuing agent -- this can be done either with background processes (easy yet slow), R HTTP servers (more difficult yet faster), or real RPC like Rserve or triggr (hard, yet fast to ultra-fast).
You are confusing two issues.
Yes, R can be used via a webplatform. In fact, the R FAQ has an entire section on this. In the fifteen+ years that both R and 'the Web' have ridden to prominence, many such frameworks have been proposed. And since R 2.13.0 R even has its own embedded web server (to drive documentation display).
Yes, R scripts can run faster via the bytecode compiler, but that does not give you orders of magnitude.
It's one of those things I see a lot but never really think of. Do you think for the purpose of web application development (specifically ASP.NET WebForms/MVC). Do you think it's advantageous to do such a thing and if so, what kind of advantages come out of it?
By virtualization I mean using products like Hyper-V to separate the server context like your SQL and Web Server, etc.
First question is, virtualization of what? Do you mean server virtualization? Do you mean running VMWare on each dev's laptop with multiple OSes? Do you mean moving everything to the cloud?
Virtualization of servers, in web app context, is not really different from that in general IT - most of the servers on the Internet, including StackOverload's, are bought to handle peak loads and spend most of the time idling away the cycles, so virtualizing them makes sense when you have more than a certain amount.
VMWare on the desktop (or other parallels on other operating systems) is superb because a) your devs can run a full instance of your server environment, including multiple virtual servers connnected in a virtual network - this is about as close to the real thing that you can get, minus hardware costs and minus devs messing with each other's servers. For clients, you can use Linux and multiple Windows installs to test various browsers, font sizes, etc. quickly - also a big win.
Moving everything to the cloud makes sense in many cases, but is probably a topic for a separate full-sized question :)
One big advantage I see is, that every developer can have his/her own sandbox to work on. If someone messes up his/her sandbox he/she can take a clean image and all is OK again. So I guess that means that there is room to experiment without losing valuable time getting back to the normal setup, you can simply do a rollback.
I'm in doubt a bit on whether you should use virtualisation for production environments. Depending on the application of course.
The only time I would use a virtual for ASP.Net development was if the app required specific setup, such as relying on installed software, wierd settings or particular shares. Every developer has their own webserver and can run their own database so if it's a "basic" webapp I don't see much value in virtuals.. it's pretty hard to break anything with a basic web app deployment :)
With a virtual server, you can test your code in a production-like environment. It is also possible to quickly revert back to the original setup. For many applications, it is useful in that time period just after you write the code, but before it goes to production.
I'm a fan of virtualizaion and use it in testing and production (VMWare and Hyper-v) but over the last year I find it less important on a dev machine. TFS provides me with all the backup/rollback ability that I need, multiple versions of .net can now exist on the same machine and VS2008 can target all those versions.
In a development environment a virtual environment is useful to put several different servers on one box, you can have an instance for your web app, one for your services, one for database, etc. That way it mimics your production environment if you are using separate servers.
One of the benefits of using virtualization in production is that your application is not tied to a specific machine. If you wanted to move your web server instance to another box, it is trivial to do so. You don't need to install or configure things on the new server and hope that everything is set up properly.
One problem I have had though in testing virtual instances is that it can run slower for some applications, specifically engineering apps that like running the CPU at 100%. So test before you leap.