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