wang_quan_li的专栏

一、 Yahoo的军规条例：谨记：80%-90%的终端响应时间是花费在下载页面中的图片，样式表，脚本，flash等；详细的解释来这里查：http://developer.yahoo.com/performance/rules.html也可以直接firebug上一项项比对，如下图：简单翻译解释下：1、尽量减少HTTP请求个数——须权衡合并图片（如css sprites，内

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded问题的解决办法.一、异常如下：Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded二、产生原因：意味着太多的时间花在了垃圾收集上面,SUN的建议是指定垃圾回收的算法，加上启动参

JVM 调优，首先应从内存开始，尤其是在真正的的web服务部署的时候。因为真正的web服务会比开发的时候花费更多的内存，用来处理多用户并发的情况。本人多次吃过这方面的亏，所以整理一下，希望能给别人以帮助。这个年头变啦，内存变得如大白菜，每个新装的机器都2G以上的内存，甚至4G，也不是什么新闻。而软件‘吃’内存的情况则变化不大（除了VIsta）。但 JAVA诞生的时候可不是这样——95年

php-fpm 进程池优化方法php-fpm进程池开启进程有两种方式，一种是static，直接开启指定数量的php-fpm进程，不再增加或者减少；另一种则是dynamic，开始时开启一定数量的php-fpm进程，当请求量变大时，动态的增加php-fpm进程数到上限，当空闲时自动释放空闲的进程数到一个下限。这两种不同的执行方式，可以根据服务器的实际需求来进行调整。要用到的一些

前段时间接到某项目中关于虚拟机所在宿主机上最大支撑连接数的测试需求。应用场景类似于在物理机上运行着多个虚拟机，这些虚拟机对外提供服务，来自于任何地方的客户端都可能向这些应用服务发起连接和请求。也许单个虚拟机并发的连接数十分有限，但对提供虚拟机服务的物理机或宿主机来说连接数就可能达到十万、几十万甚至百万。在这样的情况下，宿主机是否能够稳定运行呢？同时项目方也提出了明确的测试目标，支撑300万连接，这

某产品每次重启Tomcat都会收到CPU告警信息，重启阶段CPU使用率可以达到80%~90%以上，会持续一段时间回降（具体时间没有考察）。应产品方要求，对该问题进行分析定位。因线上产品不能随便重启，问题定位阶段使用的是同规格的云主机QA19，该环境上有和线上一致的应用程序，且重启tomcat时，也会有CPU飙高的现象。负载高的原因：重启的时候对资源使用情况进行监控，并通过top -H

Perf 是一款随 Linux 内核代码一同发布和维护的性能诊断工具，由内核社区维护和发展。Perf 不仅可以用于应用程序的性能统计分析，也可以应用于内核代码的性能统计和分析。它不但可以分析指定应用程序的性能问题 (per thread)，也可以用来分析内核的性能问题，当然也可以同时分析应用代码和内核，从而全面理解应用程序中的性能瓶颈。在此对Perf工具的使用做一下简单介绍，方便对程序性能

定位性能问题，尤其是cpu使用率过高时，经常需要查找cpu消耗较高的线程，然后查看其堆栈，从而进入代码定位问题。该场景下， jstack+top是一种非常经典的方式。jstack+topjstack+top的一般套路：1、top -H 查看cpu占用较高的线程，记录十进制的线程id2、jstack  将线程信息dump到文件中，在文件中根据线程id查找该线程的堆栈。

Keep-Alive即俗称的长连接，使客户端到服务端建立的连接持续有效，当对服务器发起后续请求时，Keep-Alive功能可以复用先前使用过的连接，减少了重新建立连接所需的开销。通常使用HTTP协议采用的是请求应答模式，客户端到服务端的一次请求完成了，它们之间的连接也随之关闭。在某些应用场景下，比如后端RESTful服务，就需要保持住连接，这时就可以启用HTTP Keep-Alive。下图就是

测试中发现某接口响应时间超过1S,观察到数据库服务器 CPU 使用率飙到 80% 以上。Profile 响应时间主要消耗在 SQL 语句的执行上,定位原因是检索字段没有加索引。数据库索引可以帮助我们大大的加快数据的检索速度。当符合以下情况时建议增加索引:• 数据库表比较大时;• 需要全表扫描查询时;• 取出的数据量比表数据量少很多时;    索引会增加额外的存储空间,并且在

nginx + tomcat 架构的 Web 服务中,用户感觉响应很慢,如何排查呢?可以第一时间查看 nginx 的 access.log。log_format 中定义了 $request_time 字段,它指的是从接受用户请求数据到发送完回复数据的时间。那究竟是慢在了 nginx、tomcat 还是其它?log_format 同 时 提 供 了 $upstream_response_ti

当 后 端 服 务 器 的 响 应 body 大 于proxy_temp_file_write_size,响应会被缓冲到 proxy_temp_path 目录下的临时文件中;当 客 户 端 的 请 求 body 大 于 client_body_buffer_size, 请 求 会 缓 存 到 client_body_temp_path 目录下的临时文件中。因此当nginx 处理大数据量的请求或响应

网站如果有很多用户上传图片(相册，商品图片)，一般的做法是将用户图片保存在磁盘上面(数据库中记录图片的地址)。用户上传的时候按照原图、中图、小图等各个尺寸都生成一份保存在磁盘上。比如php的网店系统echsop就是这么做的，而shopex之类也大同小异。 这种做法也不是不可以。多生成几个尺寸，在磁盘上无非多存储几份而已，磁盘现在也便宜。 不过，有个问题：运营部经常需

原则一：流量隔离原则二：灾备切换原则三：水平扩展-分流原则四：超预期流量-限流原则五：保护系统-降级原则六：提高性能-读写分离原则七：唯快不破-异步化原则八：动态，静态流量分离原则九：线上压力测试-发现瓶颈原则十：预案

一，SQL语句性能优化1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默  认值。3，应尽量避免在 where 子句中使用!=或，>=，BETWEEN，I

1. 没必要去优化页面模板，这都是一些很成熟的技术，就算你好不容易提升了10%的性能，这10%在整个页面的执行过程中只占了0.5%的比例，微乎其微，等于是前面例子中的4车道变8车道的傻瓜，我们不要去充当傻瓜。2，数据库连接：使用连接池来减少连接次数；重复的数据库查询：使用缓存来避免重复的数据库查询；慢查询：使用索引来提升查询速度，使用连接查询替换子查询等。3，静态文件和动态页面分开处理，应

写在前面的话：总是在灾难发生后，才想起容灾的重要性；总是在吃过亏后，才记得曾经有人提醒过。（一）核心军规（1）不在数据库做运算cpu计算务必移至业务层；（2）控制单表数据量int型不超过1000w，含char则不超过500w；合理分表；限制单库表数量在300以内；（3）控制列数量字段少而精，字段数建议在20以内；（4）平衡范式与冗余效率优先；

关于论坛数据库的设计文章分类:数据库一个简单的论坛系统1：包含下列信息： 2：每天论坛访问量300万左右，更新帖子10万左右。请给出数据库表结构设计，并结合范式简要说明设计思路。一. 发帖主题和回复信息存放在一张表，并在这个表中增加user_name字段 对数据库的操作而言，检索数据的性能基本不会对数据造成很大的影响（精确查找的情况下），而对表与表之间的连接却会产生巨大

1 性能的关键指标2 服务化系统构成模式请求对系统资源的占用2.1 基础服务2.2 集成服务2.3 混合服务混合服务的资源消耗2.4 系统资源消耗3 常见系统优化tips3.1 代码调优3.2 数据库调优References这篇文章是在