Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >我所理解的性能测试是什么?

我所理解的性能测试是什么?

作者头像
小小科
发布于 2018-05-02 05:18:39
发布于 2018-05-02 05:18:39
1.3K0
举报
文章被收录于专栏:北京马哥教育北京马哥教育

扯淡首先说明这篇博客是文不对题的。起这个名字想法来源自韩寒的《我所理解的生活》,之前看过一个关于这本书的视频,感觉巨牛X,于是就想写一篇《我所理解的性能测试》。虽然是文不对题的,但我就是想用这个名字,在这个残忍的社会,给自己博客文章起个名字这点权利还是有的。下面我要贴出来的是zee大神的《性能测试面试问题列表》中列出来的性能测试与操作系统方面问题与我自己整理的回答。回答的不一定对,也懒得去改了。就用这些问题与回答来记录我这段时间的努力,来记录我所理解的性能测试吧。性能测试1.如何理解TPS性能指标的一个重要因素。TPS(Transaction Per Second,每秒事物数),单位时间内完成的事物的数量。TPS的计算一般是通过的事物除以时间。TPS是跟测试脚本中事物(Transaction)相关联的。在性能测试工具中,吞吐量也被称之为TPS(Transaction Per Second,每秒事物数)。吞吐量直接体现系统性能的承载能力,是指单位时间内处理的客户请求的数量。其计量单位可以根据需求不同而不同,比如请求数/秒,页面数/秒,业务数/小时(可以说下我们采集项目中吞吐量可以用 解析卡数/秒)。对于交互式应用,用户直接的体验就是“响应时间”,通过“并发用户数”和“响应时间”可以确定系统的性能规划;但对于非交互式应用,用“吞吐量”来描述用户对系统的性能期望可能更加合理。吞吐量作为性能测试的主要关键指标。吞吐量和并发用户数之前存在着一定的联系。在没有性能瓶颈的时候,吞吐量随着虚拟用户数的增加而增加(计算公式为 吞吐量 = (VU个数 * 每个VU发出请求数) / 单位时间)。如果性能遇到瓶颈,吞吐量与VU数理之间就不再符合这个关系。2.如何理解线程调用线程(thread)是”进程”中某个单一顺序的控制流。也被称为轻量进程。线程的好处:1) 创建一个新线程花费的时间少。2).(JAVA中线程具有新的,可运行,运行,等待/阻塞/休眠,死亡等几种状态。)在未阻塞情况下,两个线程(在同一进程中的)的切换时间少。在阻塞情况下,线程间切换将产生上下文切换。3).由于同一个进程内的线程共享内存和文件,所以线程之间互相通信不必调用内核。4) 线程能独立执行,能充分利用和发挥处理机与外围设备并行工作的能力。使用线程可以把占据长时间的程序中的任务放到后台去处理ps:JAVA中可以通过jstack或者jprofiler dump出线程所执行的堆栈信息。3.如何理解响应时间响应时间反映完成某个业务所需要的时间。在性能测试中是通过测试工具的事物函数来完成响应时间的统计。事物函数会记录开始事物和结束事物的时间差,使用Transaction Response Time这个词来说明。响应时间主要包括网络时间,服务器处理时间,网络延迟对于交互式应用,用户直接的体验就是“响应时间”,通过“并发用户数”和“响应时间”可以确定系统的性能规划;对于交互式应用,响应时间出现拐点系统就可能出现瓶颈4.如何理解响应时间,TPS曲线和用户之间的关系随着用户数量的增加,在未出现瓶颈前响应时间保持稳定,TPS值和并发用户数成线性关系,出现瓶颈后响应时间变长,TPS基本保持不变或开始下降。5.在LoadRunner中为何要设置思考时间和pacing?1)Think time,思考时间。可以通过设置思考时间,来模拟真实用户在操作过程中的等待时间。从定义上来看,think time是在iteration内部的某个action中各个步骤的间隔时间。2)Pacing,步调。可以通过设置两次迭代(iteration)之间的间隔时间,来调整各个action之间的步调(或者称之为节奏)。3)pacing和think time都是可以模拟现实世界中的停顿。对于复杂场景,这个停顿要靠pacing来完成。不过,pacing怎么设置才最合适,是需要研究用户行为才能定的。操作系统1.如何判断CPU、内存、磁盘的瓶颈?CPU瓶颈:1) 查看CPU利用率。建议CPU指标如下a) User Time:65%~70%b) System Time:30%~35%c) Idle:0%~5%如果us,sy高于这个指标可以判断CPU有瓶颈使用top查看查看运行队列每个CPU都会维持一个运行队列,理想情况下,调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载,就会出现调度器跟不上系统的要求,导致可运行的进程会填满队列。队列愈大,程序执行时间就愈长。“load”用来表示运行队列,用top 命令我们可以看到CPU一分钟,5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00,那么说明CPU已经超出负荷,交通严重的拥堵。使用top或者uptime查看查看上下文切换每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。使用vmstat查看cs结论:检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.确定CPU 利用率中user/system比例维持在70/30#p#分页标题#e#当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级当I/O 处理得到增长,CPU 范畴的应用处理将受到影响ps:对于JAVA应用,CPU瓶颈可以通过jprofiler监控分析内存瓶颈:1.查看利用率(free)used:已使用多大。free:可用有多少。Shared:多个进程共享的内存总额。Buffers/cached:磁盘缓存的大小。2.查看页交换,swap交换(po,pi,so,si),磁盘IO(vmstat)si: 每秒从交换区写到内存的大小so: 每秒写入交换区的内存大小page in :分页(Page)从磁盘重新回到内存的过程被称作Page-Inpage out : 分页(Page)写入磁盘的过程被称作Page-Out另外在进行页交换的时候,会产生磁盘IO,还需注意bi,boBo 磁盘块页面从内存到文件或交换设备的总额Bi 磁盘块页面从文件或交换设备到内存的总额3.page fault(pidstat -r,sar -B )minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生其中sar -B中fault/s表示每秒钟minflt,majflt的和。结论:监控虚拟内存性能由以下几个部分组成:1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.zee:如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加,而空闲的物理内存(free)不断地减少,证明系统中运行的进程正在不断地消耗物理内存。已经使用的虚拟内存(swpd)不断增加,而且存在着大量的页面交换(si和so),证明物理内存已经不能满足系统需求,系统必须把物理内存的页面交换到磁盘中去。由此可以得到这样的结论:该主机上的物理内存已经不能满足系统运行的需要,内存已成为该系统性能的一个瓶颈。ps:对于java程序,内存瓶颈可以通过heap dump后使用mat分析磁盘瓶颈:iostat查看IO信息。如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。另外还需要注意iowait这个值,iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.ps:磁盘瓶颈可以通过pidstat -d 定位程序2.如何理解CPU、内存、磁盘的关系?这些子系统之间关系是彼此联系,相互彼此依赖的1.对于进程来说,数据是存放在内存中的,进程的运行需要使用CPU,进程读写数据需要跟磁盘打交道。2.当内存不足时需要跟磁盘进行页(page)交换,swap交换,从而产生磁盘IO。po,so释放物理内存,pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)3.当磁盘IO负载过高时,需要监控swap和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的,当iowait 增长,表示CPU花费大量的时间在等待磁盘IO,此时CPU Bound的应用处理将受到影响(磁盘IO过高)3.如何理解paging in / paging out ?在Linux内存管理中,主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上,把活动页面保留在内存中供进程使用。交换技术是将整个进程,而不是部分页面,全部交换到磁盘上。分页(Page)写入磁盘的过程被称作Page-Out,分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时,但发现此分页不在物理内存中(因为已经被Page-Out了),此时就发生了分页错误(Page Fault)。当系统内核发现可运行内存变少时,就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生,但是如果Page-out频繁不断的发生,直到当内核管理分页的时间超过运行程式的时间时,系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态,这种状态亦被称作thrashing(颠簸)。可以通过vmstat -s 查看 paged in/out 数量4.如何监控操作系统的资源?(可用一个操作系统做例子)(把简历上部分内容直接贴出来了,懒的整理了)CPU监控:top(利用率), uptime(运行队列数), vmstat(上下文切换数), jprofile(方法占用cpu时间百分比)内存监控:top, free(利用率), vmstat(page和swap交换), pidstat -r和sar -B(page fault), jmap -heap(堆dump), mat和jprofiler(查看对象)磁盘监控:iostat(%util), top(iowait%), pidstat -d网络监控:netstat(连接数), nethogs(流量), wireshark和tcpdump(抓包)JVM监控:jstat(gc), jmap(堆dump), jstack(线程dump), jprofiler和visualvm(剖析工具)nmon(长时间全局收集数据)5.如何理解上下文切换(context switch)?(可用一个操作系统做例子)每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。#p#分页标题#e#vmstat其中cs那一列6.如何理解磁盘IO?(可用一个操作系统做例子)磁盘IO速度是非常慢的,linux内核就是要尽量降低IO内存不足时会进行页交换,产生磁盘IOCPU Bound类型应用,当磁盘IO过多,iowait过大时会影响性能。PS:一句话说出我所理解的性能测试,我现在的回答是——果与因

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2014-07-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 马哥Linux运维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
GHSL: 全球1975 年到 2030 年以 5 年间隔建成面积的分布情况(100m)
该栅格数据集描述了建成面积的分布情况,以每 100 米网格单元中的平方米为单位。 该数据集测量:a) 建筑总面积;b) 分配给主要非住宅(NRES)用途网格单元的建筑面积。 数据从 1975 年到 2030 年以 5 年为间隔进行时空内插或外推。 有关全球人类住区图层主要产品的完整信息,请参阅[全球人类住区图层数据包 2023 年报告](https://ghsl.jrc.ec.europa.eu/documents/GHSL_Data_Package_2023.pdf?t=1683540422)。 全球人类住区图层(GHSL)项目得到了欧盟委员会、联合研究中心以及区域和城市政策总司的支持。
此星光明
2025/01/27
770
GHSL: 全球1975 年到 2030 年以 5 年间隔建成面积的分布情况(100m)
GHSL:1975-2030 年全球网格人口和建成面积数据为基础(5 年为间隔)
该栅格数据集采用联合国统计委员会推荐的 "城市化程度 "第一阶段方法,以全球人类地理信息系统(GHSL)项目生成的 1975-2030 年全球网格人口和建成面积数据为基础,以 5 年为间隔,对全球多时城乡进行了分类。 城市化程度图层是通过整合从大地遥感卫星和哨兵-2 数据 GHS-BUILT-S R2023 中提取的建成面积信息,以及从 CIESIN GPW v4.11[GHS-POP R2023] 中提取的网格人口数据生成的(https://developers.google.com/earth-engine/datasets/catalog/JRC_GHSL_P2023A_GHS_POP)。 该产品是在 GHS-BUILT-S 和 GHS-POP 更新的基础上对 2023 年发布的数据进行的更新。 结算模型在详细级别(第二级 - L2)提供。 有关全球人类居住图层主要产品的完整信息,请参阅[全球人类居住图层数据包 2023 报告](https://human-settlement.emergency.copernicus.eu/documents/GHSL_Data_Package_2023.pdf?t=1727170839)。 全球人类居住图层(GHSL)项目得到了欧盟委员会、联合研究中心以及区域和城市政策总局的支持。
此星光明
2025/01/27
860
GHSL:1975-2030 年全球网格人口和建成面积数据为基础(5 年为间隔)
GHSL: 1975-2030全球建筑体积的分布情况,以每 100 米网格单元立方米为单位
GHSL: Global building volume 1975-2030 (P2023A)
此星光明
2025/01/24
950
GHSL: 1975-2030全球建筑体积的分布情况,以每 100 米网格单元立方米为单位
GHSL:全球2018 年建成面积(总建面和非住宅)的分布数据(10m分辨率)
GHSL: Global built-up surface 10m (P2023A)
此星光明
2025/01/21
790
GHSL:全球2018 年建成面积(总建面和非住宅)的分布数据(10m分辨率)
2018 年全球建筑物高度的分布情况,分辨率为 100 米
该空间栅格数据集描述了全球建筑物高度的分布情况,分辨率为 100 米,时间为 2018 年。 用于预测建筑物高度的输入数据是 ALOS 全球数字地表模型(30 米)、NASA 航天飞机雷达地形任务数据(30 米)以及 2017-2018 年期间 L1C 数据的全球哨兵-2 图像合成。 有关 GHSL 数据产品的更多信息,请参阅[GHSL 数据包 2023 报告](https://ghsl.jrc.ec.europa.eu/documents/GHSL_Data_Package_2023.pdf?t=1683540422),其中建筑高度层被称为平均净建筑高度(ANBH)。 全球人类居住层(GHSL)项目由欧盟委员会、联合研究中心和区域与城市政策总局支持。
此星光明
2025/01/23
610
2018 年全球建筑物高度的分布情况,分辨率为 100 米
Google Earth Engine ——全球人类住区层(GHSL)数据集
The GHSL relies on the design and implementation of new spatial data mining technologies allowing to automatically process and extract analytics and knowledge from large amount of heterogeneous data including: global, fine-scale satellite image data streams, census data, and crowd sources or volunteered geographic information sources.
此星光明
2024/02/02
2630
Google Earth Engine ——全球人类住区层(GHSL)数据集
Google Earth Engine ——GHS-MOD是GHSL采用的农村-城市住区分类MODel---城市化程度(DEGURBA)分类数据集
GHSL: Global Human Settlement Layers, Settlement Grid 1975-1990-2000-2014 (P2016)
此星光明
2024/02/02
2280
Google Earth Engine ——GHS-MOD是GHSL采用的农村-城市住区分类MODel---城市化程度(DEGURBA)分类数据集
Google Earth Engine(GEE)——GHSL 全球人口网格数据集250米分辨率
GHSL 依赖于新的空间数据挖掘技术的设计和实施,允许从大量异构数据中自动处理和提取分析和知识,这些数据包括:全球、精细规模的卫星图像数据流、人口普查数据和人群来源或自愿地理信息来源。
此星光明
2024/02/02
4070
Google Earth Engine(GEE)——GHSL 全球人口网格数据集250米分辨率
Google Earth Engine ——全球人类住区层(GHSL)项目由欧盟委员会人口的分布和密度250米分辨率数据集
GHSL依赖于新的空间数据挖掘技术的设计和实施,允许自动处理并从大量的异质数据中提取分析和知识,这些数据包括:全球的、精细的卫星图像数据流、人口普查数据、以及人群来源或自愿的地理信息来源。
此星光明
2024/02/02
2190
Google Earth Engine ——全球人类住区层(GHSL)项目由欧盟委员会人口的分布和密度250米分辨率数据集
Google Earth Engine(GEE)——GHSL:全球人类住区层,建成网格 1975-1990-2000-2015 (P2016) 数据集
GHSL 依赖于新的空间数据挖掘技术的设计和实施,允许从大量异构数据中自动处理和提取分析和知识,这些数据包括:全球、精细规模的卫星图像数据流、人口普查数据和人群来源或自愿地理信息来源。
此星光明
2024/02/02
1340
Google Earth Engine(GEE)——GHSL:全球人类住区层,建成网格 1975-1990-2000-2015 (P2016) 数据集
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)水体面积和掩膜数据集
The Gridded Population of World Version 4 (GPWv4), Revision 11 models the distribution of global human population for the years 2000, 2005, 2010, 2015, and 2020 on 30 arc-second (approximately 1km) grid cells. Population is distributed to cells using proportional allocation of population from census and administrative units. Population input data are collected at the most detailed spatial resolution available from the results of the 2010 round of censuses, which occurred between 2005 and 2014. The input data are extrapolated to produce population estimates for each modeled year.
此星光明
2024/02/02
1570
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)水体面积和掩膜数据集
Google Earth Engine——街区数据集包含2010年的人口普查街区,最小单位大致相当于一个城市街区。超过1100万个多边形特征,覆盖美国、哥伦比亚特区、波多黎各和岛屿地区。
The United States Census Bureau regularly releases a geodatabase named TIGER. This dataset contains the 2010 census blocks, roughly equivalent to a city block. There are just over 11 million polygon features covering the United States, the District of Columbia, Puerto Rico, and the Island areas.
此星光明
2024/02/02
2100
Google Earth Engine——街区数据集包含2010年的人口普查街区,最小单位大致相当于一个城市街区。超过1100万个多边形特征,覆盖美国、哥伦比亚特区、波多黎各和岛屿地区。
Google Earth Engine ——全球JRC/GSW1_3/Metadata数据集的观测数据
This dataset contains maps of the location and temporal distribution of surface water from 1984 to 2020 and provides statistics on the extent and change of those water surfaces. For more information see the associated journal article: High-resolution mapping of global surface water and its long-term changes (Nature, 2016) and the online Data Users Guide.
此星光明
2024/02/02
1270
Google Earth Engine ——全球JRC/GSW1_3/Metadata数据集的观测数据
Google Earth Engine——世界人口数据集描述了2010年、2015年和其他年份居住在每个网格单元的估计人数。
WorldPop Project Population Data: Estimated Residential Population per 100x100m Grid Square [deprecated]
此星光明
2024/02/02
2290
Google Earth Engine——世界人口数据集描述了2010年、2015年和其他年份居住在每个网格单元的估计人数。
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)人口区域数据集
The Gridded Population of World Version 4 (GPWv4), Revision 11 models the distribution of global human population for the years 2000, 2005, 2010, 2015, and 2020 on 30 arc-second (approximately 1km) grid cells. Population is distributed to cells using proportional allocation of population from census and administrative units. Population input data are collected at the most detailed spatial resolution available from the results of the 2010 round of censuses, which occurred between 2005 and 2014. The input data are extrapolated to produce population estimates for each modeled year.
此星光明
2024/02/02
1690
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)人口区域数据集
Google Earth Engine——美国人口普查局定期发布一个名为TIGER的地理数据库。这个表格包含了2010年人口普查的人口概况1的数值,按普查区汇总
The United States Census Bureau regularly releases a geodatabase named TIGER. This table contains the 2010 census Demographic Profile 1 values aggregated by census tract. Tract areas vary tremendously, but in urban areas are roughly equivalent to a neighborhood. There are about 74,000 polygon features covering the United States, the District of Columbia, Puerto Rico, and the Island areas.
此星光明
2024/02/02
1480
Google Earth Engine——美国人口普查局定期发布一个名为TIGER的地理数据库。这个表格包含了2010年人口普查的人口概况1的数值,按普查区汇总
Google Earth Engine ——全球JRC/GSW1_3/GlobalSurfaceWater数据集的观测数据
This dataset contains maps of the location and temporal distribution of surface water from 1984 to 2020 and provides statistics on the extent and change of those water surfaces. For more information see the associated journal article: High-resolution mapping of global surface water and its long-term changes (Nature, 2016) and the online Data Users Guide.
此星光明
2024/02/02
2020
Google Earth Engine ——全球JRC/GSW1_3/GlobalSurfaceWater数据集的观测数据
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)数据集
The Gridded Population of World Version 4 (GPWv4), Revision 11 models the distribution of global human population for the years 2000, 2005, 2010, 2015, and 2020 on 30 arc-second (approximately 1km) grid cells. Population is distributed to cells using proportional allocation of population from census and administrative units. Population input data are collected at the most detailed spatial resolution available from the results of the 2010 round of censuses, which occurred between 2005 and 2014. The input data are extrapolated to produce population estimates for each modeled year.
此星光明
2024/02/02
1680
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)数据集
Google Earth Engine ——基于MODIS数据集JRC/GWIS/GlobFire/v2/DailyPerimetersMCD64A1的火灾边界数据集
Fire boundaries based on the MODIS dataset MCD64A1. The data were computed based on an algorithm that relies on encoding in a graph structure a space-time relationship among patches of burned areas.
此星光明
2024/02/02
1800
Google Earth Engine ——基于MODIS数据集JRC/GWIS/GlobFire/v2/DailyPerimetersMCD64A1的火灾边界数据集
GEE数据集:1996 年到 2020 年全球红树林观测数据集(JAXA)(更新)
这项研究使用了日本宇宙航空研究开发机构(JAXA)提供的 L 波段合成孔径雷达(SAR)全球mask数据集,从 1996 年到 2020 年的 11 个时间段,建立了全球红树林范围和变化的长期时间序列。 该研究采用 "从地图到图像 "的方法进行变化检测,其中基线地图(GMW v2.5)使用阈值化和上下文红树林变化掩码进行更新。 这种方法适用于所有图像-日期对,每个时间段生成 10 幅地图,汇总后生成全球红树林时间序列。 所绘制的红树林范围图的准确度估计为 87.4%(95th conf. int.: 86.2 - 88.6%),但单个增益和损失变化类别的准确度较低,分别为 58.1%(52.4 - 63.9%)和 60.6%(56.1 - 64.8%)。误差来源包括合成孔径雷达镶嵌数据集的错误登记(只能部分纠正),以及红树林破碎区域(如水产养殖池塘周围)的混淆。 总体而言,1996 年确定的红树林面积为 152,604 平方公里(133,996 - 176,910),到 2020 年将减少-5,245 平方公里(-13,587 - 3686),总面积为 147,359 平方公里(127,925 - 168,895),估计 24 年间损失 3.4%。 全球红树林观测 3.0 版是迄今为止最全面的全球红树林变化记录,预计将支持广泛的活动,包括对全球沿海环境的持续监测、保护目标进展情况的界定和评估、保护区规划以及全球红树林生态系统的风险评估。
此星光明
2024/10/01
1880
GEE数据集:1996 年到 2020 年全球红树林观测数据集(JAXA)(更新)
推荐阅读
GHSL: 全球1975 年到 2030 年以 5 年间隔建成面积的分布情况(100m)
770
GHSL:1975-2030 年全球网格人口和建成面积数据为基础(5 年为间隔)
860
GHSL: 1975-2030全球建筑体积的分布情况,以每 100 米网格单元立方米为单位
950
GHSL:全球2018 年建成面积(总建面和非住宅)的分布数据(10m分辨率)
790
2018 年全球建筑物高度的分布情况,分辨率为 100 米
610
Google Earth Engine ——全球人类住区层(GHSL)数据集
2630
Google Earth Engine ——GHS-MOD是GHSL采用的农村-城市住区分类MODel---城市化程度(DEGURBA)分类数据集
2280
Google Earth Engine(GEE)——GHSL 全球人口网格数据集250米分辨率
4070
Google Earth Engine ——全球人类住区层(GHSL)项目由欧盟委员会人口的分布和密度250米分辨率数据集
2190
Google Earth Engine(GEE)——GHSL:全球人类住区层,建成网格 1975-1990-2000-2015 (P2016) 数据集
1340
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)水体面积和掩膜数据集
1570
Google Earth Engine——街区数据集包含2010年的人口普查街区,最小单位大致相当于一个城市街区。超过1100万个多边形特征,覆盖美国、哥伦比亚特区、波多黎各和岛屿地区。
2100
Google Earth Engine ——全球JRC/GSW1_3/Metadata数据集的观测数据
1270
Google Earth Engine——世界人口数据集描述了2010年、2015年和其他年份居住在每个网格单元的估计人数。
2290
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)人口区域数据集
1690
Google Earth Engine——美国人口普查局定期发布一个名为TIGER的地理数据库。这个表格包含了2010年人口普查的人口概况1的数值,按普查区汇总
1480
Google Earth Engine ——全球JRC/GSW1_3/GlobalSurfaceWater数据集的观测数据
2020
Google Earth Engine ——数据全解析专辑(世界第 4 版网格化人口 (GPWv4) 修订版30 弧秒1公里格网)数据集
1680
Google Earth Engine ——基于MODIS数据集JRC/GWIS/GlobFire/v2/DailyPerimetersMCD64A1的火灾边界数据集
1800
GEE数据集:1996 年到 2020 年全球红树林观测数据集(JAXA)(更新)
1880
相关推荐
GHSL: 全球1975 年到 2030 年以 5 年间隔建成面积的分布情况(100m)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档