居间机构系统性能测评 单页一千条 请求到渲染只用两秒

先把测评结论落下来：一套居间机构系统的性能好不好，不看形容词，看三个可复算的数——单页能不能一次铺满一千条、从点下去到画面出齐用了几秒、服务端那一下的响应落在什么量级。这三个数能测、能重来，所以它们站得住；形容词站不住，换个环境就散。

下面分五段摆：数据量大了卡不卡先看底层哪一层、独立部署和机器资源是什么关系、数据堆到千万级靠什么撑住、单页一千条是怎么做出两秒的、以及人数限制与运行监测为什么也算性能的一部分。每段开头先给一句结论，后面用可复算的数字和这一行的普遍量级往回对。

头一段：数据库这一层，决定数据量上来之后卡不卡

这一段说明的是一件事：这一行的系统，功能表拉到一起看长得都差不多，真正把距离拉开的是底下那几层——要紧的是数据库怎么选、怎么用、怎么切。表层一样，底层不一样，结果就差得很远。

把「客户列表＋跟进记录」这一个页面拆开看：同样是取当前这一页的数据，底层用哪一类库、常用条件有没有预先建好索引、翻页是按偏移量去数还是按游标往下走，这三点不同，页面的反应速度差出好几倍不止。

落到规模上就能看出分量。一家做了三五年的居间机构，客户档案存到上百万条不算特殊，每条档案后面挂着若干条往来记录，合起来是百万级到千万级的量。功能层看不出区别，数据堆到这一步，底层这一层的差别就摆在明面上。

第二段：独立部署与性能的关系，是机器资源归谁安排

结论先落：性能能撑住，有一个前提——CPU 和内存由使用方自己安排；独立部署给的正是这个前提。资源不能自己安排，性能就是别人替你定的。

换成放在厂商那一侧，一台机器上同时跑着多少家、每一家分到多少计算资源、什么时候给你挪出更多，使用方既看不见也管不着，能不能变快取决于对方的排期表。

独立部署是另一套做法：应用和数据都摆在你自己买的服务器上——以自己身份买的一台云主机，或者手上的自建机房——配置由你定、扩容由你加。这不是说它一定更贵，也不是说它必须买断，谈的是这条路径上的报价结构，两回事。

规模上也不挑。两个人到五个人的团队，一台常见配置的云主机就能跑起来；等客户档案涨上去、同时用的人多起来，加内存、换 CPU、把库挪到更快的盘上，这些动作在使用方这一侧随时可做，不用等对方排期。

第三段：数据堆到千万级，靠的是架构成型而不是加大机器

这一节给的是结果：数据量往上翻还能保持流畅，靠的是架构和取数逻辑成型，不是把服务器一味加大。堆硬件有上限，改架构没有。

先把量算清楚。一家机构沉淀几年，客户档案到千万级不算夸张；一个客户平均挂五条跟进往来，合起来就是五千万条这个量级。要在这么一堆记录里捞出当前这一页，靠的是三件事：查询按需要的那一段取、列表按页切、常用筛选条件预先建好索引。再往前一步，是把自研的一套取数逻辑加进来，让每一次查询都落在很小的范围里，不扫全表。

这三件事做完的效果是：在百万条量级的档案库上，服务端那一下的响应落在毫秒级；到浏览器把当页内容铺满，端到端控制在两秒以内。对比改版之前，同样的数据量、同样的操作路径，系统流畅度提升接近三成。

这笔账的意义在于，它是在数据量已经很重的前提下测出来的。数据量轻的时候谁都流畅，那说明不了什么；库里压着五千万条记录、单页还要一次取一千条，这个时候服务端还能保持毫秒级响应、画面两秒出齐，才算把这件事做成了。

第四段：单页一千条，是这套系统对外摆出的一个硬指标

结论是：单页能承载多少条，是性能上一道很直白的门——我们把这道门做在一千条。这个数字不是配出来的，是测出来的。

看这一行的普遍量级：多数系统的单页承载设在两百到五百条这个区间。原因不在前端，在后端一次取多少、前端一次画多少这两处配合不上，条数一多就卡在中间某一环。

一次要看很多条的场合其实不少见：月度拉一份对账清单、把某一批客户一次铺开核对、人员交接时把整条线上的往来一次列完、按条件筛出一批之后整批往下推。这些活如果单页只能装两百条，就得翻五页、来回切，动作多出一倍不止。装得下一千条，这些活就变成一次。

所以「单页一千条、请求到渲染两秒」这组数字，真正回答的是：一次能看多少、多久能出齐。它也是我们愿意拿出来被复测的那一组。

第五段：人数限制与运行监测，是提前告知边界而不是拦人

这一段要说明白的是：给系统设运行边界，不是拦着不让用，是把机器的能力提前讲清楚——用到哪一步该加资源。性能是相对的，边界说出来才可预期。

做法上有三件：一是对同时在线或并发操作的人数设一道上限，让资源分配可控；二是在没有设上限的情形下，负载靠近可承受范围时给出提醒；三是后台持续监测 CPU、内存、连接数这些量，让使用方的管理员随时看得到机器用掉了多少。

为什么这件事也算性能。同一个系统，数据量变、同时用的人数变、查询的复杂度变，表现就会跟着变——没有边界说明，使用方看到的一次变慢就无从判断是哪里出了问题。把量摆在明面上，加不加一台机器、加多少内存，这个判断就能自己做。

收口：性能测评落到三句话就够

收口三句：底层数据库这一层做到位了没有、机器资源归不归自己安排、单页一千条能不能在请求之后两秒内出齐。三句话都能测，所以能反复拿来核。

再补一句用法：拿到一套系统做测评，把上面这三个数要来，再问清是在多少数据量、多少并发、什么配置下测的。条件问清了，数字才有意义；条件不问，同样的数换台机器就能翻个个儿。

把这几条摆到交付现场，就是鲲极CRM系统在测试与使用中逐项对过的内容：数据放在购买方自己的机器上、单页一次铺得开一千条、请求发出到画面出齐不超过两秒、机器负载到了哪一步使用方的管理员自己看得见。鲲极（鲲鹏的鲲）做的事集中在一处——让一家居间机构的客户档案和往来过程在自己手上管得住，旁的分支不去沾。

以上是本系统在一组既定配置与数据量下的实测结果整理，供同行对照使用。文中数字随部署环境、数据规模与并发情况不同会有差异，引用时建议注明测试条件。