本来我是很喜欢这个项目的, 甚至花费大功夫进行了重构和优化, 可以看帖子:
但是最后我为什么放弃了呢?
原因
我有部署一个webp-server-go , 来对图片进行优化, 如果优化后更小, 那么存储优化后的图片. 如果优化后更大, 那么存储原图片. 然后存到服务器目录, 对外访问.
我现在有疑问:
- 大部分图片在转换优化后, 实际变小的图片并不是很多
- 在经过上面流程后, 图片不仅在S3存储桶里存了一份, 本地服务器也存了一份, 这样反而额外占用了本地服务器的硬盘, 如果图片多了还是个额外成本
- 在并发比较大的情况下, webp-server-go的处理速度就不够了, 会比较占用服务器CPU和内存
所以我想让你帮忙参考下, 是否有必要使用这个webp-server-go, 直接使用原图怎么样?
AI o1-preview 回答
基于您提出的疑虑,似乎您在使用 webp-server-go 进行当前的图片优化设置时遇到了一些挑战。让我们针对您的每个问题进行分析,探讨继续使用这种方法是否有益,或者直接使用原始图片是否会更好。
1. 优化后实际变小的图片并不多
问题: 大部分图片在优化后,文件大小并未显著减小。
分析:
- 图片格式: 如果您的原始图片已经是经过压缩的JPEG或PNG格式,转换为WebP可能不会带来明显的大小减小。
- 图片内容: 简单的图形(如图标或徽标)可能无法进一步压缩,而复杂的图片(如照片)通常在优化后收益更大。
- 质量设置:
webp-server-go
中的压缩级别和质量设置可能不够激进,无法在不明显降低质量的情况下产生更小的文件。建议:
- 评估压缩设置: 在放弃优化之前,考虑调整压缩参数,以在图像质量和文件大小之间找到平衡。
- 选择性优化: 实现逻辑,仅对超过某个大小阈值的图片进行优化,以确保优化带来有意义的影响。
2. 本地存储占用增加
问题: 在本地服务器上存储优化后的图片会消耗额外的磁盘空间,随着图片数量的增加,这将导致额外的成本。
分析:
- 冗余存储: 在S3存储桶中保存原始图片,同时在本地保存优化后的副本,会导致不必要的存储占用。
- 可扩展性: 随着图片库的增长,本地存储可能成为瓶颈,导致成本增加或需要额外的基础设施。
建议:
- 从S3或CDN提供图片: 而不是在本地存储优化后的图片,您可以直接从S3或通过内容分发网络(CDN)提供图片,这样可以全局缓存图片。
- 上传时进行优化: 在图片上传时进行优化,然后仅将优化后的图片存储到S3。这消除了本地存储的需要,并减少了冗余。
- 使用云端优化服务: 采用如 Cloudinary、Imgix 或 AWS Lambda@Edge 等服务,可进行实时优化,无需占用本地资源。
3. 高并发情况下的性能问题
问题: 在高负载下,
webp-server-go
会消耗大量的CPU和内存资源,导致性能瓶颈。分析:
- 资源密集型处理: 实时图像优化对CPU要求很高,特别是处理高分辨率图片或大量请求时。
- 可扩展性限制: 如果优化带来的收益有限,为处理峰值负载而扩展服务器可能并不具成本效益。
建议:
- 异步处理: 不要实时优化图片,而是在非高峰期异步批量处理。
- 利用无服务器架构: 使用无服务器计算(例如AWS Lambda)进行图像处理,可根据需求自动扩展,减少对服务器的负担。
- 探索高效的库: 考虑使用更高效的图像处理库(如Node.js中的libvips和sharp),这些库速度更快,内存占用更少。
结论和替代方案
鉴于优化后的收益有限、额外的存储成本和性能问题,可能没有必要以当前的方式继续使用
webp-server-go
。替代解决方案:
- 停止实时优化: 不再使用
webp-server-go
进行按需优化。- 上传时优化:
- 当用户上传图片时,自动对其进行优化。
- 仅存储优化后的图片至S3。
- 这样确保所有图片都已优化,且避免存储冗余文件。
- 通过CDN提供图片:
- 使用CDN来分发图片,可提供缓存,减轻服务器负担,并通常包含优化功能。
- 像Cloudflare这样的CDN提供实时的图片优化和缓存服务。
- 监控和调整:
- 持续监控图片大小和加载性能。
- 如果发现图片对网站性能产生影响,重新评估优化策略。
直接使用原始图片(上传时已优化)的好处
- 降低服务器负载: 消除了实时优化对CPU和内存的占用。
- 简化架构: 简化了系统,无需维护
webp-server-go
,降低了复杂性。- 成本节约: 通过避免存储重复的图片,降低了存储成本,并可能减少服务器基础设施的费用。
- 性能提升: 用户能够更快地加载图片,改善用户体验。
最终建议
切换到直接使用原始图片(在上传时已优化)似乎更符合您的需求:
- 效率: 节省资源,降低成本。
- 简洁性: 简化了图片处理流程。
- 可扩展性: 随着用户数量和图片库的增长,更容易扩展。
如果未来发现图片大小影响了网站性能,您可以考虑:
- 重新评估优化工具: 可能会有新的工具或服务,提供更好的性能和压缩率。
- 采用先进技术: 实施响应式图片、懒加载,或采用更广泛支持的现代图片格式。
如果您需要进一步的帮助或对实施新方法有其他疑问,欢迎随时联系,我很乐意协助您。
主要原因
-
优化时的CPU和内存占用, 我使用的是绿云的这个服务器:
我知道绿云很差, CPU占用和内存占用长时间高了会重启, 但我是短时间占用, 所以跟服务器关系其实不大.
在同时并发处理20+图片时, CPU和内存卡死, 容器反复重启, 这个太尴尬了, 但是这个也能克服, 说服自己实际应用中这种请求并不常见 -
占用硬盘空间: 在我使用了2-3天并且重启过容器后,也就是只保留了优化和对比后的图片, 硬盘占用1.3个G, 的确不是很大. 但是长期以往, 不仅在存储桶占用了一份空间, 硬盘也占用一份空间, 硬盘空间不够只能更换服务器硬盘, 这个又是一个成本. 相对于图片压缩节省的CDN成本, 这个实在是没有必要.
综上所述, 我放弃了webp-server-go, 然后自己写了一个proxy-go来无缝切换服务, 实在是因为nginx我同时配置多个路径的多个反代, 有的路径成功有的路径失败, 不理解. 只能弄个中间件来适应下, 项目在这里: