标签：性能优化

共 213 篇相关文章

IT 累计浏览 2,040

从 Nginx 默认不压缩 HTTP/1.0 说起

这篇讲的是，Nginx 默认只为 HTTP/1.1 启用 GZip 压缩，而对 HTTP/1.0 请求关闭压缩，这背后并非配置疏忽，而是 HTTP 协议特性在服务端实现中的一个关键权衡。文章从移动端异常高比例的 HTTP/1.0 流量这一现象切入，深入剖析了原因。Nginx 默认采用即时压缩（On-The-Fly Compression）以优化首字节时间，但这导致无法预知响应大小，无法设置 Content-Length。在 HTTP/1.0 中，没有 HTTP/1.1 的 Transfer-Encoding: chunked 分块传输机制，客户端只能依靠 Content-Length 或断开连接来判断结束。因此，Nginx 为了在 HTTP/1.0 上尽可能保持持久连接（keep-alive），默认选择了放弃压缩。一旦启用 HTTP/1.0 压缩，Nginx 就只能返回 Connection: close 来结束传输。文章通过对比测试验证了这一机制，并给出了务实建议：对于动态内容（如 PHP 输出的 HTML），因其本身无法预知大小，不妨启用 GZip 以节省流量；对于可预知大小的静态文件（JS、CSS），则建议将关键资源内联，非关键资源用外链并启用压缩，接受连接断开以换取流量节省。一个看似简单的 Nginx 配置，背后其实是 HTTP/1.0 与 1.1 在协议能力上的深刻差异。

IT 累计浏览 2,962

iOS 高性能异构滚动视图构建方案 —— LazyScrollView

这篇文章讲的是如何解决iOS开发中一个棘手的性能问题：当滚动视图需要展示大量异构（非统一Cell）的视图内容时，传统的UITableView或UICollectionView方案会显得不够灵活或性能不足。作者从天猫客户端首页的实际需求出发，详细介绍了他们自研的LazyScrollView方案。 LazyScrollView继承自UIScrollView，其核心设计思想是在初始状态就通过一个DataSource协议，预先获知所有子视图在滚动视图内的绝对布局坐标（Rect）。这使得框架能在滚动过程中精准计算哪些视图应该被加载或回收，实现了跨不同视图层级的复用，效果类似于TableView的复用机制，但适配性更广。文章不仅阐述了背景和原理，还提供了清晰的使用指南，包括实现特定的数据源协议以及调用关键API。通过实际Demo演示，直观展示了视图在滚动时被复用标记的变化。内部实现的核心在于根据预先计算好的布局信息进行视图管理，这种思路为处理复杂、动态布局的滚动视图提供了一个高效的解决路径。

IT 累计浏览 1,664

Linux内核参数调整

这篇讲的是如何通过调整一系列Linux内核参数，来解决高并发服务器性能瓶颈与稳定性问题。作者从实践出发，将原本分散的配置点系统地串联起来。文章的核心在于将ulimit文件描述符限制提升到10万以上，这是支撑海量并发连接的基础。同时，详细拆解了几个关键网络参数的调整：比如增大socket缓存区以优化数据吞吐，设置tcp_tw_reuse和tcp_tw_recycle以加速服务重启时的端口回收，以及启用tcp_syncookies来防御SYN洪水攻击。对于进程间通信，也给出了消息队列的具体配额建议。除了性能，文章还关注了调试与兼容性。它解释了如何开启并配置coredump，以便在程序崩溃时快速定位问题；并补充了FreeBSD/MacOS下的类似调整方法。整篇文章更像一份精心整理的“调优清单”，把影响高负载服务器的文件限制、网络栈、IPC和故障诊断等关键环节都梳理到了一起，给出了从原理到具体配置值的直接指导。

IT 累计浏览 2,129

让我们写快速的JavaScript,JS性能优化小窍门

这篇讲的是如何写出更快的JavaScript代码。作者从JS性能尚未达到极限的现状出发，直指在混合应用等场景中，性能优化仍是必要的“伎俩”。文章没有空谈理论，而是用一系列直观的对比测试来揭示优化窍门。它告诉你，动态类型虽灵活，但会拖慢速度，保持变量类型一致（尤其是数组）是关键；`delete`运算符比赋值为`null`慢得多，而动态添加对象属性也会带来巨大开销。对于字符串拼接，`+=`运算符在主流浏览器上都胜过`concat`和`join`。在正则表达式使用上，`RegExp.prototype.exec`通常也比`String.prototype.search`更快。更重要的是，这些结论都附带了跨浏览器（如Firefox与Chrome）的性能测试数据，比如位运算在Firefox上极快但在Chrome上却更慢。这些基于具体测试的发现，能帮助开发者在编写或优化JS代码时做出更明智的选择，避免那些“昂贵”的操作，让代码真正跑得更快。

IT 累计浏览 3,187

一次临时表空间大量占用问题的处理

这篇讲的是如何诊断和解决一个核心交易系统临时表空间暴涨至600GB的问题。作者从实际案例出发，发现占用临时空间的大量排序段，并非由当前执行的SQL产生，而是源于大量会话打开了需要复杂排序的查询游标后，一直没有关闭，导致Oracle必须维持这些游标的状态和已排序的数据，从而长期占用临时段。文章详细展示了排查过程：通过v$sort_usage定位到大量会话关联同一个SQL_ID，但发现该SQL本身并不需要排序。真正的“元凶”是这些会话中打开的另一个游标——一条对千万级数据进行排序的业务查询。由于应用在取数后未正确关闭游标，使得排序段无法释放。作者甚至用PL/SQL代码复现了这一过程，清晰演示了临时空间是如何被一个未关闭的游标“泄漏”出去的。这篇案例的精彩之处在于，它纠正了一个常见误区，并提供了一套实用的诊断思路：当遇到临时表空间异常时，应重点检查会话的打开游标，特别是那些有大量排序操作且未完成处理的SQL，而不仅仅是看当前正在执行的语句。

IT 累计浏览 2,764

移动端点击、触碰随记

这篇讲的是移动端开发里几个老生常谈却又总踩坑的“事故”：点击延迟、点穿和焦点获取错误。作者从实测数据出发，直观展示了移动端原生click事件为何存在约300ms的固定延迟（为了判断是否双击缩放），以及为何要拥抱更快的tap事件（如zepto的实现）。文章深入分析了触摸事件与鼠标事件的触发顺序，指出tap和click本质是同一次触碰的不同阶段。针对“点穿”这个经典坑（根源在于事件绑定层级），作者对比了阻止事件流的方法，明确preventDefault是关键大招，并顺势对比了fastclick、Yocto等库的解决方案，分析了它们的原理与适用场景。最后，文章还深入探讨了在Angular框架下如何处理ng-click点穿问题，以及如何区分处理input、textarea等元素的焦点获取需求，给出了具体的代码思路。全文从现象到原理，再到框架内的实战方案，是一份扎实的移动端触控问题排查指南。

IT 累计浏览 2,835

小心别让圆角成了你列表的帧数杀手

这篇讲的是在iOS滚动列表中滥用圆角导致性能暴跌的“坑”。作者实测发现，为cell中的UIImageView设置`cornerRadius`时，随着圆角视图数量增加，帧率会迅速下滑至45fps甚至30fps以下，造成明显的卡顿感。更出人意料的是，使用`layer.mask`来实现圆角，性能比`cornerRadius`还要差，帧率可能直接跌到20fps。文章剖析了根源在于**离屏渲染**，特别是频繁的上下文切换带来了数十倍于普通渲染的开销。对此，作者给出了明确的避坑指南：滚动列表中应尽量避免使用`cornerRadius`或`mask`。如果必须使用，可以通过开启`shouldRasterize`来缓存渲染结果，或者采用预处理圆角图片、覆盖镂空图层等更高效的替代方案来保障流畅度。

IT 累计浏览 3,575

微信朋友圈技术之道

这篇讲的是微信朋友圈在面临十亿级日发布、百亿级日浏览的海量压力时，如何保障系统稳定与性能的核心架构。微信朋友圈负责人陈明分享了其背后的技术之道。面对移动互联网汹涌的峰值流量（如春节期间流量达平日5倍），系统通过一套自动化的服务优先级策略进行应对：优先保障支付与点对点消息，然后是群聊，最后才是朋友圈。在核心架构上，朋友圈采用“写扩散”模型——用户发布内容时，会将数据副本写入每个好友的时间线表。这种看似“重”的写入，换来了极其简单可靠的读取（只读自己的时间线），大幅降低了读失败的可能性。文章还揭示了朋友圈数据依赖的四个核心表（发布、相册、评论、时间线）及其水平扩展方式，并详细阐述了多层级容灾设计。从同城多园区无感切换，到全球多数据中心的跨地域同步，微信甚至为适应高延迟、高丢包的跨国公网环境，自研了类TCP协议以保证数据同步的效率与安全。整个分享从数据背景、架构选型到容灾细节，清晰展示了一个超大规模社交系统如何在性能与可靠性之间做出权衡与设计。

IT 累计浏览 3,679

iOS 保持界面流畅的技巧

这篇深度解析从 iOS 屏幕显示原理入手，剖析了界面卡顿的根源。文章详细拆解了 VSync 机制下，CPU 与 GPU 协同工作的流程，并指出当任一方未能及时完成渲染时，掉帧便会发生。作者系统性地列举了 CPU 侧的对象创建与销毁、布局计算（尤其是 Autolayout 的性能陷阱）、文本渲染等常见开销来源，也涵盖了 GPU 侧的渲染与合成问题。在剖析原理的基础上，文章重点介绍了 AsyncDisplayKit 框架。作者阐述了其图层预合成、异步并发操作等核心设计，以及如何利用 Runloop 进行任务分发，从而将主线程从繁重的布局和渲染任务中解放出来。文章更提供了极具实践价值的参考：一个完全仿照微博、Twitter 的开源列表 Demo。通过预排版、预渲染、异步绘制等优化技巧的组合运用，该 Demo 即使在 iPhone 4S 上快速滑动，也能稳定保持 50-60 FPS 的流畅度。这不仅仅是理论分析，更是一份可供验证、对比和直接使用的性能优化方案指南。

IT 累计浏览 2,526

Spark的性能调优

这篇文章从实战经验出发，汇总了Spark性能调优的多个关键方向。内容不仅涵盖基础配置，更深入到应用代码设计与任务执行策略。开篇即点明，调优的第一步往往从数据序列化开始，对比了默认的Java序列化与更快更紧凑的Kryo方案。紧接着是内存管理，文章给出了具体的检测方法（如使用UI或SizeEstimator）和优化建议（如启用压缩指针）。GC调优部分尤为实用，解释了默认内存分配比例、Eden区设置，并分享了如何避免因大量对象创建导致的“GC overhead limit exceeded”错误。对于影响性能的关键因素，文章详细阐述了并行度、Reduce Task内存使用以及Shuffle的优化。例如，通过广播变量减少大表shuffle是一个经典模式。数据本地性的五个层级及其调度策略也被清晰说明。文件存储与读取优化（如使用Parquet列存格式）和Speculation（推测执行）机制也被纳入考量。最后，文章强调了合理设置分区数和减少不必要Shuffle的重要性，并给出了具体的代码示例指引。整篇文章既包含JVM级别的参数调整，也涉及Spark应用层的数据结构设计与API选择（如prefetchByKey vs groupByKey），是一份从理论公式到实战经验的综合性调优指南。

IT 累计浏览 1,957

RDS MySQL参数调优最佳实践

这篇讲的是RDS MySQL用户常困惑的参数调优问题。作者从实际场景出发，首先明确了哪些参数由产品规格或数据安全决定无法修改，比如内存、连接数和主备同步相关参数。这解决了用户“能不能改”的首要疑惑。文章的核心价值在于，它清晰地指出绝大部分参数已由专业团队优化，仅需针对特殊场景微调。随后，作者深入剖析了open_files_limit、back_log、innodb_autoinc_lock_mode等几个关键参数：逐一说明其作用、设置不当会引发的典型错误现象（如“Too many open files”、连接超时或死锁），并给出了具体的调整建议和原理。此外，文章还介绍了几个RDS特有的实用参数，例如控制临时磁盘空间的rds_max_tmp_disk_space和用于保护数据库的rds_threads_running_high_watermark，让读者能按需应用。整体而言，这篇文章并非泛泛而谈，而是提供了从“能否修改”到“为何调整”再到“如何调整”的完整实践路径，能帮助用户避免性能陷阱。

IT 累计浏览 2,482

如何成为MySQL DBA

这篇文章就像一份路线图，为想进入MySQL DBA领域的朋友清晰地规划了从入门到进阶的学习路径。作者凭借十多年的一线经验，指出不必过分畏惧这个岗位的门槛，并强调了扎实的Linux基础是关键的第一步。核心内容聚焦于一条明确的DBA学习主线：从理解MySQL版本与启动原理、掌握基础SQL语言，到深入学习复制、备份恢复、压力测试，直至最终能剖析InnoDB的事务与锁机制。作者不仅列出了具体要掌握的技术点，还分享了一些实用建议，比如学习SQL规范时可以请教有经验的前辈。文章进一步指出了向高级DBA迈进时需要拓展的知识面，包括操作系统层面的IO与内存理解、高可用架构的自主设计以及平台管理能力。最后，作者回归到技术人持续学习的本质，为这条成长之路定下了脚踏实地的基调。

IT 累计浏览 4,743

让PHP7达到最高性能的几个Tips

这篇讲的是PHP 7性能调优的实战经验。作者（鸟哥）指出，尽管PHP 7性能相比前代已有大幅提升，但通过一系列精准的配置和编译优化，还能进一步榨取其潜力。文章提供了五个具体可操作的Tips。核心建议包括：**务必启用Zend Opcache**（PHP 7未启用时已比PHP 5.6启用后快，但开启后仍有收益）；**使用GCC 4.8以上版本编译**，可获得约5%的性能提升；**配置HugePage**以减少TLB Miss；以及开启**Opcache File Cache**（实验性）和针对特定项目使用**PGO（Profile Guided Optimization）** 进行定制化编译优化。这些方案从基础配置到高阶编译技巧层层递进，作者通过WordPress等实例说明了PGO等优化如何为特定应用带来量身定制的性能提升，为追求极致PHP性能的开发者提供了清晰的技术路线。

IT 累计浏览 3,599

缓存算法–LRU

这篇讲的是两种经典的缓存淘汰算法：LRU和它的改进版LRU-K。文章开门见山，先解析了LRU（最近最少使用）的核心思想——它用一个巧妙的链表来实现，新数据插入头部，每次访问都把数据提到最前，满了就淘汰尾部那个“最久没碰”的。这种策略在热点数据集中时效率很高，实现也简单。但文章也指出了LRU的软肋：一旦出现偶发的批量扫描，会挤掉很多热门数据，造成严重的“缓存污染”。为了解决这个问题，文章引入了LRU-K。这里的“K”代表一个访问次数阈值，比如我们常说的LRU-2。它不再因为一次访问就把数据加入缓存，而是让数据在历史队列中先“排队”，只有被访问了K次，证明它确实是热点，才获准进入缓存队列。这样一来，LRU-K的命中率通常比LRU更高，能有效抵抗缓存污染。但天下没有免费的午餐，它的实现需要维护额外的访问历史队列并进行排序，算法复杂度、内存消耗和CPU开销都比LRU要高。文章最后也点明了选择的关键：LRU胜在简单高效，适合大多数常规场景；而当你面对严重的访问模式波动时，LRU-K（尤其是LRU-2）提供了一个更稳健的选择。

IT 累计浏览 3,165

TLS 握手优化详解

这篇讲的是随着HTTPS成为主流，如何优化TLS握手带来的性能开销。作者从TLS握手需要消耗两个RTT（往返时间）的痛点出发，详细拆解了False Start优化技术——它允许客户端在握手尚未完全结束时就提前发送加密的应用数据，从而将握手延迟从两个RTT压缩至一个。文章还深入分析了证书链的优化策略，指出证书过长或中间证书缺失会导致额外开销，并推荐了使用ECC证书来显著减小证书体积。通过Wireshark抓包图，文章直观展示了这些优化前后的对比效果。对于正在部署HTTPS的开发者来说，这些关于握手流程和证书配置的实践细节，能有效帮助他们在不牺牲安全性的前提下提升连接速度。

IT 累计浏览 3,312

线上PHP问题排查思路与实践

这篇文章来自一位资深工程师在技术大会上的分享，系统地梳理了线上PHP问题的排查方法论。作者从最让用户头疼的“裸奔错误页面”切入，指出工程师需要看到502错误背后PHP-FPM进程失效等深层原因。其核心思路是一个清晰的四步闭环：先恢复服务（通过摘机、回滚、重启或降级等手段），再保留现场（像警察保护案发现场一样记录日志与系统状态），接着排查问题（结合PHP内核、网络协议等知识和工具分析数据），最后验证结果。作者强调，恢复与保留往往同步进行，例如用gcore保存进程core文件后立即重启。文章还分享了三个来自不同层面的实战案例，包括用tcpdump排查MySQL TPS飙升、追查导致CPU100%的PHP进程，以及一个由echo引发的系统崩溃。文末附有PPT下载，可供深入研习这套从理论到实践的完整排查框架。

IT 累计浏览 4,087

运维不得不知的 Linux 性能监控、测试、优化工具

系统性能专家 Brendan Gregg 在 LinuxCon NA 2014 大会上，更新了他关于 Linux 性能分析的经典演讲。这篇介绍正是基于他分享的最新内容，旨在为运维人员梳理一套实用工具集。面对纷繁的 Linux 性能工具，Brendan Gregg 提出了一个朴素的观点：最好用的往往是那些久经考验、简单直接的小工具。文章的核心内容，就是三张清晰分类的工具全景图，分别对应性能工作的三个关键环节：监控、测试与优化。具体来说，文章通过三张图表系统性地覆盖了 Linux 各个子系统（如 CPU、内存、磁盘 I/O、网络）在不同场景下可选用的工具。第一张图聚焦于系统可观测性，列举了用于实时监控和诊断问题的工具；第二张图总结了进行性能基准测试与评估的工具；第三张图则归纳了用于系统调优与参数设置的工具。这种结构化的梳理，直接解决了“该用哪个工具”的常见困惑。这套工具的价值在于其历经实战检验，专注于解决具体问题。对于需要快速定位性能瓶颈或优化系统的运维人员而言，这相当于获得了一份经过专家认证的“工具菜单”，能帮助他们从眼花缭乱的选项中，高效地找到合适的武器。

IT 累计浏览 2,437

C++ 传参时传内置类型时用传值(pass by value)方式效率较高

这篇文章从《Effective C++》的经典条款出发，深入探讨了一个C++开发者常感困惑的问题：函数传参时，应该用传值（pass by value）还是传引用（pass by reference）？作者指出，这个选择并非一概而论，而是取决于参数的类型——文章特别对比了内置类型（如int、指针）与自定义类型之间的行为差异。为了验证这一结论，文章提供了清晰的代码示例和关键的汇编代码对比。核心发现在于：对于int这类内置类型，传值（`int f(int i)`）编译生成的x86汇编指令更简洁，参数直接通过寄存器传递，效率最高；而传常量引用（`int g(const int &i)`）则多了一次内存间接访问的步骤，尽管微小但在极热路径上可能产生影响。文章也点明了反向情况：当面对存在构造与析构开销的自定义类型时，传引用才能避免不必要的复制成本。此外，STL中的迭代器与函数对象本质上是指针，因此遵循内置类型的规则。作者通过这次代码级的验证，不仅重申了一个有效的实践准则，更通过底层视角加深了理解：效率的考量必须结合类型特性。这提醒我们，在追求代码“优雅”的同时，也不应忽视特定场景下符合硬件行为的朴素写法所带来的切实性能收益。

IT 累计浏览 3,004

10条影响CSS渲染速度的写法与建议

这篇文章聚焦于CSS的渲染性能，作者从日常编码中常见的写法入手，剖析了10种可能导致浏览器渲染变慢的习惯。文章开篇就直指通配符选择器`*`的滥用，它会遍历所有标签，是性能的一大隐患。接着，作者犀利地指出了IE滤镜（如实现灰色效果的`filter: gray`）的高资源消耗问题，并以汶川地震时大量网站变灰导致CPU飙升的实际案例佐证。此外，诸如过度使用绝对定位、背景图片平铺策略不当、CSS选择器路径过深等影响渲染链效率的写法，也都被一一拆解。对于每个问题，作者都提供了务实的替代方案，比如针对通配符，建议改为对常用标签（body, li等）单独重置；对于背景平铺，则建议将色彩少的图片制成尺寸稍大的GIF格式。文章强调，合理的布局和让属性通过继承传递，能从根本上优化渲染路径。这些经验之谈，源于作者在真实项目中遇到的性能瓶颈，为前端开发者提供了清晰的避坑指南。

IT 累计浏览 2,496

从千分位格式化谈JS性能优化

作者从最基础的数字千分位格式化需求出发，系统性地探索了六种JavaScript实现路径。从最开始循环操作数组和字符串，到利用正则表达式匹配末尾三位，再到最终利用前瞻断言的“一行代码”方案，文章层层递进地展示了不同算法思路的演进与权衡。真正的价值在于文末附上的性能测试数据。在对不同数量级的数字执行5000次操作后，结果清晰表明：基于字符串拼接和`slice`截取的方案（方法二与四）性能表现最佳；而看似简洁的分组合并法（方法五）耗时最高，揭示了正则表达式与字符串方法在不同场景下的性能成本差异。这篇文章不仅仅是提供几个代码片段，它示范了一种面对常见需求的优化思维：从直观解法到性能洞察，最终通过基准测试来验证假设。对于开发者而言，其核心启示在于——选择“最优”代码，往往需要基于具体场景和实测数据，而非仅凭直觉或代码简洁度。