关于适用base64对图片进行编码在服务器上性能的相关讨论

周五在写open api的时候 和?大神探讨一个问题,由于我们要求请求我们的人通通采用api_secret签名和参数签名,但是如果出入图片的话我们可能没有办法使用现成的装饰器进行参数签名。所以就在思考到底使用哪种方案在既能保证接口请求的可控性,又能做比较好的改动来实现。(openapi这块说实话由于前面的代码质量不高,可重用性很糟糕,写起来不得不考虑非常多的问题。)

后来我们才用了一种“笨办法” 即我们不改动现有的校验装饰器,而是让请求者将想要传入的图片先经过base64处理之后,按照我们的格式使用字符串的方式传上来。那么我们就能将其当成常规字段进行处理。这个方案在和?讨论的时候,最担心的一个问题即是部署到服务器上时候的性能问题。由于图片越大,解码出来的图片字符串长度就将越长。1个1m大小的图片转码base64之后几乎长得可怕。

 

于是尝试性的 我们在测使用的nginx服务器上做了一个简单的实验,对处理转码的时间打点进行计算看具体需要多少时间。按照我们当时测试的结果来看。解码一张500kb经过base64转码的图片回图片格式贴上两次 测试数据

"解码时间": 0.012989044189453125,
"解码时间": 0.003607034683227539,

可见 将一张500kb的图片解码的速度是非常快的 如果光从解码的角度去考虑 这个方法是完全可行的 因为只耗费了约3毫秒和12毫秒。

图片上传真正的瓶颈在于上传的网速,转码仅仅耗费如此少的时间 然而。整个api处理完毕却耗时1秒。可见 网络速度才是决定性能的一个重要指标。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值