虽然B/S结构、J2EE架构愈来愈成为流行模式，但基于传统的C/S结构的应用程序还广泛地应用于各种行业。尤其是金融行业中的商业银行柜面－核心帐务系统等。一方面由于传统商业银行一般都有大量的字符终端等需要复用的设备，一方面也是因为他们存在大量密集的对实时性要求很高的高柜业务，使用传统的基于C/S结构或者C/S/S结构的应用效率更有保证。
C/S结构即CLIENT/SERVER结构。传统的C/S结构一般分为两层：客户端和服务器端。该结构的基本工作原理是，客户程序向数据服务器发送SQL请求，服务器返回数据和结果。客户端负责实现用户接口功能，同时封装了部分应用逻辑。服务器端的数据库服务器主要提供数据存储功能，也通过触发器和存储过程提供部分应用逻辑。
C/S/S结构即客户/应用服务器/数据库服务器三层结构，中间增加了应用服务器，通常实现应用逻辑，是连接客户与数据库服务器的桥梁。它响应用户发来的请求执行某种业务任务，并与数据库服务器打交道，技术实现上通常选用中间件产品，如BEA公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应用也属于这种三层或多层结构，这里不包括。）
三层或多层C/S结构与两层C/S结构相比，它的优势主要表现在：安全性加强、效率提高、易于维护、可伸缩性、可共享性、开放性好等。 1.2系统架构示意图
1.3CS/CSS系统架构中性能测试的特点 1.3.1CS/CSS系统架构的性能影响因素
由于CS/CSS系统的以下特性，测试工程师对一个CS/CSS系统实施性能测试具有很大的难度： *整个系统的各个部分使用多种操作系统，性能上有差别；
*整个系统架构的各个环节上使用多种数据库，同样在性能上有差别；
*应用是多个，分属多个种类，分布在不同设备上，包括自行开发的应用、第三方的应用； *系统中的设备、组件通过不同协议进行连接、通讯；
*系统的内部接口多，性能瓶颈多；而系统的整体性能往往取决于最差的部分；需要分别测试和联合测试
*系统的性能指标不光同应用系统架构有关，还和具体行业应用的业务模式有关； *采用此架构的行业应用往往是一个7×24小时系统；
*采用此架构的行业应用可能高柜业务多，这样会影响对性能度量项的选取和转换； *各个环节基本上以交换数据报文的方式通信，其格式经常会比较复杂。
因此这样的系统对于对测试工程师的知识的深度和广度都是一个考验。对于这样的系统，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。
1.3.2CS/CSS系统架构中性能测试的基本策略 1. 确定好测试工作范围
首先可以分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是用户最关心的，我们在测试之前就要通过一些设置把这些因素的影响调至最低。
另外，用户更关心整个系统中哪个环节的性能情况也会影响工作范围。如有的环节是全新系统，而有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全面一些。 2. 分析好客户的性能测试需求
客户是已经明确提出了性能指标，还是只提供了用户使用方式和历史交易流量数据，需要我们自己进行性能基准的计算？性能测试的目的是验证系统性能还是想确定目标系统的理想配置？是否还要使用测试结果预测在不同机型的处理能力？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。
3. 要作好性能测试的计划和方案
测试计划和方案中要注意测试需求分析阶段提出的问题的解决。 4. 确定的测试通过准则、性能测试的计划、结果要获得客户的认可
要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚至是性能测试过程，都要根据其重要程度，决定是否需要客户进行确认和签字。获得客户的认可是最重要的。
1.3.3CS/CSS系统中性能测量与性能探测 性能测量
1. 在性能测试开始前必须认真规划性能测量：
软件性能测量技术范围很广。可以包括日志、事件计数、事件持续时间、采样等性能测量技术。 *确定性能测量的策略：我们要测试什么？ *规划性能测试中使用什么样的测量工具。
随着项目越来越大，你是不是觉得项目的 CSS 越来越难维护，常用的属性就是那么几个，来来回回的写，搞得你也很烦，如果是那么赶紧尝试用 ACSS 方案来解决你的问题吧，如果否，那说明你经历的项目还不够多不够大，这时候你要继续努力搬砖。
如果你不了解什么是 ACSS 的话，可以参考下我之前的教程: CSS 架构之 ACSS 。如果你想了解项目组织样式的演进历史，强烈建议你研读 TailwindCSS 作者 2017 年写的把 CSS 分为五个阶段的一篇文章：
读完你会彻底理解「为什么传统的 “语义化类名” 是 CSS 难以维护的原因」，详述了 CSS 的五个阶段，写的很棒，多看几遍。
回到 ACSS，ACSS 中目前最流行的框架就是我们文章的主角 TailwindCSS 。
但是，如果在项目中使用建议你使用 Windi CSS 。
它们是一种继承关系，如何 TailwindCSS是父类，那么 Windi CSS 就是子类。
当然你也可以认为 TailwindCSS 是 ES5， Windi CSS 是 JavaScript ， Windi CSS 在 TailwindCSS 的基础上进行了扩展，还包括 ES6+ 的部分，这个我们留在 TailwindCSS 章节讲。
不过，你可以放心学习 TailwindCSS，它的语法在 Windi CSS，完全是可用的。
Windi CSS 如何安装结合其他框架使用，在 安装 章节非常清楚。
而且我们也没必要纠结 WIndiCSS 的大家过程，这些框架都会帮我们处理的，这里我们简单的搭建一个项目，方便接下里的演示：
在 package.json 文件中的 script 字段，我们新增如下字段：
接下来可以运行命令：
项目根目录将会新增三个文件：
查看 index.html 的文件内容大致如下：
HTML 层面全部都是 ACSS 的写法，同时注意文件开头应用的样式：
我们对其重新命名： windi.css => windi-acss.css 。
现在我们运行命令：
这个命令会根据 HTML 的类名生成对应的 CSS，这是项目的目录结构为：
多了个文件 windi-acss.css 其内容为：
现在可以在浏览器打开 index.html 文件了，看到效果是下面这样：
为了更好的演示和提升开发体验，我们需要对项目进行一些调整。
首先，就是增加热更新：
windicss:watch 命令添加了 -d 参数，开启开发环境下的热更新功能。
目录调整为如下结构：
index.html 的内容替换为：
npm run windicss:watch 之后，打开浏览器看到：
