$，这是书本上表示的命令提示符。你要看一下书本上的前言或者第一章，一般书本在最开始会说明一下符号，字体格式代表的含义，你没有从头看起，漏掉了重要的提示信息。书本开头肯定告诉你$，表示命令提示符，这个字符不需要你输入的。
cd testsass已经成功了，你又用cd ..返回了，这是不对的。
touch style.css，要单独输入的，不要和cd命令混在一块。
你连基本的命令行概念都没有搞懂。
$是Linux的提示符，你用了Windows，估计后面很多问题，因为书本是以Linux为目标系统个来写的。
我们知道Rails应用的内存占用通常都是比较高的，尤其是比较重型的全栈应用内存使用更接近1G（当然同时也包括想sidekiq这样加载整个Rails应用的ruby进程），所以我们通常对应这种情况都采取一种比较tricky的方式，使用像 puma_worker_killer 这样的监控程序，监控rails进程达到一定内存占用后将其重启。也就是说应用一开始的内存占用通常都在100~300MB之间，随着时间的推移进程会创建大量的『对象』内部又会进行数次内存分配和回收，所以内存就会不断飙升。
在我们知道了基本情况之后，那就该说说正题如何优化Rails的内存占用，解决方案有若种，我们这里讲解一个最容易实施而且见效最快的方式，就是从内存分配入手。ruby使用glibc的malloc(3)进行内存分配，这是一个比较古老的内存分配器，性能比较低分配时会产生大量碎片。所以真的这一点，现在由很多性能比较出色由兼容原有API和以及被验证过的特性的新分配器，如jemalloc和tmalloc，这里我们就使用jemalloc作为Ruby应用的内存分配器，来看看能达到什么样的优化效果。
jemalloc是facebook出品的，最早用于FreeBSD中的内存分配器，后来像firefox从3.0也开始使用它，redis从2.4之后默认在linux上使用jemalloc。既然有这么多性能敏感型的软件都使用了jemalloc那它一定有过人之处。
jemalloc的特别之处在于它融合了其他内存分配技术的优势，并且采用多级内存分配，线程池缓存tcache还有划分内存区来减少线程间锁的争用。
jemalloc结构：
多级内存分配 ：jemalloc根据对象的大小，将其归为划分为 small object, large object和huge object三类
Arena : jemalloc 没有像malloc那样对内存的划分都几种在一个区域中管理，而是使用多个小块的内存区域来分别管理，内个小块称为"arena" 。
线程池缓存thread cache ：tcache是分配线程的缓存空间，jemalloc使用tcache来减少线程内存分配中锁竞争，从而提升分配效率，每个tcache对应一个arena。
这一步我们来看看应用Jemalloc到我们的ruby进程中到底能有多大的提升呢。
安装
我们选择在2.4.1版本上进行测试。除了上面这种安装方式外，也可以通过gem包来安装 jemalloc-rb
内存使用
我们在同一个应用运行的两台服务器中的一个上面安装的jemalloc，而另一套作为对照组没有安装。
这里就贴出性能差距最明显的一个进程 rails应用的sidekiq进程
没有使用jemalloc的服务器上面的sidekiq进程
使用jemalloc的服务器上面的sidekiq进程
可以看到差距是很明显的，当然不是每个进程都有这样的优化效果，这个我们总结的时候再说。
从上面的jemalloc的前后对比图中我们能够看出jemalloc的优化还是有明显效果的。至于为什么sidekiq和puma之前的差距这么大，这就引出了，其实jemalloc仅是从内存分配的程度去优化和改进内存使用和性能，在你的应用程序大量产生对象，并且长久运行下去的情况时，效果就比较明显，而如果应用本身做的就比较精简，从程序角度优化的比较好的话，jemalloc的提示就不明显。所以说jemalloc可以为你的应用内存性能解燃眉之急，但是从系统性的角度出发，还是从自身出发优化好应用本身的性能。
Phusion Passenger是一个流行的Web应用服务器，它最初是针对Ruby的，现在也支持Node.js应用。在今年的早些时候该功能被引入了Passenger的企业版中，但是现在已经开源并随着最近的4.0.21免费版发布。Passenger能与Apache或者Nginx Web服务器集成，旨在成为一个服务、监控和扩展Web应用程序的完整解决方案。Phusion公司的 总部位于荷兰 ，他们宣称在Passenger中运行 Node.js 应用的好处包括：
多租户——通过最小的配置运行一些应用的能力
监控——自动启动Node.js进程、如果进程崩溃了则重启它们
扩展——根据要处理的请求的数量增加或者减少进程的数量
统计——帮助显示运行中进程的状态的工具
Passenger的作者 还指出 ，与Apache/Nginx集成还带来了其他的好处，例如：加速了静态文件服务，阻止了很多常见的攻击和慢客户端。
该公告标志着Phusion向自己宣称的让Passenger最终成为一个多语言应用服务器的目标更进了一步。去年，Passenger对 Python的支持到达了beta状态 ，并于最近完成。紧跟着发布了支持Node.js的公告，Phusion还 推出 了 Meteor （一个基于Node的应用框架）支持。
Passenger本身是用C++编写的，它没有和Ruby或者任何其他的语言紧耦合。版本4中的一些架构发生了一些变化。Passenger内部的I/O处理器现在是事件驱动的，和Node.js的工作原理相似，同时企业版支持混合多进程和多线程执行，这是为了在支持通过WebSockets进行流媒体直播这样的功能时最大化资源利用率。
Passenger还为Ruby应用提供了“带外（out of band）”执行这样的功能，用户能够利用它们做其他的事情，例如：将垃圾收集延迟到请求期间，与Phusion的 Union Station产品 （一个订阅式应用监控和分析服务）集成。
在流行的Ruby应用服务器中，Puma和Passenger相似，它们都喜欢使用线程而不是Thin和Unicom这样的服务器所使用的事件架构。Phusion团队最近发布了 一篇文章比较了Passenger和Puma ，而Puma的作者Evan Phoenix则在HackerNews上对此 做出了回应 。
InfoQ和Phusion的CTO Hongli Lai进行了一次谈话以讨论Passenger最近的更新：
Passenger 为 Ruby 用户提供了不寻常的特性，例如带外执行，它和语言运行时紧密集成。那么对于 Node.js 和 Python 用户而言有相似的功能么？
大部分功能所有支持的语言都可以使用，包括Node.js和Python。从第一天开始，我们就一直在尽量减少对Ruby的依赖。虽然我们并没有积极的推广，但是事实是在第一个版本发布几个月之后我们就已经支持Python。 我们现在还计划在下一次发布时支持 Meteor 。
Node.js和Python不能使用的功能只有很少几个，或者是因为它们对这些语言没有意义，或者是因为它们需要简单的语言特定的支持代码，而这些代码还没有被编写。Node和Python的垃圾收集器通常并不会忍受像Ruby那样的长时间的GC暂停，所以我们期望Node.js和Python用户不需要带外工作。
你认为现在的 Node.js 支持有多稳定？
我们认为它非常稳定。所有的应用程序测试都通过了，所有测试人员的应用程序都工作良好且没有已知的问题。
Passenger 最初的目标是让 Ruby 部署和 PHP 部署一样简单，仅需要用户将他们的应用丢放到正确的目录即可。你认为 Passenger 现在已经完成这一目标了么？
部署一个应用涉及到很多事情，从操作系统和语言运行时的配置到类库依赖的管理和应用程序进程的监控。PHP的部署之所以容易的原因之一是，Web服务器能够通过mod_php模块自动地处理运行的PHP应用程序。
在最初开发Passenger的时候，我们的主要计划是运行、监控和管理Ruby应用程序。你必须运行多个应用程序服务器进程，让它们监听一个本地socket，设置Web服务器反向代理这簇sockets，并且设置进程监控工具重启崩溃的进程。而在Passenger中，我们开发了一个类似于mod_php的机制解决了这些问题。因此在版本1.0中我们已经实现了自己的目标：通过将一个Ruby应用程序丢放到正确的目录运行它。
PHP生态系统依然被认为更容易部署的原因是，许多流行的PHP应用程序能自动地处理除了应用程序运行之外的其他事情。例如， Wordpress 没有依赖，不需要用户编辑配置文件或者通过漂亮的图形用户界面征求数据库凭证。但是如果你编写自己的PHP应用，那么你将会遇到和Ruby、Node或者Python应用开发人员相同的问题。
有没有托管公司真正地提供开箱即用的 Passenger 支持？
提供开箱即用的Passenger支持的知名托管公司有 Amazon Elastic Beanstalk 和Red Hat OpenShift 。许多其他的提供商（例如 Heroku ）对应用程序服务器的选择往往不可知，但是它们依然允许用户很容易地使用Passenger。还有很多较小的托管公司默认使用Passenger，例如 BrightBox 和 SpeedyRails 。
在 Ruby 应用程序服务器领域有一些强有力的竞争者（ Thin 、 Unicorn 和 Puma ）。那么你认为目前 Passenger 在这个生态系统中处于什么位置？
其他的Ruby应用程序服务器比Passenger有更多的范围限制。它们需要用户启动一个或者多个进程，将它们设置为监听sockets，配置反向代理规则等。对于想要严格控制整个系统的专家而言这并不一定是错误的方法，但是却不同于我们的哲学。我们希望软件易于安装、使用和管理，同时依然可以保持稳定性和灵活性。
但是话说回来，我们都互相学习了很多内容。例如，Passenger的“智能产卵（smart spawning）”功能在日期上要早于Unicorn，但是Passenger的带外工作功能借鉴了Unicorn的，尽管我们对该功能做了改进。每一种服务器都有它自己的优势和劣势。
转载
