如何优化 ruby 中的网站加载时间？
https://stackoverflow.com/questions/808601
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我是一个新手，正在创建一个在 cake php 框架上编写的轻量级照片展示网站，RoR.i 计划使用 scriptalicious 库中的效果，以及用于照片显示和过渡效果的 jquery。
由于该网站的照片非常丰富，我可以采取哪些编程步骤来确保所有照片和其他页面快速加载？
解决方案
我认为你把事情搞混了一点。是否与 php/cake 混合？
那么，关于性能。这主要取决于您认为您将拥有多少用户、这些用户是谁以及他们做什么。每小时 10 个还是每秒 100 个？他们会长时间观看一张图片，还是快速地从一页跳到另一页？
这里有一些不太技术性的提示。没有服务器配置优化，没有memcached等等。开始用常识思考性能——这不是圣杯！
您的网站/应用程序是否太慢？ 大多数情况下，情况并非如此。加快速度总没有坏处，但人们通常关心性能 太多了. 。总记得：重要的不是速度，而是存在 足够快. 。没有人注意到额外的几毫秒。如果您的页面需要一秒钟加载，那么 50% 的加速是很明显的，但如果只需要 100 毫秒，则几乎无关紧要。
找出您的网站是否缓慢， 基准 它。有很多方法可以做到这一点，其中一种是自动化的，例如
ab（阿帕奇基准）。它模拟大量用户连接到您的网站，并为您提供一个很好的摘要，说明响应所需的时间。另一个是：用它。而且不在本地网络中！如果你觉得它很慢，那就做点什么。照片展示在很大程度上取决于图像。图像很大。所以请确保你的服务器有足够的 带宽 快速交付它们。
如果您缩放图像（这很可能），请不要在每个页面请求时调整图像大小， 缓存 缩放后的图像！也缓存缩略图。缓存所有内容。处理和交付静态文件比不断进行所有处理要便宜得多。
考虑图像的质量。快速交付比高图像质量更重要吗？玩弄 图片大小 - 更好的压缩意味着更小的文件大小、更低的质量和更快的交付。
想一想 可用性. 。如果没有缩略图页面，人们就必须依次浏览您的图库，查看大量他们不想看到的照片。如果他们已经看到图像，他们可以直接跳到那些重要的部分（降低带宽使用率和每秒请求数）。想想 flickr：显示图像的大小...它们就像邮票——500像素宽，但人们仍然很高兴。如果他们需要更大的版本，他们无论如何都会点击“所有尺寸”链接。
技巧，技巧，技巧:早些时候，当用户使用模式冲浪时，有时会传输低分辨率/高压缩图像，因此用户在短时间内就有了一些东西。仅在加载第一个图像后，才会启动更大的版本。它不再常见了，因为现在大多数用户都有宽带，所以发送额外的图像只是额外的工作量。
想一想 观众. 。他们会使用 14.4k 调制解调器或宽带访问您的网站吗？他们是否习惯于缓慢加载网站（摄影师可能是这样）？检查您的统计数据以了解它们。
你的 后端脚本语言 很可能不是你的问题。php 并不是很快，ruby 也不是很快 - 与 c、java 或 ocaml 相比。框架比手工制作的优化代码慢。调试您的代码以查看速度慢的部分在哪里。我猜？图像调整大小和数据库访问。当切换到另一种语言或优化代码时，这一点不会改变。
关于网站的速度
这涉及很多因素。他们之中有一些是：
服务器端处理：你的应用程序快吗？你的硬件快吗？
送货：请求和文件从客户端传输到服务器（反之亦然）的速度有多快？（取决于带宽）
客户端渲染：他们的浏览器有多快，需要完成多少工作？
用户习惯：客户是否需要速度？有时，慢速页面没有问题，例如如果他们在那里呆了很长时间而不四处走动。考虑一下 Flash 游戏网站：如果您花一个小时玩 Flash 游戏，您可能甚至不会注意到页面是否在 3 或 5 秒内加载。
感知速度——所有四种速度的混合——是重要的指标。
如果您确认自己确实太慢，请务必优化正确的部分。如果服务器足够快，那么优化服务器端脚本是没有用的，但页面需要很长时间才能在浏览器上呈现。如果您的带宽被堵塞，则无需优化渲染时间。
关于优化
性能是构建应用程序时不可或缺的一部分。如果你确实需要快速的东西，你必须从一开始就计划速度。如果它不是为了速度而设计的，那么有效的优化通常是不可能的。
对于网络应用程序来说并非如此，因为它们很容易水平扩展，这意味着：向它扔硬件。
所有事情都需要花钱，如果钱对你（或你的老板）很重要，请不要忘记它。优化应用程序两周的成本是多少？比如说，优化会花费你（或你的老板）X 欧元（我是欧洲人）的薪水。现在，考虑购买另一台服务器：费用为 Y €（包括设置）。如果 Y < X，只需购买服务器就可以了。
随机流行语
最后但并非最不重要的一点是，我会向您抛出一些随机（无序）的流行语，也许有些东西可能会有所帮助。只是谷歌，这应该有帮助......
内容交付网络、（英特尔）SSD、精灵（组合图像以保存请求）、页面压缩（gzip、deflate）、memcached、APC（PHP 字节码缓存）、缩小和合并多个 CSS 和 JS 文件、有意识地处理 HTTP状态代码（未更改）、静态和动态内容分离（不同的服务器和域）、通过 AJAX 逐步加载（重要内容优先），...
现在我没主意了。
编辑/更新
我忘记的事情/技术：
实现一个进度条或类似的东西，这样用户至少能感觉到有事情发生。如果仅使用 javascript，则不能使用进度条，但至少显示某种动画沙漏或时钟。如果你使用flash，你可以显示一个真正的进度条。
您可以通过使用 AJAX 或 flash 来跳过整个页面重新加载 - 只需加载您需要的数据。您经常会在 Flash 图片库中看到这种实现。只需加载图像和描述。
预加载：如果用户长时间查看一张图像，您就可以开始加载下一张图像，因此如果用户继续，它就会被浏览器缓存。
免责声明
我从未实现过对性能至关重要的应用程序（有两个例外），因此我上面写的大部分内容都是猜测和其他人的经验。今天，您将阅读有关成功初创公司的故事，以及他们如何应对（性能方面）每天用户数从 100 到无数的情况，以及他们如何使用巧妙的技巧来解决所有这些问题。
但这会发生在你身上吗？可能不会。每个人都在谈论它，但几乎没有人真正需要它 （但我承认，知道还是很高兴）.
我的现实世界经验（是的，我喜欢写长答案）：
有一次我做了一个网站的一部分，每天有几千个独立访问者，由 cms (typo3) 提供支持，并在一个专用的 samp 服务器上运行（想想使用过的十年前的 solaris 服务器， 不是ghz！）。您可以搜索公寓，表格会告诉您将会有多少个结果（例如20-40平方米：400 次点击，30-60 平方米：600 次点击）通过重新加载 iframe 点击一下. 。它非常非常慢（但用户仍然使用它）。持续 100% 负载。解决这个问题是我的工作。
我做了什么？首先，找出为什么这么慢。我的第一个猜测是正确的，点击请求 还 使用typo3（当然没有缓存）。通过用一个直接查询数据库的自定义脚本替换这个单一操作，绕过typo3，问题就解决了。负载几乎降到零。我花了大约2个小时。
另一个项目每天有大约 1500 个独立访问者，显示由 Oracle 数据库提供的数据，其中包含数百万行和复杂的连接，需要永远（=几秒钟）运行。我在优化oracle方面没有太多经验，但我知道：该数据库每周只更新一两次。我的解决方案：我只是通过将 html 写入文件系统来缓存内容。更新后（在半夜）我清除了缓存并开始重建它。因此，我没有进行昂贵的查询，而是进行了廉价的文件系统读取。问题解决了。
这两个例子都告诉我网络开发的性能是 不是 火箭科学。大多数时候解决方案很简单。和：还有其他部分在 99% 的情况下更为重要： 开发商成本 和 安全.
其他提示
减少库的数量，您确定要使用jquery + scriptalicious。坚持简单的事情，不要寻找复杂的动画。
快速加载=＆gt;缓存，带有照片的页面是缓存的理想选择。
如果您担心的是用户速度感，您可能希望在后台预加载图像以预期用户操作，但认为这可能会增加您的服务器负载。只有在收缩带宽良好的情况下才能执行此操作。
如果你能够产生一个非常静态的拇指头版，比如每天更改两次，你可以使用精灵技术来减少加载许多拇指的延迟，请参阅：
