性能测试知多少---系统架构分析

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
云解析 DNS,旗舰版 1个月
简介:

  有些事儿一旦放一放就难再拾起来,突然发现《性能测试知多少》这个系列两月没更新,关键时我都不知道啥时候放下的,总容易被各种技术所吸引走,如饥似渴的想学更多的东西,这几天一直有朋友问我为啥不写了,我才意识,事情要一样一样做,我现在要把这个系列完成。


 

  之前有对性能需求进行过分析,那篇主要从项目业务、背景等角度如何抽丝剥茧的将项目的需求抽离出来。在我们进行需求的时候也需要对被测项目的架构有一定的认识,如果不了解被测系统的架构,那么在后期的性能分析与调优阶段将无从下手。

 

简单系统架构介绍                                                                              

 

  因为每个公司的业务不同,采用的技术,架构也都有很大不同。但不管怎么变动,但基本都在三层架构的基础上扩展与改进。

下面看一个基本的系统架构:

表示层

  表示层运行在客户终端上,运行java  applet 程序,提供协议控制和用户界面,与系统用户实现直接交互,通过TCP/HTTP协议与业务层系统通信,向应用层系统发送请求报文,并接收应用层系统返回的回应报文。

业务逻辑层

  业务逻辑层作为中间层实现核心业务逻辑服务。

  应用服务器主要运行中间件系统,中间件系统系统作为一个容器来运行各种应用软件系统。前台发来的请求报文通过中间件传递 给应用程序,应用程序在处理的过程中调用数据层的数据服务器,数据服务器将查询的数据返回给应用程序,应用软件处理完成后通过中间件系统返回给客户端。

  在大型的系统中,可以对应用系统进行拆分,比如拆分成交易服务,查询服务;或者通过负载均衡技术,来分散客户端发来的请求,使其能承受更大的用户访问量。

数据层

  数据层运行在数据库主机上,负责整个系统中数据信息的存储。运行数据库服务程序,查询通过JDBC与应用程序进行通信,主要用于存储数据与提供数据查询等服务。

  数据库集群技术就是对大型系统应用非常广泛的一种解决方案。

 

大型系统架构介绍                                                                               

 

  前面介绍了一般系统的架构,那么一个大型的系统在设计中使用了哪些手段或技术来提高系统的性能呢

操作系统

  操作系统是硬件与软件之间的桥梁,那么一个稳定的操作系统是系统坚实的基础。在个人操作系统领域,windows 无疑是绝对的霸主,但随着近几年的发展,linux/unix以其不俗的性能表现,超强的稳定性与安全性使其在服务器领域变成重多企业的首选。因为系统服务器由少数技术人员使用,他们更看重系统的性能、稳定性和安全性等方面的表现。

Web服务器

  Web服务器即中间件服务器,是应用程序的载体(容器),应用程序只有在中间件服务器上才能正常的运行被外界所访问使用。对于window系统来说,IIS是微软配套的web服务器,他们的搭配应该是夫妻是之间的默契;apache 作为开源力量代表,不管在windows还是linux下面都非常得宠。因为linuxapache 都为开源产品且性能优异,应用非常广泛。

  · 淘宝网(阿里巴巴): Linux操作系统 + Web 服务器: Apache

  · 新浪:FreeBSD + Web 服务器:Apache

  · YahooFreeBSD + Web 服务器:自己的

  · Google: 部分Linux + Web 服务器:自己的

  · 百度:Linux + Web 服务器: Apache

  · 网易:Linux + Web 服务器: Apache

  · eBay: Windows Server 2003/8 (大量) + Web 服务器:Microsoft IIS

  · MySpace: Windows Server 2003/8 + Web 服务器:Microsoft IIS

 

常用的系统架构是:

· Linux + Apache + PHP + MySQL

· Linux + Apache + Java (WebSphere) + Oracle

· Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库

· Window Server 2003/2008 + tomcat + MySql

 

 

提高系统性能的相关技术                                                              

 

网页HTML 静态化

  其实大家都知道网页静态化,效率最高,消耗最小的就是纯静态化的 html 页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。

  但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统 CMS,像我们 常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还 能具备频道管理,权限管理,自动抓取等功能,

  对于一个大型网站来说,拥有一套高效,可管理的CMS 是必不可少的,除了门户和信息发布类型的网站,对于交互性要求很 高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子,文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像 Mop 的大杂烩就是使用了这样的策略,网易社区等也是如此同时,html 静态化也是某些缓存策略使用的手段,

  对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用 html 静态化来实现,比如论坛中论坛的公用设 置信息,这些信息目前的主流论坛都 可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以 考虑将这部分内容进 行后台更新的时候进行静态化,这样避免了大量的数据库访问请求;

 

图片服务器分离

  对Web 服务器来说,不管是 Apache,IIS 还是其他容器,图片是最消耗资源的,于是我们 有必要将图片与页 面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器,这样的架构可以降低提供页面访问请求的服务器系统压 力,并且可以保证系统不 会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如 apache 在配 置 ContentType 的时候可以尽量少支持,尽可能少的 LoadModule,保证更高的系统消耗和执行效率;

 

数据库集群和库表散列 

  大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

  在数据库集群方面, 很多数据库都有自己的解决方案, Oracle, Sybase 等都有很好的方案,常用的 MySQL 提供的 Master/Slave 也是类似的方案,您使用了什么样的 DB,就参考相应的解决方案来实施即可。

  上面提到的数据库集群由于在架构,成本,扩张性方面都会受到所采用 DB 类型的限制,于是我们需要从应用程序的角度来 考虑改善系统架构,库表散列是常用并且最有效的解决方案,我们在应用程序中安装 业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或 者表,再按照一定的策略 对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户 ID 进行表散列,这样就能够低成本 的提升系统的性能并且有 很好的扩展性,sohu 的论坛就是采用了这样的架构,将论坛的用户,设置,帖 子等信息进行数据库分离,然后对帖子,用户按照板块和 ID 进行散列数 据库和表,最终可以在配置文件 中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能;

 

缓存

  缓存一词搞技术的都接触过,很多地方用到缓存,网站架构和网站开发中的缓存也是非常重要,这里先 讲述最基本的两种缓 存,高级和分布式的缓存在后面讲述, 架构方面的缓存,对 Apache 比较熟悉的人都能知道 Apache 提供了自己的缓存模块,也可以使用外加 的 Squid 模块进行缓存,这两种方式均可以有效的提高 Apache 的访问响应能力, 网站程序开发方面的缓存,Linux 上提供 的 Memory Cache 是常用的缓存接口,可以在 web 开发中使用, 比如用 Java 开发的时候就可以调用 MemoryCache 对 一些数据进行缓存和通讯共享, 一些大型社区使用了 这样的架构, 另外, 在使用 web 语言开发的时候, 各种语言基本都有自己的缓存模块和方 法, PHP 有 Pear 的 Cache 模块,Java 就更多了,net 不是很熟悉,相信也肯定有;

 

镜像

镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异, 比 如 ChinaNet 和 EduNet 之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新,在镜像的细节技术方面,这 里不阐述太深,有很多专业的现成的解决 架构和产品可选,也有廉价的通过软件实现的思路,比如 Linux 上的 rsync 等工具;

 

负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法,负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,下面介绍几种常见的负载均衡。

1. 基于DNS的负载均衡--一个域名绑定多个IP

  DNS负载均衡技术是最早的负载均衡解决方案,它是通过DNS服务中的随机名字解析来实现的,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。因此,对于同一个名字,不同的客户机会得到不同的地址,它们也就访问不同地址上的Web 服务器,从而达到负载均衡的目的。

  这种技术的优点是,实现简单、实施容易、成本低、适用于大多数TCP/IP应用;但是,其缺点也非常明显,首先这种方案不是真正意义上的负载均衡,DNS 服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每个Web服务器当前的负载情况;如果后台的Web服务器的配置和处理能力不同,最慢的 Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥作用;其次未考虑容错,如果后台的某台Web服务器出现故障,DNS服务器仍然会把DNS 请求分配到这台故障服务器上,导致不能响应客户端。最后一点是致命的,有可能造成相当一部分客户不能享受Web服务,并且由于DNS缓存的原因,所造成的后果要持续相当长一段时间(一般DNS的刷新周期约为24小时)。所以在国外最新的建设中心Web站点方案中,已经很少采用这种方案了

2. 通过硬件四层交换实现负载均衡

  在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了

3. 通过软件四层交换实现负载均衡

  软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他 提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满足多种应用需求, 这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性。

4. 通过反向代理服务器实现负载均衡

  反向代理服务器又称为 WEB 加速服务器,它位于 WEB 服务器的前端,充当WEB服务器的内容缓存器,反向代理 服务器是针对 WEB 服务器设置的,后台 WEB 服务器对互联网用户是透明的,用户只能看到反向代理服务器的地址,不清楚后台 WEB 服务器是如何 组织架构的。当互联网用户请求 WEB 服务时,DNS 将请求的域名解析为反向代理服务器的 IP 地址,这样 URL 请求将被发送到反向代理服务 器,由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利用反向代理服务器减轻了后台 WEB 服务器的负载,提高了访问速度,同 时避免了因用户直接与 WEB 服务器通信带来的安全隐患。

 

-------------------------------------

      这篇文章非常纠结,以目前技术水平来讲这块的东西实属班门弄斧。部分内容从互联网搜集。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
13天前
|
监控 测试技术 持续交付
软件测试中的性能瓶颈分析与优化策略
性能瓶颈,如同潜伏于软件深处的隐形障碍,悄然阻碍着系统的流畅运行。本文旨在揭示这些瓶颈的形成机理,剖析其背后的复杂成因,并汇聚一系列针对性的优化策略,为软件开发者提供一套系统性的解决方案。
|
19天前
|
安全 数据处理 数据安全/隐私保护
C/S架构与B/S架构的适用场景分析
C/S架构(客户端/服务器架构)与B/S架构(浏览器/服务器架构)在适用场景上各有特点,主要取决于应用的具体需求、用户群体、系统维护成本、跨平台需求等因素。
74 6
|
2月前
|
Kubernetes Cloud Native 测试技术
探索软件测试的奥秘:从理论到实践深入理解云原生架构:从基础到实践
【8月更文挑战第28天】在软件开发的世界中,测试不仅是质量的守护者,也是创新的催化剂。本文将带你穿越软件测试的迷宫,从基础概念到高级策略,揭示如何通过测试提升软件质量和用户体验。我们将一起解码测试的核心原则,探索自动化测试的魅力,并学习如何设计有效的测试案例。无论你是测试新手还是资深开发者,这篇文章都将为你提供宝贵的见解和实用的技巧,让你在软件测试的道路上更加从容不迫。 【8月更文挑战第28天】本文旨在为读者揭示云原生技术的核心概念、优势以及如何在实际项目中应用。通过深入浅出的方式,我们将探索云原生的多个方面,包括容器化、微服务架构、持续集成和持续部署(CI/CD)、以及如何利用Kubern
|
18天前
|
存储 监控 安全
SaaS业务架构:业务能力分析
【9月更文挑战第20天】在数字化时代,软件即服务(SaaS)模式逐渐成为企业软件解决方案的首选。SaaS 业务架构设计对于提供高效、可靠的服务至关重要。其核心业务能力包括:用户管理(注册登录、角色权限)、数据管理(存储备份、安全共享)、业务流程管理(设计定制、工作流自动化)、应用集成(第三方应用、移动应用)及客户服务(支持培训、反馈改进)。通过优化这些能力,可为企业提供更高效、可靠的 SaaS 服务。
29 11
|
16天前
|
测试技术 持续交付 UED
软件测试的艺术与科学:平衡创新与质量的探索在软件开发的波澜壮阔中,软件测试如同灯塔,指引着产品质量的方向。本文旨在深入探讨软件测试的核心价值,通过分析其在现代软件工程中的应用,揭示其背后的艺术性与科学性,并探讨如何在追求技术创新的同时确保产品的高质量标准。
软件测试不仅仅是技术活动,它融合了创造力和方法论,是软件开发过程中不可或缺的一环。本文首先概述了软件测试的重要性及其在项目生命周期中的角色,随后详细讨论了测试用例设计的创新方法、自动化测试的策略与挑战,以及如何通过持续集成/持续部署(CI/CD)流程优化产品质量。最后,文章强调了团队间沟通在确保测试有效性中的关键作用,并通过案例分析展示了这些原则在实践中的应用。
43 1
|
19天前
|
监控 算法 测试技术
软件测试中的性能瓶颈分析与优化策略
本文旨在深入探讨软件测试过程中性能瓶颈的识别与优化方法。通过对性能瓶颈的概念、分类及其成因进行分析,结合实际案例,提出一套系统的性能瓶颈诊断流程和针对性的优化策略。文章首先概述了性能瓶颈的基本特征,随后详细介绍了内存泄漏、资源竞争、算法效率低下等常见瓶颈类型,并阐述了如何通过代码审查、性能监测工具以及负载测试等手段有效定位问题。最后,结合最佳实践,讨论了代码级优化、系统配置调整、架构改进等多方面的解决措施,旨在为软件开发和测试人员提供实用的性能优化指导。
|
24天前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。
|
2月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
45 2
|
2月前
|
数据采集 存储 Java
Flume Agent 的内部原理分析:深入探讨 Flume 的架构与实现机制
【8月更文挑战第24天】Apache Flume是一款专为大规模日志数据的收集、聚合及传输而设计的分布式、可靠且高可用系统。本文深入解析Flume Agent的核心机制并提供实际配置与使用示例。Flume Agent由三大组件构成:Source(数据源)、Channel(数据缓存)与Sink(数据目的地)。工作流程包括数据采集、暂存及传输。通过示例配置文件和Java代码片段展示了如何设置这些组件以实现日志数据的有效管理。Flume的强大功能与灵活性使其成为大数据处理及实时数据分析领域的优选工具。
74 1
|
2月前
|
前端开发 测试技术 UED
【测试效率对比】深入分析:为何UI自动化测试的投资回报率通常低于接口自动化测试?
这篇文章深入分析了UI自动化测试与接口自动化测试的投资回报率(ROI)问题,指出UI自动化测试在某些情况下的ROI并不低,反驳了没有实施过UI自动化就轻易下结论的观点,并强调了实践的重要性和自动化测试在项目迭代中的作用。
60 1