如何使用爬虫来对比某东上的数据

2)吞吐量

吞吐量(Transaction Per Second)是指系统在单位时间内处理事务的数量，一个事务可能包含多次请求，它反映出系统承受的压力。

需要注意的是，TPS 和 QPS 是不一样的，后者指的是单位时间内请求的数量，当用户的操作只包含一个请求接口时，TPS 和 QPS 没有区别。

吞吐量可以细分为网络吞吐量和磁盘吞吐量。前者是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。即在没有帧丢失的情况下，设备能够接受的最大速率。后者是指单位时间内系统能处理的 I/O 请求数量，I/O 请求通常为读或写数据操作请求，关注的是随机读写性能。

最后来简单总结一下。性能调优非常重要，不仅用户体验好，系统稳定，更能体现出真正优秀的编码水平。我相信所有的小伙伴都能写出跑的通的代码，但至于痛不痛快，就需要在性能方面有所研究了。

换句话说，如果你跳槽到一家公司，恰好解决了原有系统的性能瓶颈，那不得了啊，兄弟，你立马就得到公司重用了!
 

那我再来问问小伙伴，哪些因素会成为系统的性能瓶颈呢?闭上眼睛，转个圈，想一想。

• 数据库：几乎所有的系统都会用到数据库，大量的数据库读写操作会严重影响到系统的性能，所以数据库缓存技术 Redis 变得越来越重要。另外，系统运行时间久了之后，数据量就会变得非常大，不仅需要在 SQL 上做很多优化，还要在分库分表上下足功夫。
• 网络：如果你家的网速很慢，那就要去问问运营商，你家的带宽多少。或者，至少检查一下，你家的网线是百兆的还是千兆的，虽然网线都很短，短到只有猫到路由器那么一小节。网络带宽如果太小的话，就意味着数据传输得很慢，就像跑车到市区，搞不好还没有自行车快。
• 磁盘：我家里的台式机都换成了固态硬盘，换了之后的速度就比之前普通硬盘的快很多。多说一点，数据库的读写操作就是磁盘 I/O，而 Redis 之所以快，就是因为 Redis 操作的是内存，但 Redis 牛逼的一点在于它不仅可以做缓存，还可以将数据持久化到磁盘。
• 内存：内存的读写速度比磁盘快得多，但空间远没有磁盘那么大，一般家用的计算机内存在 16G 已经是很高的配置了。众所周知，Java 程序是通过 JVM 分配内存的，创建的对象都放在堆内存上，操作起来就很快，但如果代码写得有问题的话，就很容易造成内存溢出。
• CPU：CPU 的计算速度快到超出人的想象，所以阿尔法狗可以轻松地打败柯洁。如果，我真的是说如果啊，放在 CPU 还是奔腾的年代，柯洁还是可以轻松打败阿尔法狗的。如果程序涉及到大量的上下文切换，或者造成 JVM 频繁的 GC，就很容易长时间占用 CPU，导致出现性能问题。

在实际的工作当中，小伙伴们也可以按照上面的顺序进行性能调优。一开始，不要盲目对内存和 CPU 下手，这个难度有点大，并且效果不明显;搞不好，还会影响到整个系统的使用。先从数据库、网络和磁盘着手优化，很容易看到效果，并且不容易出错。

最后一个问题，小伙伴们知道系统的性能指标吗?

1)响应时间

很多年以前，我干过一件很蠢的事。公司有一台闲置的云服务器，是 Windows Server 版的，刚好有一客户想体验我司的系统，我就没想那么多，把系统部署到了这台云服务器上。

结果呢?

首页打开的速度超级慢，慢到需要将近一分钟的时间。不仅客户的下巴惊掉了，我自己的也掉了。

为了挽回颜面，我对首页相关的后端和前端做了很多优化，后端刻意使用了缓存技术，减少了 SQL 语句的查询;前端压缩了 JavaScript 和 CSS，减少了请求数，甚至更换了 CDN，使用了图片懒加载，但收效甚微。

最后静下心来想了想，同样的代码，部署到 Linux 环境下的那个系统就很快，就算是第一次打开首页需要加载资源，响应时间仍然短到无法感知。于是就把 Windows Server 重装成了 CentOS，效果立竿见影，响应时间短到离谱。

那，一个系统的性能好不好，响应时间(指系统对请求作出响应的时间，比如用户打开首页)就是最明显的一个直观上的指标。对于游戏来说，响应时间小于 100 毫秒还算不错，响应时间在 1 秒左右勉强接受，如果响应时间达到 3 秒就没法玩了。

（编辑：阜新站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!