交付 10 个 Base 64 图像的最佳实践

发布于 2024-12-05 13:26:12 字数 219 浏览 1 评论 0原文

我正在开发一个phonegap应用程序,该应用程序的一部分是大约10张经过base64编码的图像,每个用户每周下载一次(现在有100个用户,希望能增长很多) 我的服务器很慢,我也在处理这个问题,所以这些图像的传递很慢。 我的问题是: 在 PHP 和服务器方面,生成这些 Base64 图像并将其保存到数据库一次并根据请求从数据库获取图像或每次请求图像时对图像进行 Base64 编码会更快吗?

感谢您的帮助。

I am developing a phonegap app, one part of the app is about 10 images that are base64 encoded and downloaded about once per week per user(100 users now, hopefully growing alot)
My server is slow, which i am also working on, so delivery of these images is slow.
My question is:
Would it be faster, php and server wise, to generate and save these base64 images to a db once and fetch the images from the db on request OR base64 encode the image every time the image is requested?

Thanks for your help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

血之狂魔 2024-12-12 13:26:12

对图像进行 Base64 编码并存储编码肯定会更快。

这是一个经典的内存与速度权衡,您可以支付较低的计算成本,以获得更高的内存成本。在这种情况下,这意味着存储更多数据(如果仅保留编码版本,则存储8/7 8/6,如果保留原始版本,则存储多于2倍)也)。

您能做的最好的事情是将图像保留在内存中,因为这可以避免访问磁盘的成本。您可以使用共享内存函数来做到这一点,或者通过滥用会话变量并分配用于检索内容的固定会话 ID。

It would definitely be faster to base64 encode the images and store the encoding.

This is a classic memory vs. speed tradeoff, you can pay a lower computation cost, for a higher memory cost. In this case, that means storing more data (8/7 8/6 more if you just keep the encoded version, and a little more than 2x if you keep the original too).

The best thing you could do is keep the images in memory, since this would avoid the cost of accessing the disk. You can do this with shared memory functions, or by abusing the session variables and assigning a fixed session id to retrieve content.

橘亓 2024-12-12 13:26:12

在不知道您的应用程序的详细信息的情况下,在我看来,拥有一个仅存储 10 个图像的数据库是多余的。在慢速服务器上运行数据库所增加的开销可能会消除您从保存 Base64 编码中获得的任何好处。

我会将 Base64 编码的图像存储为文件而不是数据库,以便您的 Web 服务器可以将它们直接提供给客户端。

我还要确保如果客户端可以处理的话,您可以提供 gzip 压缩的数据,因为 base64 数据压缩得非常好。这将大大减少服务器的流量。请参阅

Without knowing the details of your app, it seems to me that having a db for just 10 images is overkill. The added overhead of running the db on your slow server will probably kill any benefits you may get from saving on base64 encoding.

I would store the base64 encoded images as files instead of a db, so that they can be served directly to the clients by your web server.

I would also make sure you can deliver data gzip compressed if the client can handle it, since base64 data compresses really well. This will reduce the traffic to your server considerably. See this.

人生戏 2024-12-12 13:26:12

在您的服务器受到处理器限制之前,您很可能会受到带宽限制。我的想法:

  • 不要发送 base64 编码的图像。相反,发送正确压缩的二进制数据。
  • 除非需要,否则不要更新客户端(即,如果没有更新的图像可供抓取,则不要抓取图像)。使用 304 标头和相关内容来跟踪。
  • 一旦情况开始严重,请使用 memcache/Redis 而不是数据库来存储“预先消化的”图像数据。

You'll most likely be bandwidth-bound before your server become processor bound. My thoughts:

  • Don't send base64-encoded images. Instead, send properly compressed binary data.
  • Don't have the client update unless it needs to (i.e. don't grab the image if there's no newer image to grab). Use 304 headers and related to keep track.
  • Once things start to hit hard, use memcache/Redis instead of a database to store the "pre-digested" image data.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文