鉴于某位朋友嫌文章发的太冷清，本着语不惊人死不休的精神，今天这篇文章就是来拉仇恨的了，呵呵

今天发的这些东西肯定是片面的，不客观的！但为了让自己少掉坑，也为了解答吃瓜群众的疑惑，有些“真相”不吐不快，路见不平的朋友请高抬贵手，欢迎拔嘴相喷，修养高的朋友就权当看笑话吧。

用RStudio也有一段时间了，但真正开始使用RStudio Server版则只有半年多的时间，自从接触了这个Server版之后，就让我越来越羞愧，不管是工作上还是生活上越来越抬不起头！

为啥？难道是男人的难言之隐？哈哈，事情也没那么复杂，说起来就三个字：不痛快！说明白点，一句话：不能手起刀落，砍瓜切菜般解决问题了！作为一个老司机，这怎么能忍？

这个RStudio Server真有说的这么恐怖？今天得空，就仔细的审视剖析了一番：

首先我们先数落一下RStudio Server的一些“罪状”：

1.资源耗尽时，直接崩溃，environment直接清空，完全不给你挽救的机会；

2.执行过程不透明，执行了N天最后憋出来一个崩溃，仅凭一点点事后残留的“JY”，完全不知道执行到哪出错了；

3.工作空间加载缓慢，有时候不小心关了浏览器，对不起，你想再进来，先在外面凉快凉快！

4.“工会”很“团结”，一旦罢工就是联合罢工，看着满屏的圈圈，心都凉了半截！

……

好了，说了这么多RStudio Server的缺点，那这些究竟是什么原因造成的呢？

所谓冰冻三尺非一日之寒，我在这里也给大家挖一挖RStudio Server的“寒毒”

1.RStudio Server的解决方案：

首先我们得从RStudio Server的使命说起，Server版的RStudio，最主要的任务就是能在web界面上执行R，那如何才能做到这一点呢？先看看RStudio Server的信息传递链：
    RSession -> C++ -> Java -> WebSocket -> html+js

咋一看去，涉及到的环节还挺多的，看到骨子里，其实就三块：R+数据桥梁+web服务

2.分析原因：

用fiddler抓包看了看RStudio Server的通讯过程，其中就包含了许多rpc请求

1. web界面上的js会向Java发送一个rpc请求，Java如果处理不过来，该请求就会阻塞，直至超时；

2. web界面判断未完成的任务，还会定期发送rpc/event作为心跳，与Java保持沟通；

3.RSession执行完后返回给c++,c++通过event通知Java,Java等待下次rpc/event时就会将结果呈现到web界面；

搞清除了RStudio工作的大致流程，我们可以看出，RStudio目前的架构很糟糕，不适合大规模并发请求，对时间要求很高很频繁的互动性操作恐怕也不太胜任。本来想针对RStudio的问题做一些优化工作，但看到基本盘是这样的，优化的动力瞬间没了。

这种架构本身就是具有高度阻塞风险的，所以如果一旦RStudio Server界面卡顿，有以下几项措施可以尝试下：

1.多刷新几次（千万不要整体刷新，局部刷新界面上的模块就好了），有可能Java Web阻塞了界面中的某项请求，刷新一下就能出来；

2.RSession可能执行死掉了，重启RSession，或者直接到服务器上kill掉RSession；

对RStudio Server的建议：

1.采用无阻塞的异步式架构，不一定非要用Java web技术，可以用nodejs等，这样不必等待某个卡住的模块，其他模块照样能正常提供服务；

2.整个界面都是由rpc请求完成，这是不太合适的，完全可以把一部分不会变化的html和js框架部分由简单的http服务器完成，这样即使rpc服务超时了，至少始终还有部分功能是能使用的；

好了，黑了这么多，总而言之，RStudio还是一款很优秀的R集成开发环境，

俗话说的好，工具是死的，人是活的，就看你怎么用。

但我还是要最后黑一句：你把Server版做好一点能死人吗？屌丝可没功夫琢磨怎么用好你，计算交给你，时间留给妹子和娃 ;-)