如何优化ruby中的站点加载时间？

Question

我是一个新手,正在创建一个写在蛋糕php框架上的轻量级照片展示网站,RoR.i计划使用来自scriptalicious库的效果,以及用于照片显示和过渡效果的jquery.

由于该网站将非常丰富,我可以采取哪些编程步骤来确保所有照片和其他页面快速加载？

Answer 1

我觉得你有点混淆了.与php/cake混合？

关于性能.它主要取决于您认为您将拥有多少用户,这些用户是谁以及他们做了什么.每小时10或每秒100？他们看了很长时间的图像,还是他们在页面之间迅速跳跃？

这里有一些不太技术的提示.没有服务器配置优化,没有memcached等等.开始考虑具有常识的表现 - 这不是圣杯!

• 你的网站/应用程序太慢了吗？最常见的情况并非如此.它永远不会伤害加速,但通常,人们过于关心性能.永远记住:它不是要快速,而是要足够快.没有人注意到一些额外的毫秒.如果您的页面需要一秒钟加载,则加速50%是显而易见的,但如果只需要100毫秒,则大多不相关.

• 要确定您的网站是否运行缓慢,请对其进行基准测试.有很多方法可以做到这一点,一个是自动化的,比如ab(apache基准测试).它模拟了许多连接到您网站的用户,并为您提供了一个很好的摘要,它需要多长时间才能做出响应.另一个是:使用它.而不是在本地网络!如果你觉得它要慢,那就做点什么吧.

• 照片展示很大程度上取决于图像.图像很大.所以请确保您的服务器有足够的带宽来快速交付它们.

• 如果您缩放图像(非常可能),请不要在每个页面请求上调整图像大小,缓存缩放图像!缓存缩略图.缓存一切.处理和交付静态文件比不断进行所有处理要便宜得多.

• 想一想图像的质量.快速交付比高图像质量更重要吗？使用图像大小 - 更好的压缩意味着更低的文件大小,更低的质量和更快的交付.

• 考虑可用性.如果没有缩略图页面,人们必须按顺序浏览您的图书馆,查看他们不想看的很多照片.如果他们已经看到了图像,他们可以直接跳到那些重要的东西(降低带宽使用率和每秒请求数).想想flickr:所显示图像的大小......它们就像邮票 - 500像素宽,人们仍然很开心.如果他们需要更大的版本,他们无论如何都会点击"所有尺寸"链接.

• 技巧,技巧,技巧:较早,当用户使用模式浏览时,有时会传输低分辨率/高压缩图像,因此用户在很短的时间后就会有所收获.只有在第一张图片加载后,才会出现更大的版本.它不再常见,因为今天大多数用户都有宽带,因此发送额外的图像只是额外的工作量.

• 想想观众.他们会用14.4k调制解调器或宽带访问您的网站吗？他们习惯于减慢加载网站(摄影师可能是)吗？检查您的统计数据以了解它们.

• 你的后端脚本语言很可能不是你的问题.php并不是很快,ruby并不是很快 - 比如c或java或ocaml.框架比手工制作的优化代码慢.调试代码以查看缓慢部分的位置.我猜？图像大小调整和数据库访问.切换到另一种语言或优化代码时不会改变.

关于网站的速度

涉及很多因素.他们之中有一些是:

1. 服务器端处理:您的应用程序是否快速,您的硬件是否快速？

2. 交付:请求和文件从客户端传输到服务器的速度有多快,反之亦然？(取决于带宽)

3. 客户端渲染:他们的浏览器有多快,需要做多少工作？

4. 用户haibts:客户端甚至需要速度吗？有时,慢速页面没有问题,例如,如果他们在那里花了很长时间没有点击.想想Flash游戏网站:如果你花一个小时玩Flash游戏,你甚至可能不会注意到页面是否在3或5秒内加载.

感知的速度 - 四者的混合 - 是重要的指标.

如果您确认自己太慢了,请务必优化正确的部分.如果服务器足够快,优化服务器端脚本是没用的,但页面需要很长时间才能在浏览器上呈现.如果带宽堵塞,则无需优化渲染时间.

关于优化

在构建应用程序时,性能是不可或缺的部分.如果你真的需要快速的东西,你必须从一开始就计划速度.如果它不是为速度而设计的,那么通常不可能进行有效的优化.

对于网络应用程序而言,这并不是真的,因为它们可以轻松地水平扩展,这意味着:将硬件投入其中.
所有的东西都要花钱,如果钱对你(或你的老板)很重要,不要忘记它.两周优化应用程序需要多少钱？比如说,优化你(或你的老板)X(我是欧洲人)薪水的成本.现在,考虑购买另一台服务器:花费Y€(包括设置).如果Y <X,只需购买服务器就可以了.

随机流行语

最后但并非最不重要的是,我会向你抛出一些随机(无序)的流行语,也许有些东西可能有所帮助.只是谷歌,这应该有帮助......

内容传送网络,(英特尔)SSD,精灵(组合图像以保存请求),页面压缩(gzip,deflate),memcached,APC(PHP的字节码缓存),缩小和合并多个CSS和JS文件,有意识地处理HTTP状态代码(未更改),静态和动态内容的分离(不同的服务器和域),通过AJAX逐步加载(重要内容优先),...

现在我没有想法.

编辑/更新

我忘了的事情/技巧:

• 实现进度条或类似的东西,所以用户至少感觉到正在发生的事情.如果只使用javascript,你不能使用进度条,但至少显示某种动画沙漏或时钟.如果你使用闪光灯,你可以显示一个真正的进度条.

• 您可以通过使用AJAX或Flash跳过完整的页面重新加载 - 只需加载您需要的数据.你经常在flash图片库中看到这个.只需加载图像和描述.

• 预加载:如果用户长时间查看一个图像,您可以开始加载下一个图像,因此如果用户继续,则会进行浏览器缓存.

放弃

我从未实现过性能关键应用程序(有2个例外),所以我上面写的大部分内容都是猜测和其他人的经验.今天你会读到有关成功创业公司的故事,以及他们如何应对(性能方面的)每天从100人到大量用户,以及他们如何使用漂亮的技巧来解决所有这些问题.
但这会发生在你身上吗？可能不是.每个人都在谈论它,几乎没有人真正需要它(但我承认,它仍然很好知道).

我的真实世界体验(是的,我喜欢写长答案):

曾经我做过一个网站的一部分,每天有数千名独立访问者,由cms(typo3)驱动并在一个专用的samp服务器上运行(想想使用过的,十年前的solaris服务器,而不是ghz!).你可以搜索公寓,并通过重新加载iframe ON-CLICK告诉你你将拥有多少结果(例如20-40m²:400次点击,30-60m²:600次点击).它非常非常慢(但用户仍然使用它).不断100%负荷.解决这个问题是我的职责.
我做了什么？首先,找出它为何如此缓慢.我的第一个猜测是正确的,点击请求也使用了typo3(当然没有缓存).通过使用直接查询数据库的自定义脚本替换此单个操作,绕过typo3,问题得以解决.负载几乎没有下降.花了我大约2个小时.

另一个项目每天有大约1500个唯一访问者,显示由oracle数据库服务的数据,其中有数百万行和复杂的连接,需要花费很长时间(=几秒钟)才能运行.我没有太多优化oracle的经验,但我知道:数据库每周只更新一次或两次.我的解决方案:我只是通过将html写入文件系统来缓存内容.更新后(在半夜)我清除缓存并开始重建它.所以,而不是昂贵的查询,我只有廉价的文件系统读取.问题解决了.

这两个例子都告诉我,网络开发的表现不是火箭科学.大部分时间解决方案都很简单.并且:其他部分在99%的时间里更为重要:开发人员的成本和安全性.