下载与上传速度计算的总结

下载与上传速度计算的总结

     -- 从良好的用户体验出发，速度计算乃一门艺术活儿。

---

# 背景说明

首先，背景说明一下，这里要探讨的速度涉及到两部分，一个下载速度，一个上传速度。

前段时间从事的一个项目开发，正好涉及到计算速度，要求在界面提供有速度的显示。刚开始认为要显示速度应该很简单的逻辑，计算公式如下：
download_speed = download_bytes / tick_time_count;
upload_speed = upload_bytes / tick_time_count;

照此，若要计算每秒的即时速度，只需获取每秒的流量差值结果即可，足够简单吧☺。

# 情况描述

但是，我们上面涉及的问题很单纯，忽略了产品设计细节上的很多东西，复杂的元素。
有必要先说明清楚我们产品的在统计速度方面，大致流程是怎么设计的，如下：

--
为了方便描述逻辑，在此先定义我们产品的两进程p1和p2，说明，p1负责具体的下载逻辑，p2负责下载展示与用户交互。

-- 1，p1进程实时更新流量统计值download_bytes，upload_bytes 。

     在系统应用层，毕竟下载与上传逻辑都是在p1进程直接处理，足以做到实时更新，提供准确信息。
  
2，p2与p1的通信均为异步-轮循机制。所以p2投递异步请求获取流量统计值，然后轮循尝试获取结果。
     两进程通信是单方面，只有p2向p1投递请求，而p2获取请求结果需要以定时轮循方式得以获取。
  
3，p2获到统计值download_bytes，upload_bytes ，与上次获取的流量统计值download_bytes’，upload_bytes ‘相比得到差值

 diff_download_bytes，diff_upload_bytes 。

4，p2同时取得p1返回流量时的时间戳tick_time_count，与上次的时间戳tick_time_count‘，相比得到差值diff_tick_time_count。

5， 差值与时间代入以上速度计算公式，最后得到速度值。

     download_speed = diff_download_bytes / diff_tick_time_count;

     upload_speed = diff_upload_bytes / diff_tick_time_count;

6，界面显示的速度值为6秒的平均速度，作为平滑效果的处理。
# 问题剖析

那么，产品上面具体的复杂细节在哪里？个人的总结可能不太全面，描述如下：

1，统计流量的地方与显示速度地方不在同一进程。
     p1负责流量统计而不涉及具体的速度计算，该点主要从逻辑分层方面考虑，一个属于功能逻辑，一个属于具体的业务逻辑。
     p2可以周期从p1获取流量统计值，根据具体场合计算所需的速度。

2，两进程通信为异步交互，存在堵塞导致延迟。
     由于下载与上传涉及逻辑诸多，p1进程需要处理的请求可能很多很多，导致p2获取流量的请求等到一段时间才得以处理返回，出现延迟现象。这样，请求时刻与计算速度的时刻出现较大的时差。
     其实，第二点是由第一点而引起的。
    

# 歇后语

像以上的情况，要想进程间的尽量同步（准确）显示速度，的确是一件考验的事情啊。

如同事振振所说的，”公司单独安排一同事负责这方面工作的研究，设计好速度显示的用户体验，也不为过。”

所以，从良好的用户体验出发，速度计算乃一门艺术活儿。