共 69 篇相关文章
这篇讲的是作者如何将一个php应用的TPS从120稳定提升至810的实战过程。 文章开篇直面问题：系统TPS低下、响应慢、并发能力差。作者从应用代码入手，借助xhprof定位瓶颈，优化了如避免高频内核调用、用memcached缓存数据等细节。随后，思路扩展到整个服务栈的配置调优。 在php层面，通过禁用不必要的模块、重新编译、配置php-fpm等方式节约资源。Web服务器Nginx侧，则涉及worker进程数、epoll模型、keep-alive、gzip压缩及静态资源处理等关键配置。更深层的，作者对操作系统进行了“瘦身”：精简守护进程、调整文件描述符限制、优化磁盘挂载参数。 整个过程的转折点在于对内核参数的精细调整。通过sysctl优化TCP连接、缓冲区等设置后，系统不仅TPS达标，性能曲线也趋于稳定。作者总结道，提升TPS的核心在于缩短单个请求的响应时间，并可通过strace等工具分析，从减少上下文切换和系统调用入手，最终实现更少资源开销下的更高吞吐。
生产环境中Tomcat内存设置不当容易引发各类溢出错误，这篇文章就系统总结了三种常见情况及其解决思路。 最典型的是Java heap space堆溢出，通常发生在98%时间用于GC且可用堆不足2%时。在无内存泄露的前提下，通过调整-Xms和-Xmx参数（建议设为相同值，如1024m）可解决，但需注意其上限受操作系统数据模型、虚拟内存及物理内存限制。 其次是PermGen space永久保存区域溢出，多因加载过多Class信息（如Hibernate、Spring框架动态生成类）导致。解决办法是加大-XX:PermSize与-XX:MaxPermSize参数，并需注意它们与-Xmx的总和不能超过系统最大JVM堆支持（如1.5G）。 第三种较为特殊，是unable to create new native thread无法创建新线程，这与JVM和系统内存分配比例有关。文章深入分析了JVM占用内存过多时，操作系统可用内存不足以创建更多物理线程的原理，并给出了线程数估算公式。此类问题需要同时调整操作系统与JVM参数。 作者从实际遇到的问题出发，不仅列出参数调整方案，还通过测试数据（如32位系统下堆大小限制）和原理分析（如线程创建机制）来支撑结论，强调需要根据不同溢出类型进行针对性诊断才能治本。
这篇讲的是Linux系统监控的必备工具top，如何通过一些关键技巧，从基础的实时观察者，变成强大的自动化诊断助手。作者从多数人仅用top进行交互式监控的现状出发，点明其局限——输出不便用于脚本分析。 文章核心聚焦两个实用技巧。首先是批处理模式（`top -b`），结合`-n`参数，能实现单次或定时输出。这解决了交互模式难以对接后续处理的痛点，特别适合与`at`或`cron`结合，在预定时间自动抓取系统状态快照，比如为性能回溯提供数据。其次，文章详细拆解了如何精准监控制定目标。通过`-p`指定PID，或使用`-u`/`-U`按用户过滤。这里点明了一个易被忽略的细节：`-u`仅匹配有效用户ID，而`-U`会搜索包括真实ID、保存ID在内的更多类型，让过滤更灵活。 这些技巧让top从“看一看”工具，升级为可编程、可定制的观测站，尤其适合需要长期监控或自动化运维的场景。
这篇文章从工程师的成长路径出发，探讨了软件架构设计中两个相辅相成但思维模式迥异的层面。作者指出，许多工程师从解决排序算法效率、提升代码可读性这类“微观架构”问题起步，这些成果直观且易于度量。然而，随着系统规模扩大，“宏观架构”——即关乎全局效率与成本的顶层策略设计——的价值便凸显出来。 文中用一个形象的对比阐释了这种思维转换：追求缓存命中率最大化是微观视角，而从全局出发，接受长尾数据的访问延迟，可能使整体成本下降一个数量级且性能影响甚微。作者进一步分析，从专注细节的微观思维转向宏观架构时，成果往往不如提升单个模块QPS那样立竿见影，更像是一种“虚”但至关重要的战略能力。 文章的核心观点在于，微观与宏观如同战术与战略，缺一不可。优秀的工程师团队需要合理的微观与宏观人员配比，架构师也需具备对代码细节的理解，才能做出正确的技术判断。文末列举的如C10k问题、SPDY协议、事件模型等断言，也邀请读者一起实践这种从微观细节到宏观影响的思考视角。
这篇讲的是进程上下文切换如何成为性能杀手的实测篇。作者从自己开源的并发网络库chaos中选取task_service模块，通过编译宏控制，对比了pthread条件变量、sleep、pipe、socketpair、eventfd以及boost::io_service这几种线程间通信机制的实际表现。 测试数据清晰展示了不同机制的CS/s（每秒上下文切换次数）和整体耗时：pthread条件变量切换高达60万次且最慢，而eventfd的切换次数低至200次，效率遥遥领先。有趣的是，boost::io_service的CS也高达75万次，但整体效率却比pthread模型更好，作者推测这与其内部高效的队列实现有关。 结论很直接：上下文切换次数与程序运行效率基本呈反比，减少CS是优化后台服务性能时必须考量的关键因素。文章用硬核的实测数据说话，为开发者选择并发模型提供了切实参考。
这篇讲的是阿里核心系统数据库团队如何从零打造一个名为UMP的MySQL云服务平台，来同时解决大规模MySQL集群面临的成本与性能难题。 背景是淘宝这样的企业有数千台MySQL服务器，直接扩展成本高昂。他们的UMP系统目标很明确：让开发者能方便地申请和使用资源，而由平台透明地处理主从热备、读写分离、分库分表等复杂运维工作。核心方案是在一台物理机上运行多个MySQL实例以降低成本，并实现资源的弹性隔离与分配。 他们最初的方案基于MySQL-Proxy，但很快发现了它的多线程模型缺陷、功能扩展困难以及社区不活跃等问题。于是，团队果断选择用Erlang语言重写了整个Proxy层。Erlang轻量级的“绿进程”和OTP框架，为他们提供了高并发、高容错且易于热部署的编程模型，完美契合了云服务的需求。 最终的UMP系统架构包含Controller、Proxy、Agent等多个角色，通过RabbitMQ和ZooKeeper协同工作，构成了一个完整的、可伸缩的云数据库服务。文中还透露，这个系统已经在天猫聚石塔等平台落地，为电商业务提供着安全可靠的数据云服务。
这篇文章是国外知名性能专家 Steve Souders 的一次系统梳理。他从自己在 WebPerfDays London 的实践出发，为我们带来了一份详尽的网站性能优化（WPO）工具清单。 摘要内容：这篇文章是国外知名性能专家 Steve Souders 的一次系统梳理。他从自己在 WebPerfDays London 的实践出发，为我们带来了一份详尽的网站性能优化（WPO）工具清单。从浏览器内置的审计面板、到专业的第三方测速平台、再到本地化的脚本运行与监控工具，这份清单覆盖了前端性能分析的完整链路。对于开发者而言，性能优化不再是一个模糊的概念，而是可以通过具体工具量化、诊断和改善的过程。Steve Souders 帮助大家建立了一个从发现问题到验证效果的工具箱，让“让网站更快”这件事变得路径清晰。无论你是刚开始关注性能的开发者，还是寻求进阶的工程师，这份源自一线专家的工具指南都能为你的优化工作提供切实的抓手。
这篇讲的是团队如何用星际争霸2的编辑器来解决怪物AI配置的老问题。传统做法是策划写需求文档，再交给程序去改代码，流程长还容易出错。作者接手这个模块后，发现编辑器自带的触发器系统其实是个现成的解决方案——它支持用“如果-那么”的逻辑来定义行为，并且所有参数都能在界面里直接修改。 通过搭建一套基于触发器的AI框架，策划可以直接在编辑器里调整怪物的巡逻路线、攻击逻辑和技能释放条件，改完就能实时看到效果，不用再走提需求、等排期、测版本的漫长循环。这相当于把原本硬编码在程序里的行为“翻译”成了策划能看懂、能操作的数据配置。 这种做法的核心是把编辑器从单纯的关卡工具，变成了支持数据驱动的AI开发平台。虽然最初只是为了解决沟通效率问题，但最终让团队获得了快速迭代AI设计的能力——策划可以当场尝试不同的行为组合，测试反馈的周期从几天缩短到了几分钟。对于同样受困于工具链割裂的团队来说，这种“用现有工具挖掘隐藏功能”的思路，或许比从头自研一套编辑器更有实操参考价值。
这篇文章重申了在 PHP 开发中一个常见的争议点：**“不要使用 `include_once` 或 `require_once`”**。 作者从 PHP 一个历史悠久的扩展配置项 `apc.include_once_override` 的去留讨论切入，指出这个旨在优化 `_once` 函数性能的 APC 配置，长期以来都未能被完美实现，本身就反映了这类函数带来的复杂性和性能开销问题。 文章的核心观点在于，依赖 `_once` 变体虽然方便（无需手动去重），但它迫使 PHP 引擎在每次文件引入时都进行额外的“文件是否已引入”的检查与记录，这本质上是一种性能损耗。作者认为，在绝大多数场景下，通过清晰的代码结构和依赖管理（例如使用命名空间、自动加载或显式管理文件引入顺序）来确保文件不会被重复加载，是比依赖引擎去重更高效、更可控的做法。文章建议开发者重新审视自己的代码习惯，优先考虑使用普通的 `include` 或 `require`。
这篇讲的是一次针对移动端网页卡顿问题的“响应性开发”改造实践。 作者从移动端 H5 页面在低端安卓机上滚动卡顿、交互延迟的痛点出发，没有选择大刀阔斧地重写，而是采取了更为精准的“响应性”策略。核心思路是利用浏览器空闲时段异步执行低优先级任务（如日志上报、非关键数据预加载），并将主线程上的长任务拆分为多个可中断的小任务，从而为用户的触摸、滑动等关键交互让出资源。 实践表明，这种改造显著提升了页面的流畅度与可交互性。文章不仅分享了如何通过 `requestIdleCallback` 和任务分割的具体实现，更重要的是传递了一种优化理念：性能优化未必是彻底的架构革新，有时通过精巧的资源调度与任务编排，也能在不动用重型武器的前提下，为用户换取切实的流畅体验。
这篇通过三幅有趣的图，探讨了负载均衡算法在实际应用中需要改进的问题。作者从分布式系统的常见痛点出发，用
这篇讲的是作者从一个关于数组内部链表的内存池技术题目出发，对CPU cache，特别是cache line，进行的探索和测试。文章首先点明了这种数据结构的优势——通过保持地址连续来提升缓存命中率，非常直观。 作者指出，对程序员来说，CPU高速缓存本是一个透明部件，我们通常无法直接干预其操作。但正因了解其工作特点，我们可以通过特定的代码优化，让程序更好地利用它。 文章的核心价值在于，作者并未止步于理论。他深入到多核环境下，对cache line进行了实际的测试与分析。这为理解在复杂硬件场景下，数据如何影响缓存行为提供了第一手的观察。 通过这次从实际问题到硬件原理的挖掘，作者将抽象的缓存概念落地，展示了如何从日常编程细节中洞察底层性能的关键。
这篇讲的是前端项目中性能优化的实战经验。作者从一次真实的项目重构出发，分享了针对页面加载速度和交互响应这两个核心痛点的具体优化方案。文中详细拆解了如何通过代码分割与动态导入减少初始包体积，并利用懒加载策略优化长列表的渲染性能。一个值得注意的数据是，经过这套组合优化后，项目在弱网环境下的首屏加载时间缩短了约40%，列表滚动时的卡顿感也明显改善。文章没有停留在理论层面，而是给出了可复用的优化策略和踩坑记录，比如如何平衡分割粒度与请求瀑布流问题。这些来自生产环境的一手经验，对正在处理类似性能瓶颈的前端开发者有直接的参考价值。
这篇讲的是一个由微博讨论引发的技术争论：频繁使用的CSS雪碧图，到底会不会“吃”掉大量内存？ 文章作者没有停留在理论争执，而是通过具体的浏览器内存监控工具，对典型的雪碧图使用场景进行了实测。结果发现，无论是在PC还是移动端，合理的雪碧图应用并不会导致内存占用出现所谓的“暴涨”。内存增长主要与图片本身的尺寸和解码后的数据量有关，与使用单张小图相比，将它们合并为一张雪碧图并不会产生额外的内存负担。 文章进一步解释了背后的原因：浏览器在加载雪碧图时，是将其作为一张完整的位图进行解码和存储的，其内存占用基本等同于所有碎片图片内存之和，而非简单累加。因此，开发者完全可以继续利用雪碧图来减少HTTP请求、提升加载性能，而无需担忧内存问题。这篇文章用实测数据澄清了一个常见的误解，让优化方案的取舍更加清晰。
这篇讲的是CPU缓存如何直接影响Java程序性能。作者从一个基本事实出发：现代计算机中，CPU访问内存需要约200个时钟周期，而访问L1缓存仅需3-4周期。为了弥合这一鸿沟，硬件设计了L1、L2、L3多级缓存，形成了一个金字塔式的存储结构。 文章通过一个精心设计的Java实验，直观揭示了缓存行（通常为64字节）的关键作用。实验对一个二维long型数组进行遍历：一种是按行顺序访问，另一种是按列交错访问。结果令人震惊——顺序遍历耗时约1.4秒，而交错遍历则飙升至22秒，性能相差超过15倍。作者用`perf`工具进一步验证，后者的L1数据缓存未命中次数远高于前者。 根源在于数组的内存布局与缓存行机制。顺序访问时，加载一个元素会将其所在缓存行的相邻元素也一并载入，后续访问能高效命中缓存。而随机跳跃的访问模式会导致频繁的缓存行失效，迫使CPU不断从更慢的内存中获取数据。这提醒Java开发者，虽然JVM屏蔽了底层细节，但编写数据结构密集、对性能敏感的代码时，理解CPU缓存的工作原理，遵循“空间局部性”原则组织数据访问，能带来显著的性能收益。
这篇讲的是Linux内核在高压场景下，如何通过一系列调优来提升性能。作者从一次线上服务的CPU使用率波动事件切入，发现常规的监控工具难以准确定位瓶颈。随后，文章详细拆解了针对进程调度（CFS）、内存回收（kswapd）以及网络协议栈（TCP）的几项关键调整，例如通过修改sysctl参数来减少锁竞争、调整内核预读窗口优化磁盘I/O，并给出了优化前后的部分数据对比。 有趣的是，作者在文末坦率地附上了发布后收到的微博质疑链接。这场讨论的核心在于，部分优化参数的修改是否具有普适性，以及在生产环境中直接应用的潜在风险。文章与其说是一份“标准答案”，不如说是一次公开的实践复盘，它展现了理论调优与现实生产环境复杂性的碰撞。 对于读者而言，这篇文章的价值不仅在于提供了几条具体的排查思路和可试的调优选项，更在于它示范了如何面对技术方案的争议——将结论交由社区审视，在讨论中修正认知，这本身也是技术迭代的一部分。
作者完成了一个MySQL性能挑战：在单表插入场景下实现10万+的TPS（每秒事务数）。对于熟悉数据库优化的读者来说，这通常是一个需要多方面调优才能接近的指标。 这篇文章记录的正是达成这一结果的实践过程。虽然正文以一句“装B留念”轻松带过，但标题本身传递了明确的技术成果和挑战性。作者很可能深入调整了包括硬件配置、MySQL参数、事务提交模式、甚至存储引擎选项在内的多个环节，才最终将单表顺序插入的吞吐量推高到了这个水平。 这种级别的性能数据，对于设计高写入负载系统（如日志收集、时序数据、高并发交易记录）的架构选型和容量规划具有直接的参考价值。它展示了MySQL在特定写入模式下的性能天花板，并隐含了作者在实战中踩坑和优化的经验。
这篇文章聚焦于高并发系统中一个经典的性能瓶颈：锁竞争。作者从传统锁机制在极端并发下可能引发的严重性能问题出发，深入剖析了为何在用户态实现并优化自旋锁能成为一种有效的解决方案。 文章的核心是提出了一种改进的用户态自旋锁设计。它探讨了传统锁（可能涉及内核态切换）的开销，并详细阐述了在用户空间通过特定算法（如自适应自旋、结合无锁思想或对锁持有状态的精细判断）来实现更高效锁的思路。这个方案旨在避免或减少代价高昂的系统调用与上下文切换。 通过这种设计，文章展示的目标是在多核处理器、高竞争场景下，能够显著降低锁操作的延迟，并提升系统的整体吞吐量。这种对底层同步原语的极致优化，对于追求低延迟、高吞吐量的服务端开发具有直接的参考价值。
这篇讲的是 MySQL 数据库性能优化系列的第三部分，作者将焦点从索引转向了 SQL 语句本身。文章指出，即便索引设计得当，不合理的查询写法同样会拖垮性能，因此 SQL 优化是整个调优链条中至关重要的一环。 作者从 SQL 执行的常见瓶颈出发，系统梳理了多个关键的优化方向。比如，如何避免导致全表扫描的写法，怎样利用执行计划（EXPLAIN）来分析和重写低效查询，以及在复杂的关联查询和子查询中需要注意哪些陷阱。文章并非空谈理论，而是通过具体的代码示例，对比了优化前后的写法差异，并解释了其背后的执行逻辑变化。 最终，文章强调了 SQL 优化的核心目的：让数据库引擎能以最高效、最精准的方式获取数据，从而在索引优化的基础上，进一步释放查询性能的潜力。对于日常编写和维护数据库应用的开发者来说，这些实践建议能直接帮助减少不必要的负载和延迟。
这篇讲的是 MySQL 线程处理模式的一次重要演进。作者从 MySQL 5.5.16 版本将 Thread Pool 作为官方插件支持切入，梳理了此前两种常见的线程处理模式：一种是主要用于调试的 `no-threads` 单线程模式，另一种是默认的 `one-thread-per-connection` 模式——即为每一个客户端连接分配一个独立线程。 文章核心对比了这几种模式的关键差异。老模式在连接数剧增时，会因创建和销毁大量线程而产生显著的性能开销与资源消耗，成为高并发场景下的瓶颈。而官方引入的 Thread Pool 模式，本质上是通过一个线程池来集中管理和复用线程，用有限的线程处理大量的并发请求，从而降低系统开销，提升服务器的资源利用效率和稳定性。 作者通过这段演变说明，Thread Pool 的引入正是为了解决 `one-thread-per-connection` 在大规模并发下力不从心的背景问题。其核心方案是将线程处理模式设置为 `dynamically-loaded`，以插件形式加载线程池功能，为应对高负载生产环境提供了一种更优的架构选择。
