对 [Steemit,未来发展的瓶颈在哪里?] 一文中技术部分的探讨

powerfj(54)
Published in
#cn
Words
2114
Reading
10 min
Listen
Play
9y

看完@coldhairSteemit,未来发展的瓶颈在哪里?, 觉得其中关于技术的有一些问题可能有一些误会, 所以我觉得有必要和大家说明一下, 以消除大家的担心

我在国内访问Steemit,除了速度慢的像蜗牛,还会经常发生卡顿现象,有几次编辑好的内容都丢失了。

这就说明,问题很可能出在Steemit本身上,而不是网络环境的问题。于是,我又进一步寻找问题的答案。

用户访问速度慢,极有可能是Steem区块链的先天缺陷。

从上面的这些描述来看, 可以看出@coldhair觉得是区块链的速度导致了访问Steemit.com的速度慢, 我觉得这个结论是有一些问题的. 之前做过一些网站的前端页面优化的工作, 所以对这里的理解会比较深刻, 所以我想从一些专业的角度来分析一下为什么Steemit目前访问起来会比较慢.

首先我们需要明确一个概念就是用户感觉的网站打开的速度慢是指从用户点击一个链接从第一屏的内容渲染完毕的时间间隔比较长. 一般这个时间超过1秒, 对于用户来说就是比较慢的. 如果速度在100毫秒之内, 大家会感觉是极快的. 我家中国电信的宽带, 不登录打开百度首页时间是65毫秒, 这种速度你刷新页面的时候基本上都感受不到页面刷新过.

给用户感觉到的打开速度取决于很多因素, 下面列出了一些主要的因素, 这些因素也是一般做网站前端优化的方向.

  1. 用户网络到网站服务器网络的连接状况
  2. 网站的服务器处理一个请求所花费的时间
  3. 所打开网页html内容的大小
  4. 网页内容在浏览器中渲染出来所花费的时间

我自己尝试着打开steemit.com, 发现确实是有点慢. 下面逐条解释一下Steemit网站访问慢的可能的原因:

  1. 由于Steemit的网站服务器是搭建在亚马逊的美国机房, 从中国访问的时候物理距离就要比访问国内网站远很多, 这里大概有100毫秒左右的差异. 还有一个问题就是中国到美国的网络通道是走的国际带宽线路, 这一条线路目前来说一直不稳定, 而且还存在高峰期的时间, 会导致传输时间更加不稳定

  2. 一般用户打开一个页面的时候, 服务器处理的时间根据是否有写入操作会有所不同, 而且写入还分同步和异步不同的情况.

    • 如果一个请求不包含写操作, 只包含读操作的时候, 服务器处理时间相对来说会快一些, 当然如果读取操作需要得到结果的逻辑比较复杂, 运算的数据特别大的时候, 每次运行的时间也会比较长, 但是一般可以使用缓存来加速. 举个例子, 如果我打开一个页面, 要获得一个文章单独的内容的时候, 基本上服务器的逻辑就是直接去数据库拿这个文章的内容, 速度就会非常快. 如果我要获取的是某一段时间之内, 某几个用户, 然后标题包含"XXX", 标签包含"YYY", 然后第Z页的N篇文章, 这种从一个数据集合中根据字段来筛选出来一些数据来的逻辑, 筛选条件比较多, 包含了内容的模糊搜索的情况的时候, 如果是直接从数据库查询的话, 速度相对来说会慢一些. 大部分只读页面的逻辑, 如果对于数据的实时性要求不是很高的情况下, 数据都是可以缓存的, 基本上处理时间就会很短.

    • 如果一个请求包含写操作, 比如提交一篇文章, 或者给别人点赞, 如果不是使用区块链接做服务器的时候, 我们一般会把数据存入数据库, 存入数据库的这个操作可能会因为数据库的繁忙程度以及数据大小, 数据库表的设计等等很多因素, 导致花费的时间会比较长. Steemit存储这些数据的时候, 最终数据是会被存入Steemit区块链的, 因为写入区块链成功的标志是区块链上面的多个节点确认收到了信息才算写入成功, 所以这个时间会比一般的写入常见的数据库的时间会长很多. 当然Steemit也可以做一些优化, 就是先保证写入了到服务器本地的数据库是成功了, 然后立马返回给前端用户. 最后保证写入服务器本地数据库的数据会最终同步到Steem的区块链接里面, 这种情况下可能会导致我提交一篇文章之后, Steemit上面我可以马上看到我的文章, 但是区块链里面不保证立刻可以查到我的文章内容. 而且如果最后Steemit做数据同步到区块链的时候有一些失误, 可能就会导致我的数据没有存入到区块链.

  3. Steemit打开首页之后或者一个文章页的时候, 页面在不进行gzip压缩的情况下就有300多KB, 压缩之后还有50多KB. 这个页面内容相对来说还是比较大的了. 在国际线路上进行数据传输的时候, 由于国际线路不稳定会导致丢包率可能相对来说高一些, 文件越大, 传输的时间可能会越长.

  4. Steemit网页使用的图片比较多, 图片最后走的是从S3的服务器上面拉取, 应该是没有走CDN, 而且部分剪裁的图片是进行了一次302的跳转请求, 所以图片的展示相对来说会给人感觉慢一点

以上是我人肉查看Steemit网站分析出来的结果, 总体来说Steemit在给用户打开首屏的时间优化上面应该还有一些优化的空间可以做. 其实对于网页的加载性能是有很多工具可以进行检测的, 比如谷歌出品的 https://developers.google.com/speed/pagespeed/insights/, 我们用它来分析steemit的首页的情况如下, 其中一个是83分, 一个是66分, 然后两者的服务器响应时间都有几百毫秒, 说明这里的优化空间还是比较大的

CDECA036-C53A-4322-860D-2BEDDF688688.png

7B2073E7-FFCC-4E25-A226-68ACE52828C2.png

最后的最后, @coldhair哥还在担心区块链的处理速度, 我去steemdata.com看了一下目前的发帖和评论的数据, 每天最高的量加起来只有120k, 然后除以每天的秒数得出来一天平均TPS只有1.39, 当然这里还没包括其他的诸如点赞和转发还有转账之类的交易操作, 我想这种操作加起来就算是发帖和评论之和的10倍, 目前的TPS也就只有13.9, 现在STEEM区块链底层的TPS号称是可以通过增加服务器性能轻松达到10000, 所以目前Steemit的用户活跃再增长100倍左右, 系统都还是可以承受的住的, 所有我觉得大家对于STEEM系统是否承受的住的担心目前来看是有一些多余了. 大家还是好好写文章, 多拉一些用户进来把整个社区壮大吧 :)