首页 文章 精选 留言 我的

精选列表

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

Windows 11 的新体验:可安装上千个 Android 应用、任务栏优化

据 Windows + 设备首席产品官 Panos Panay 介绍, Windows 11 开始推出新体验,比如在 Windows 11 的应用商店里正式开放下载 1000+ Android 应用(目前仅限美国区)、任务栏改进、以及两个重新设计的应用程序:媒体播放器和记事本。 Windows 11 的 Android 应用和游戏 与亚马逊应用商店合作,新增了超过 1000 款应用和游戏。美国的 Windows 11 用户可以访问 Microsoft Store 中的 Amazon Appstore Preview 1,下载 Audible、Kindle、Subway Surfers、Lords Mobile、Khan Academy Kids 等热门应用程序。 据 Panos Panay 吹牛介绍:这些应用程序感觉就像是 Windows 的一部分,与 Windows 的输入和窗口体验(如 Snap 布局)自然集成。 微软将根据美国区用户的反馈,来决定是否要增加更多应用,或是否继续对其他区域的用户开放该功能。 任务栏的新增强功能 Microsoft Teams 用户可从任务栏即时访问窗口共享和静音控件。 开启 Microsoft Teams 时,每个任务都可以直接进行屏幕共享: 开启 Microsoft Teams 时,任务栏会有个麦克风,就算在会议期间切换到其他界面(摸鱼!)也能轻松开麦或者闭麦。 任务栏上的天气 天气小部件的入口改到了左下角,如果任务栏是左对齐的,则小部件的入口将位于任务栏的右侧。 将鼠标悬停在天气图标上,小部件面板将打开,并一直保持打开状态,直到将鼠标移开。 如果要保持小部件打开,则单击一次天气图标,它将保持打开状态,直到单击天气小部件之外的某个位置。 多显示器的时钟 现在多显示屏会在每个显示屏的右下角都显示时钟。 重新设计的媒体播放器和记事本 用 Media Player媒体播放器取代了 Groove 音乐应用,现有的乐库和歌单会自动转移过去。 Windows 11 的记事本也得到了“重生”,添加了新的功能,例如多级撤消、彩色表情符号以及现代高效的查找和替换体验,而且会自动跟随系统的白天/黑夜主题;菜单也得到了简化,可以更轻松地在应用程序中找到想要执行的操作。 关于新版记事本可查看以往的介绍:重新设计的 Windows 11 新版本记事本开始内测。

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

阿里云 RTC QoS 及视频编码联合优化之切流编码

如果要在两条分辨率不同的视频流之间切换,目前所有的视频编码标准都必须要编码 I 帧,即只能利用帧内预测,尽管这两条流的画面内容基本一样,但是由于两条流的参考帧不同,分辨率不同,目前所有的视频编码标准都无法做到利用帧间信息冗余进行编码,而帧内编码即 I 帧的压缩效率是非常低下的,因此在切流处很容易造成视频质量下降或由于码率突增引起的卡顿;阿里云 RTC codec 在前代标准的基础之上通过独创的切流编码技术和网络层 QoS 体系的紧密配合可以做到在此种场景下仍然利用帧间信息冗余编码 P 帧,相比于 I 帧显著提升压缩效率,提升视觉体验。 作者|安基程、田伟峰 审校|泰一 1. 背景介绍 一条视频流,如果中途改变分辨率,对于目前主流的 H.264/AVC, H.265/HEVC 标准来说,必须要编码 I 帧,即只能利用帧内信息冗余,如图 1(左)所示;新一代的编码标准如 AV1,H.266/VVC 等可以做到利用帧间信息冗余,不编 I 帧,以提升压缩效率,基本原理是通过对参考帧进行缩放,使得参考帧和当前帧的分辨率一致,如图 1(右)所示,阿里云 RTC codec 的变分辨率编码(Resolution Change Coding,以下简称 RCC)技术也具备该能力,详情请参考我们之前的分享:《阿里云 RTC QoS 弱网对抗之变分辨率编码》。 本文将要介绍的切流编码(Stream Switch Coding,以下简称 SSC)技术是对 RCC 技术的升级。 图 1. 变分辨率示意图(左:传统插入 I 帧方式;右:参考帧缩放技术) H.264/AVC 标准的 SP slice 技术可以用于切换两条分辨率一样的视频流,但是对于切换两条分辨率不同的视频流则无能为力。 2. 切流场景简介 图 2. 多流场景示意图 图 2 展示了多流场景,一个 publisher 上有两个 encoder: Enc0, Enc1, 分别发送大分辨率的流和小分辨率的流 (以下简称大流和小流),两路流的画面内容是一样的,只是分辨率,码率不同,所以清晰度不同,subscriber 可以根据自己网络状况等选择订阅不同的流,比如网络好的时候就收大流,网络差的时候收小流,图 2 中共有 6 个 subscriber 也即 6 个 decoder,其中 Dec0, Dec1, Dec2 接收的是大流,Dec3, Dec4, Dec5 接收的是小流。 图 3. 常规切流示意图 图 3 展示了发生切流时的变化,其中 Dec3 刚开始收的是小流,后面由于某种原因(如网络变好)切换到了大流,则 Enc0 必须要发送一个 I 帧来实现切流,此 I 帧会影响到所有接收大流的 subscriber (如图中的 Dec0, Dec1, Dec2,实际情况中可能会有更多的订阅者),造成切流瞬间的编码质量下降或码率突增。图中绿色箭头代表了 Dec3 接收的帧。但是如果直接将 Enc0 的 P 帧送给 Dec3, 肯定也是不行的,因为两条流的参考帧不一样,分辨率也不一样,必然造成解码错误,正是由于这些困难,目前所有的视频编码标准都未能解决这个痛点。然而阿里云 RTC Codec 通过独创的 SSC 技术可以做到在两条分辨率不同的流之间进行切换时也能够利用帧间信息冗余不编 I 帧,提升压缩效率。 图 4. 本文 SSC 技术切流示意图 图 4 展示了利用 SSC 技术进行切流,同样是 Dec3 从小流切换到大流,在切流时 Enc0 编码了一个 PDS 帧,Enc1 编码了一个 PSS 帧,图中的绿色箭头表示了 Dec3 接收的帧,其通过接收一个 PSS 帧实现了切流。PDS 帧本文称之为目标流切换帧(P frame for Destination-stream Switch),PSS 帧本文称之为源流切换帧(P frame for Source-stream Switch),Dec0, 1, 2 和之前相比,接收的 I 帧变成了 PDS 帧,Dec3 接收的 I 帧变成了 PSS 帧,PDS 帧和 PSS 帧都利用了帧间信息冗余进行编码,因此压缩效率相对于 I 帧有显著提升。 3. 测试结果 PDS 帧压缩性能测试 本文通过测试一个视频会议序列 FourPeople 来比较 I 帧,P 帧,和 PDS 帧的压缩性能。将该序列分别压缩为全 I 帧,全 P 帧(除了第一帧为 I 帧),和全 PDS 帧(除了第一帧为 I 帧)。图 5 展示了压缩结果,横坐标为码率,纵坐标为 PSNR,精确计算 BD-rate 显示,同等质量下,P 帧可以比 I 帧节省 93% 码率,PDS 帧在具备 I 帧的切流能力的同时可以比 I 帧节省 66% 码率。 图 5. PDS 帧压缩性能展示 本测试直接说明如果将一个序列每帧都编码为 I 帧,则其每帧都具备切流能力,但是损失了压缩性能,如果都编码为 P 帧,虽然可以比 I 帧节省 93% 码率,但是完全不具备切流能力,如果都编码为 PDS 帧,则可以在保留 I 帧切流能力的同时,比 I 帧节省 66% 码率。 实际场景中一般不会每帧都出现切流的情况,本测试表明在切流处,目标流利用 PDS 帧可以比 I 帧节省 66% 码率。 PSS 帧压缩性能测试 由于 PSS 帧涉及到分辨率的切换,用传统(如 H.264, H.265 标准)的 P 帧已无法编码,所以本文只比较了 I 帧和 PSS 帧的压缩性能。本文使用了一个大小分辨率帧交错的视频会议序列来测试,即偶数帧为大分辨率,奇数帧为小分辨率,分别编码全 I 帧,和全 PSS 帧(除了第一帧为 I 帧)。同等质量下,PSS 帧比 I 帧可以节省 29% 码率。 图 6. 常规连续切流示例 图 7. 本文 SSC 技术连续切流示例 本测试直接表明的是一个不断切流的场景,如图 6 所示,Dec3 不断的在大小流之间切换,图 6 展示的是用原有编码 I 帧的切流方式,则 Dec3 收到的全是 I 帧,图 7 展示的是用本文的 SSC 技术的切流方式,Dec3 收到的则全是 PSS 帧,本测试说明在这种情况下 PSS 帧可以比 I 帧节省 29% 码率,率失真曲线如图 8 所示。 图 8. PSS 帧压缩性能展示 实际场景中一般不会出现一直切流的情况,本测试表明在切流处,源流利用 PSS 帧可以比 I 帧节省 29% 码率。 综上,利用本文展示的阿里云 RTC 独创的 SSC 技术,在切流处,目标流可以比 I 帧节省 66% 码率,源流可以比 I 帧节省 29% 码率。 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。公众号后台回复【技术】可加入阿里云视频云技术交流群,和作者一起探讨音视频技术,获取更多行业最新信息。

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

数据库连接池终于搞对了,直接从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开发者交流钉钉群”不

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

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

用户登录
用户注册