Rails使得开发员的工作变得如此简单，以至于很容易让人误以为它能解决一切麻烦，从而没有给予其后台情景足够的注意。程序员要从一开始就把重点放在扩展性上，而不是完全依赖于Rails。
事实是，Rails（Java 与Ruby on Rails对接）只能解决80%的扩展工作。
而要完成余下的20%则需要考虑下面的五个注意事项：
1。留意你的数据库
数据库查询，尤其是大量的查询会造成性能瓶颈。例如，在博客上发表评论，如果你不小心的话，ActiveRecord可能会将每个评论都发出一次查询。点击率很高的博客可能会有数以百计的评论，这意味着每个页面会要执行上百次SQL查询，显然这会降低工作效率。
这类问题被称为“n+1查询问题”，是我们要避免的。请务必使用合适的“#include”陈述以便获取查询中的相关对象。此外，要立刻招引上千个对象。这样可以实现平衡。
Rails消除了数据库中繁重的工作但却不是完全消除。Rails将程序员与SQL隔离开，但是随着网站的发展以及应用程序要扩大的需求，你肯定希望能够手动优化数据库。
要做到这一点，需要明白在里面到底发生了什么。记住在开发模式中记录登录情况，确保SQL查询记录在了登录情况中。这样，当数据库运行过多查询或者要介入以提高效率的时候，你就会及时获知。
2。解除长期执行的查询
毫无疑问，我们都希望自己开发出的程序能快速运行。
也就是说，使用这些程序的人不会关心程序的背景。如果用户发出调整个人资料的图片，视频编码等请求，他们不需要在网络请求发出后等待很久。相反，这些做完以后，发出一个请求，要在后台等待很久才能返回状态更新以及获得页面的更新。
Rails每次都会发出一个请求，如果长时间运行查询则会阻止其他请求的执行。
尽可能减少网络请求的工作，并设置一个排队机制，这样数据库就不会超载。这样可以让应用程序运行得更快且保持前端网络服务器的开放状态。
类似的观点：许多Rails程序都可以处理文件加载和用户生成的有价值数据。许多这类应用程序都将这类数据保存在Amazon S3上。
在尝试将视频上传到应用程序上的同时处理图像或上传视频到Amazon S3可以完全占用前端服务器。这意味着用户的使用速度会减慢。而是个网络服务器可以处理许多流量，但是二十个用户同时上传多个请求意味着其他人的请求会超时或被拒绝。
底线：为提高效率起见，千万不要在处理请求的时候进行图像处理或将文件上传到另一个服务器上的操作。
相反，应该接受上传，将上传成功的信息返回给客户端，然后为其他服务器处理好后台繁重的工作。
3。使用缓冲技巧来保存应用服务器和数据库的加载数据
任何时候你都可以缓冲对于计算或数据库的查询，即便是只有很短的时间，你也可以扩展整个系统的规模。你可以通过数据库缓冲服务器控制数据库服务器的加载数据。
数据库缓冲服务器可以让你将查询或计算的对象保存在应用服务器中分布的内存中。
总的格局是当你获取或计算对象的时候，可以将其保存数据库缓冲服务器中。那么下次你需要对象的时候，可以首先检查数据库缓冲服务器，只有当它不存在的时候，你才会退回到数据库或重新计算对象，然后将其保存在缓存中。
一个好的程序员要了解各种HTTP协议的各种缓冲功能。使用这些缓冲功能，就可以削减整个堆栈的负荷。
4。监视与测量
监视和测量：服务器，资源使用，应用的性能，页面响应时长。监测的时候，尽可能地收集信息。如果出现问题，你还拥有信息，性能趋势和文本。
监视工具旨在查出性能上的问题。
如果没有监测和记录，你就不能查看系统。如果问题出现的时候，你没有足够的数据可以依靠，效率就会减慢。
5。让方案的执行环境成为产品环境的复制品
许多程序员都在本地开发并测试了应用程序，因而过早部署了产品。随后他们便会遇到问题，因为真实的产品环境与电脑上的不一样。
执行和质量保障环境越接近部署环境越好。执行环境不需要很大，但是至少要运行相同规模的软件。理想情况下，测试应该与产品数据的副本一起运行，这些数据副本要与部署条件类似。这样做最大的好处是应用程序推送到产品前可以捕捉到错误，从而节约我们的时间和精力。
