首页 文章 精选 留言 我的

精选列表

搜索[优化],共10000篇文章
优秀的个人博客,低调大师

数据库连接池终于搞对了,直接从100ms优化到3ms!

我在研究HikariCP(一个数据库连接池)时无意间在HikariCP的Github wiki上看到了一篇文章(即前面给出的链接),这篇文章有力地消除了我一直以来的疑虑,看完之后感觉神清气爽。故在此做译文分享。 接下来是正文 数据库连接池的配置是开发者们常常搞出坑的地方,在配置数据库连接池时,有几个可以说是和直觉背道而驰的原则需要明确。 1万并发用户访问 想象你有一个网站,压力虽然还没到Facebook那个级别,但也有个1万上下的并发访问——也就是说差不多2万左右的TPS。那么这个网站的数据库连接池应该设置成多大呢?结果可能会让你惊讶,因为这个问题的正确问法是: “ 这个网站的数据库连接池应该设置成多小呢 ?” 下面这个视频是Oracle Real World Performance Group发布的,请先看完:http://www.dailymotion.com/video/x2s8uec (因为这视频是英文解说且没有字幕,我替大家做一下简单的概括:)视频中对Oracle数据库进行压力测试,9600并发线程进行数据库操作,每两次访问数据库的操作之间sleep 550ms,一开始设置的中间件线程池大小为2048: 初始的配置 压测跑起来之后是这个样子的: 2048连接时的性能数据 每个请求要在连接池队列里等待33ms,获得连接后执行SQL需要77ms 此时数据库的等待事件是这个熊样的: 各种buffer busy waits 各种buffer busy waits,数据库CPU在95%左右(这张图里没截到CPU) 接下来,把中间件连接池减到1024(并发什么的都不变),性能数据变成了这样: 连接池降到1024后 获取链接等待时长没怎么变,但是执行SQL的耗时减少了。下面这张图,上半部分是wait,下半部分是吞吐量 wait和吞吐量 能看到,中间件连接池从2048减半之后,吐吞量没变,但wait事件减少了一半。 接下来,把数据库连接池减到96,并发线程数仍然是9600不变。 96个连接时的性能数据 队列平均等待1ms,执行SQL平均耗时2ms。 wait事件几乎没了,吞吐量上升。 没有调整任何其他东西,仅仅只是缩小了中间件层的数据库连接池,就把请求响应时间从100ms左右缩短到了3ms。 But why? 为什么nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD?回想一下计算机科学的基础知识,答案其实是很明显的。 即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都[应该]知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程,然后操作系统切换上下文,核心开始执行另一个线程的代码,以此类推。给定一颗CPU核心,其顺序执行A和B永远比通过时间分片“同时”执行A和B要快,这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量,再增加线程数系统就只会更慢,而不是更快。 这几乎就是真理了…… 有限的资源 上面的说法只能说是接近真理,但还并没有这么简单,有一些其他的因素需要加入。当我们寻找数据库的性能瓶颈时,总是可以将其归为三类:CPU、磁盘、网络。把内存加进来也没有错,但比起磁盘和网络,内存的带宽要高出好几个数量级,所以就先不加了。 如果我们无视磁盘和网络,那么结论就非常简单。在一个8核的服务器上,设定连接/线程数为8能够提供最优的性能,再增加连接数就会因上下文切换的损耗导致性能下降。 数据库通常把数据存储在磁盘上,磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出现在一个地方,然后它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时,此外还有旋回耗时,读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升性能的,但上述原理仍然成立。 在这一时间段(即"I/O等待")内,线程是在“阻塞”着等待磁盘,此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以,由于线程总是在I/O上阻塞,我们可以让线程/连接数比CPU核心多一些,这样能够在同样的时间内完成更多的工作。 那么应该多多少呢?这要取决于磁盘。较新型的SSD不需要寻址,也没有旋转的碟片。可别想当然地认为“SSD速度更快,所以我们应该增加线程数”,恰恰相反,无需寻址和没有旋回耗时意味着更少的阻塞,所以更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时,更多的线程数才能发挥出更好的性能。 网络和磁盘类似。通过以太网接口读写数据时也会形成阻塞,10G带宽会比1G带宽的阻塞少一些,1G带宽又会比100M带宽的阻塞少一些。不过网络通常是放在第三位考虑的,有些人会在性能计算中忽略它们。 上图是PostgreSQL的benchmark数据,可以看到TPS增长率从50个连接数开始变缓。在上面Oracle的视频中,他们把连接数从2048降到了96,实际上96都太高了,除非服务器有16或32颗核心。 计算公式 下面的公式是由PostgreSQL提供的,不过我们认为可以广泛地应用于大多数数据库产品。你应该模拟预期的访问量,并从这一公式开始测试你的应用,寻找最合适的连接数值。 连接数 = ((核心数 * 2) + 有效磁盘数) 核心数不应包含超线程(hyper thread),即使打开了hyperthreading也是。如果活跃数据全部被缓存了,那么有效磁盘数是0,随着缓存命中率的下降,有效磁盘数逐渐趋近于实际的磁盘数。这一公式作用于SSD时的效果如何尚未有分析。 按这个公式,你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是不是觉得太小了?跑个性能测试试一下,我们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10,你会看到响应时长开始增加,TPS开始下降。 笔者注:这一公式其实不仅适用于数据库连接池的计算,大部分涉及计算和I/O的程序,线程数的设置都可以参考这一公式。我之前在对一个使用Netty编写的消息收发服务进行压力测试时,最终测出的最佳线程数就刚好是CPU核心数的一倍。 公理:你需要一个小连接池,和一个充满了等待连接的线程的队列 如果你有10000个并发用户,设置一个10000的连接池基本等于失了理智。1000仍然很恐怖。即是100也太多了。你需要一个10来个连接的小连接池,然后让剩下的业务线程都在队列里等待。连接池中的连接数量应该等于你的数据库能够有效同时进行的查询任务数(通常不会高于2*CPU核心数)。 我们经常见到一些小规模的web应用,应付着大约十来个的并发用户,却使用着一个100连接数的连接池。这会对你的数据库造成极其不必要的负担。 请注意 连接池的大小最终与系统特性相关。 比如一个混合了长事务和短事务的系统,通常是任何连接池都难以进行调优的。最好的办法是创建两个连接池,一个服务于长事务,一个服务于短事务。 再例如一个系统执行一个任务队列,只允许一定数量的任务同时执行,此时并发任务数应该去适应连接池连接数,而不是反过来。 译:http://suo.im/600LJ0 本文分享自微信公众号 - IT老哥(dys_family)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

“帮助企业做好MaxCompute成本优化的实践” 主题分享 6月21日 18:30不见不散

计算的价值绝不止计算本身,而是让本不会说话的数据发声。阿里云大数据计算服务MaxCompute以技术驱动产品,历经10年沉淀,成功支持阿里集团几乎99%的数据存储以及95%的计算,成为历年双11背后的核武器;更为众多企业提供快速、完全托管的从GB到EB级的数据仓库解决方案,助力企业经济高效的分析处理海量数据,实现数据和业务的更大价值。MaxCompute作为强劲的新一代计算引擎,具备超大规模存储,多种计算模式,强安全,低成本的众多优势,连续三年在世界级sort benchmark和bigbench中表现出卓越水平,用实力证明“中国计算,世界能力”。 在这个初夏,MaxCompute与大数据开发者们共同开启“因计算,共成长”分享季。 第一季《MaxCompute开发实战,爽爽不油腻》四次主题分享“MaxCompute开发者交流钉钉群”不

优秀的个人博客,低调大师

十个网络优化改造案例之一 交换机由单机改造为双机热备

主要内容及技术 Cisco交换机配置HSRP实现双机热备 关键字:Cisco、HSRP、多模光纤、光模块选择 前言: 在设计网络的时候,最先要避免的就是“单点故障”。什么是“单点故障”?简单的说,就是担任核心转发任务的设备只有一台,当这台设备负载过重或者是遇到其他故障的时候停机,从而使得网络出现瘫痪等问题。为了避免“单点故障”的出现,必须为担任核心转发任务的设备配置热备份,也就是两台设备,一主一备,当主用设备发生故障的时候,能够将数据转发任务自动的切换到备份设备上。 热备份技术在网络中非常常用,不仅是交换机和路由器,就连服务器也会使用到热备份技术。交换路由的热备份技术常用的有HSRP(Cisco私有协议)、VRRP等。本案例就以HSRP技术为例,讲解在实际工作中如何使用HSRP来实现热备份的。 一、项目需求 某国有企业的数据中心的办公区域网络目前只有一台Cisco 6509在担任汇聚层交换机任务,考虑到只有一台交换机工作,网络可靠性比较低,无法实现热备的功能。现甲方要求增加一台Cisco 6509,和原有的Cisco 6509配置成HSRP,实现热备份的功能。 现行的网络结构如下图所示: Cisco 6509的主机名为DC1-C2#26U-Office-6509-1,其中的Gi1/0/48和Gi1/0/47接口分别接在两台Juniper SRX 650防火墙上(这两台防火墙均为透明模式防火墙,已经做了双机热备)。 需要说明一下这里的Cisco 6509的主机名命名格式: 机房名称-机柜名称#上架位置-网络位置-型号-序号 l DC1表示该设备在名称为DC1的机房内; l C2#26U表示该设备在C排2号机柜,设备上端位于该机柜26U的位置 l Office表示这是办公区域的交换机 l 6509表示这个设备的型号是Cisco 6509 l 1表示这是第一台交换机 图例:Cisco 6509交换机 二、前期准备 2.1、实地调研 实地调研的目的是看看机房内有没有预留该案例实施的环境。调研的内容有以下几点内容: 1、有无足够的空间放置备用的Cisco 6509,该设备需要占用机柜14U。本案例找到的机柜为C5柜,中间隔着C3、C4柜。 2、投运中的Cisco 6509上还有无空余的接口,至少两个千兆光纤接口,本案例找到的接口是Gi1/0/45—47都空余。 3、根据主用Cisco 6509与备用Cisco 6509之间的距离,准备足够长度的光纤。由于主用设备和备用设备之间隔着两个机柜,并且光纤要求从地板下方穿越,所以准备的光纤长度为10m。 2.2、测试备用设备 备用设备需要进行如下测试: 1、查看备用设备的板卡是否齐全,除了引擎版以外,至少拥有一块48口的千兆光纤接口板卡(简称48口千兆光板)。下图展示了该板卡。 2、检查备用设备是否能够正常启动,并且没有任何报错信息。这个需要在备用设备上插上Console线,看设备的启动信息。在设备稳定启动以后,不能出现风扇、内存等硬件的报错信息,不能出现故障电源模块。通过show module查看发现状态都应该是正常状态。 show module看见光纤模块的名称有“SPF”字样,说明必须使用单模光纤。 3、查看备用设备的IOS软件版本信息,可以通过show version查看。如果备用设备的IOS软件版本比主用设备的新,则不必管;如果备用设备的IOS的软件版本低于主用设备的IOS软件版本,则必须给备用设备的IOS进行升级操作。 查看软件的版本信息: xxx-RA6509#showversion CiscoInternetworkOperatingSystemSoftware IOS(tm)s72033_rpSoftware(s72033_rp-ADVENTERPRISEK9_WAN-M),Version12.2(18)SXF9,RELEASESOFTWARE(fc1) …… ROM:SystemBootstrap,Version12.2(14r)S9,RELEASESOFTWARE(fc1) BOOTLDR:s72033_rpSoftware(s72033_rp-ADVENTERPRISEK9_WAN-M),Version12.2(18)SXF9,RELEASESOFTWARE(fc1) Xxx-RA6509uptimeis1year,12weeks,6hours,53minutes TimesinceXxx-RA6509switchedtoactiveis1year,12weeks,6hours,48minutes SystemreturnedtoROMbys/wreset(SPbywatchdogNMIatPC0xBFC25FD4,address0x0) Systemrestartedat09:59:28CCTWedSep92015 p_w_picpathfileis"disk1:s72033-adventerprisek9_wan-mz.122-18.SXF9.bin" 三、进入实施步骤 3.1、收集设备的配置信息 在收集完成硬件信息以后,下面的工作就是要收集设备的配置信息了。本案例需要收集的信息是主用设备正在运行的配置信息。建议把show running-config显示的配置信息全部拷贝下来,取关键部位的配置进行查看。 本案例的关键位置主要是VLAN接口的IP地址配置信息和路由信息,经查看配置信息如下: interfaceLoopback0 ipaddress10.115.129.14255.255.255.255 noshutdown ! interfaceVlan1 interfaceVlan10 ipaddress10.115.128.57255.255.255.248 noshutdown ! interfaceVlan130 descriptionoffice ipaddress10.115.130.254255.255.255.0 noshutdown ! ! iproute0.0.0.0/010.115.128.49 iproute9.234.3.211255.255.255.25510.115.128.58 iproute9.234.3.253255.255.255.25510.115.128.58 iproute9.234.21.210255.255.255.25510.115.128.58 iproute9.234.21.211255.255.255.25510.115.128.58 iproute10.2.1.2255.255.255.25510.115.128.58 iproute10.3.1.2255.255.255.25510.115.128.58 iproute10.4.1.2255.255.255.25510.115.128.58 iproute10.5.1.2255.255.255.25510.115.128.58 iproute10.8.1.0255.255.255.010.115.128.58 …… iproute192.168.45.223255.255.255.25510.115.128.58 iproute192.168.45.240255.255.255.25510.115.128.58 iproute192.168.45.241255.255.255.25510.115.128.58 iproute199.198.18.40255.255.255.25510.115.128.58 通过路由信息可以看到,该设备的路由信息都是写的静态路由,而且下一跳地址都是10.115.128.58,对照interface vlan 10的配置信息,可以推断出VLAN 10是连接核心设备的互联VLAN,而VLAN130是办公区域的业务VLAN。 根据VLAN 10和VLAN 130当前配置的IP地址,可以进行HSRP虚拟IP地址的规划: VLAN ID 虚拟IP 主用设备IP 备用设备IP 10 10.115.128.57 10.115.128.61 10.115.128.62 130 10.115.130.254 10.115.130.252 10.115.130.253 对于VLAN10的地址,由于10.115.128.58、10.115.128.59、10.115.128.60已经被上行设备使用,所以主用设备IP地址为10.115.128.61-62,虚拟IP地址仍然使用10.115.128.57。这里需要注意的就是:生效的IP地址如非万不得已不要更改,否则会导致上下行设备的静态路由大规模更改。 对于VLAN 130的地址是一个/24的大段,IP地址足够,所以可以让10.115.130.252当主用设备的IP地址,10.115.130.253当备用设备的IP地址。虚拟地址仍然使用10.115.130.254,也防止了主机大规模的修改默认网关。 静态路由可以完全粘贴到备用设备中。 3.2、画改造之后的拓扑图 根据配置命令和之前调研的结果,就可以画出网络改造之后的拓扑图了。 a、 连接线的修改 在网络改造之前,Cisco 6509-1的Gi 1/0/47接口连接在Juniper-SRX650-2上,Gi 1/0/48接口连接在Juniper-SRX650-1上。两个接口都是Trunk模式,允许通过的VLAN ID是10和30。 在网络改造以后,Cisco 6509-1和Cisco 6509-2之间使用Gi 1/0/47互为心跳线。Cisco 6509-2的Gi 1/0/48接口连接在Juniper-SRX650-2上。 综上所述:Cisco 6509-1和Cisco 6509-2的Gi 1/0/47和Gi 1/0/48接口都是Trunk模式,允许通过的VLAN ID是10和30。 b、画拓扑图: 3.3、准备配置脚本 a、Cisco6509-1的配置命令 track1iproute0.0.0.00.0.0.0reach interfaceVlan1 interfaceVlan10 ipaddress10.115.128.61255.255.255.248 standby10ip10.115.128.57 standby10pri105 standby10pree standby10track1dec10 ! interfaceVlan130 descriptionoffice ipaddress10.115.130.252255.255.255.0 standby130ip10.115.130.254 standby130pri105 standby130pree standby130track1dec10 ! b、Cisco6509-2的配置命令 interfacegi1/0/47 switchtrunkendo switchmodetrunk switchtrunkallvlan10,130 interfacegi1/0/48 switchtrunkendo switchmodetrunk switchtrunkallvlan10,130 interfaceVlan1 interfaceVlan10 ipaddress10.115.128.62255.255.255.248 standby10ip10.115.128.57 standby10pri100 standby10pree standby10track1dec10 ! interfaceVlan130 descriptionoffice ipaddress10.115.130.253255.255.255.0 standby130ip10.115.130.254 standby130pri100 standby130pree standby130track1dec10 ! iproute0.0.0.0/010.115.128.49 iproute9.234.3.211255.255.255.25510.115.128.58 iproute9.234.3.253255.255.255.25510.115.128.58 iproute9.234.21.210255.255.255.25510.115.128.58 iproute9.234.21.211255.255.255.25510.115.128.58 iproute10.2.1.2255.255.255.25510.115.128.58 iproute10.3.1.2255.255.255.25510.115.128.58 iproute10.4.1.2255.255.255.25510.115.128.58 iproute10.5.1.2255.255.255.25510.115.128.58 iproute10.8.1.0255.255.255.010.115.128.58 …… iproute192.168.45.223255.255.255.25510.115.128.58 iproute192.168.45.240255.255.255.25510.115.128.58 iproute192.168.45.241255.255.255.25510.115.128.58 iproute199.198.18.40255.255.255.25510.115.128.58 四、总结 本案例所涉及的知识点只有HSRP一个,看起来比较简单。但在实际的工作中需要考虑的问题依然不少。例如: 1、主用设备和备用设备当前的运行状况需要进行检查。对于正在使用的主用设备,需要先进行一次巡检,确保当前运行状况是正常的。否则在实施过程中主用设备出现故障是一件非常麻烦的事情。对于备用设备一定要经过测试,在完全没有硬件故障以后才可以上架。 2、对于光纤的选择,一定要进入机房,确定光纤的长度。光纤过短会导致项目无法实施下去,光纤过长会造成资源浪费。 3、在客户无法提供详细拓扑图的情况下,对于设备的连线位置,设备的配置信息一定要弄清楚,要不然到了实施现场只能是抓瞎了。

优秀的个人博客,低调大师

Android官方开发文档Training系列课程中文版:布局性能优化之按需加载View

原文地址:http://android.xsoftlab.net/training/improving-layouts/loading-ondemand.html 有时应用程序中会有一些很少用到的复杂布局。在需要它们的时候再加载可以降低内存的消耗,同时也可以加快界面的渲染速度。 定义ViewStub ViewStub是一个轻量级的View,它没有高宽,也不会绘制任何东西。所以它的加载与卸载的成本很低。每个ViewStub都可以使用android:layout属性指定要加载的布局。 下面这个ViewStub用于一个半透明的ProgressBar的加载。它只有在新工作开始时才会显示。 <ViewStub android:id="@+id/stub_import" android:inflatedId="@+id/panel_import" android:layout="@layout/progress_overlay" android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_gravity="bottom" /> 加载ViewStub 当需要加载由ViewStub所指定的布局时,可以使用setVisibility(View.VISIBLE)方法或者inflate()方法,两者效果相同。 ((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE); // or View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate(); Note: inflate()方法会在加载完毕的时候返回一个View。所以不需要使用findViewById()来查找这个布局的Root View。 一旦ViewStub所托管的View被加载,那么ViewStub将不再是View层级的一部分。它会被所加载的布局替换,并且会将该布局的ID更改为ViewStub的android:inflatedId属性所指定的ID。 Note: ViewStub的缺点是:它当前并不支持要加载布局的root View为< merge/>标签。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册