beralee的世界

设置一个合适服务端系统的线程数又是一件事半功倍的事情。

最佳线程数的东西我是最近才从淘宝的一份ppt上看到的，这里总结一下：

前面说了怎样合理的找到系统的瓶颈，解决系统的问题，这时候系统应该比较健康了，如果还想要进一步压榨系统的性能，就必须从一些参数下手，而调整参数实在是一件事半功倍的事情。

JVM参数调优总的来讲主要分两个方面：1.代大小的调优 2.垃圾回收机制的调优。主要的调优方向也是两个：减少full gc次数，减少每次gc所使用的时间。

(更多…)

通过jprofiler可以比较容易的分析出当前系统有没有内存泄漏的情况，如果没有内存泄漏，系统正常运行，cpu使用率还是比较高，在这个情况下，就需要找出使用CPU比较高的代码来进行专门的优化。

(更多…)

前面说到几种代码问题导致cpu的us使用过高的情况，其中最不容易查找原因的就是内存泄漏问题了，而且内存泄漏导致的后果可能直接是程序挂掉无法使用，轻微的内存泄漏又往往需要很久的时间才会重现，而内存泄漏导致heap内存接近最大值时频繁gc又会导致cpu占用高。下面是我的一些分析内存泄漏的经验。
(更多…)

有了压测，我们就可以让系统高速运转起来了，这时候，系统的问题就会被放大，首先可以从CPU的使用上分析出一些东西。

cpu load:

cpu的load是由很多因素构成，其中最主要的因素是CPU自己维护的队列的长度，例如在1分钟里，CPU的队列里维持的任务量始终为1，这个时候CPU load就基本等于1，这个值越大，就意味着CPU越忙，系统的负载就越大，一般这个值不超过3是比较好的状态。

cpu 利用率：

cpu 利用率是CPU时间在用户进程，内核处理，空闲时间，io时间等的百分比，一般java应用比较关注的就是用户进程和内核处理两块的百分比，这两块在系统负载情况下执行的百分比在65%-70%和30%-35%比较好。
(更多…)

前面说了压力测试，对于开发人员来说要掌握loadrunner并不是特别的必要，自己写测试代码又不好统计分析，这时候可以用一些更简单更适合我们的测试工具，比如apache ab。

ab并不是一个单独的工具，他是apache服务器里的一个小工具，在apache安装目录的bin目录下面，就可以找到他了。它是一个命令行工具，使用起来非常容易，格式是 ab [options] [http://]hostname[:port]/path 其中options有不少选项，具体可以看一下官方文档 http://httpd.apache.org/docs/2.0/programs/ab.html
(更多…)

前面说了，要不要做一次彻底的软件优化还得分析一下，那我们来看看我们的系统现在是个什么情况吧。

首先，要对你的系统非常熟悉，至少是主要的功能模块，如果代码是自己写的，那就最好了，否则，面对一个陌生的系统，就很难下手了。

(更多…)

下周要分享这个话题，希望能比在以前公司做的更好一点，在这里先准备一下。

首先，性能优化意味着什么？
看个漫画先：

做性能优化之前必须要先掂量一下：
a.现在的系统处理能力不能满足需求
b.现在的系统处理能力有比较大的上升空间
c.花时间改进软件提升的性能比增加硬件划的来

如果你觉得上面三项都满足的话，那么就开始干吧！

当然，这几项不是一下子就能得到答案的，必须要经过分析和评估才能下结论，但可以肯定的一点就是，一次成功的系统性能优化，意味着省钱。

受此文启发： http://www.longtask.com/blog/?p=592

性能优化从身边做起。

首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。

开始：

eclipse.ini里加入打印gc情况的参数：

-XX:+PrintGCTimeStamps