ocean

Apache Mysql 的优化

9 月 172010

搞了两天,综合网上优秀BLOG并且联系实际整理了下 Apache Mysql 的优化,虽然不一定适合每一个人,但里面的一些参数自己可以自己琢磨测试.不过Apache感觉不怎么样,爷爷的 15分钟在线 2000多IP就卡得不得了,每天90多W PV 都卡,看了下163他们的网络架构,不管是前端还是源段服务器都全是NGINX,看样子以后还得继续努力学习了,

Apache优化

KeepAlive On

KeepAliveTimeout 10

    StartServers          5
    MinSpareServers       10
    MaxSpareServers      20
    ServerLimit          1000
    MaxClients          1000
    MaxRequestsPerChild   10000

主要优化这几个参数,在服务器完全可以承受访问量的时候建议把KeepAlive设置为 on,但网上很多人设置了on但是KeepAliveTime设置为 3-5秒,我认为这样设置根本就没有效果,还不如KeepAlive设置为off,打开一个网页算快也要2秒,人家不可能看3秒又去打开新页面,所以这样设置个人觉得不科学,至少也要10秒,建议使用默认的15秒,如果服务器压力太大可以尝试KeepAlive设置off,以减少一些无效连接,

并发计算参考公式： Continue reading »

如何对MySQL服务器进行调优

LAMP 没有评论 »

9 月 172010

变量名说明 Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而得到一个空闲块。 Qcache_free_memory 缓存中的空闲内存。 Qcache_hits 每次查询在缓存中命中时就增大。

Qcache_inserts 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。 Qcache_lowmem_prunes 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况）。 Qcache_not_cached 不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句。 Qcache_queries_in_cache 当前缓存的查询（和响应）的数量。 Qcache_total_blocks 缓存中块的数量。

通常，间隔几秒显示这些变量就可以看出区别，这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS 可以重置一些计数器，如果服务器已经运行了一段时间，这会非常有帮助。

使用非常大的查询缓存，期望可以缓存所有东西，这种想法非常诱人。由于 mysqld 必须要对缓存进行维护，例如当内存变得很低时执行剪除，因此服务器可能会在试图管理缓存时而陷入困境。作为一条规则，如果 FLUSH QUERY CACHE 占用了很长时间，那就说明缓存太大了。 Continue reading »

Apache 2.0性能优化—MPM的选择与配置

LAMP 没有评论 »

9 月 172010

Apache 2.0在性能上的改善最吸引人。在支持POSIX线程的Unix系统上，Apache可以通过不同的MPM运行在一种多进程与多线程相混合的模式下，增强部分配置的可扩充性能。相比于Apache 1.3，2.0版本做了大量的优化来提升处理能力和可伸缩性，并且大多数改进在默认状态下即可生效。但是在编译和运行时刻，2.0也有许多可以显著提高性能的选择。本文不想叙述那些以功能换取速度的指令，如HostnameLookups等，而只是说明在2.0中影响性能的最核心特性：MPM（Multi -Processing Modules，多道处理模块）的基本工作原理和配置指令。

　　毫不夸张地说，MPM的引入是Apache 2.0最重要的变化。大家知道，Apache是基于模块化的设计，而Apache 2.0更扩展了模块化设计到Web服务器的最基本功能。服务器装载了一种多道处理模块，负责绑定本机网络端口、接受请求，并调度子进程来处理请求。扩展模块化设计有两个重要好处： Continue reading »

Memcached深度分析

LAMP 没有评论 »

9 月 172010

Memcached是danga.com（运营LiveJournal的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性能。关于这个东西，相信很多人都用过，本文意在通过对memcached的实现及代码分析，获得对这个出色的开源软件更深入的了解，并可以根据我们的需要对其进行更进一步的优化。末了将通过对BSM_Memcache扩展的分析，加深对memcached的使用方式理解。

本文的部分内容可能需要比较好的数学基础作为辅助。

◎Memcached是什么

在阐述这个问题之前，我们首先要清楚它“不是什么”。很多人把它当作和SharedMemory那种形式的存储载体来使用，虽然memcached使用了同样的“Key=>Value”方式组织数据，但是它和共享内存、APC等本地缓存有非常大的区别。Memcached是分布式的，也就是说它不是本地的。它基于网络连接（当然它也可以使用localhost）方式完成服务，本身它是一个独立于应用的程序或守护进程（Daemon方式）。

Memcached 使用libevent库实现网络连接服务，理论上可以处理无限多的连接，但是它和Apache不同，它更多的时候是面向稳定的持续连接的，所以它实际的并发能力是有限制的。在保守情况下memcached的最大同时连接数为200，这和Linux线程能力有关系，这个数值是可以调整的。关于 libevent可以参考相关文档。 Memcached内存使用方式也和APC不同。APC是基于共享内存和MMAP的，memcachd有自己的内存分配算法和管理方式，它和共享内存没有关系，也没有共享内存的限制，通常情况下，每个memcached进程可以管理2GB的内存空间，如果需要更多的空间，可以增加进程数。

◎Memcached适合什么场合

在很多时候，memcached都被滥用了，这当然少不了对它的抱怨。我经常在论坛上看见有人发贴，类似于“如何提高效率”，回复是“用memcached”，至于怎么用，用在哪里，用来干什么一句没有。memcached不是万能的，它也不是适用在所有场合。

Memcached 是“分布式”的内存对象缓存系统，那么就是说，那些不需要“分布”的，不需要共享的，或者干脆规模小到只有一台服务器的应用，memcached不会带来任何好处，相反还会拖慢系统效率，因为网络连接同样需要资源，即使是UNIX本地连接也一样。在我之前的测试数据中显示，memcached本地读写速度要比直接PHP内存数组慢几十倍，而APC、共享内存方式都和直接数组差不多。可见，如果只是本地级缓存，使用memcached是非常不划算的。 Continue reading »

LAMP网站建设之性能优化篇

LAMP 没有评论 »

9 月 172010

开源的LAMP (linux/Apache/Mysql/PHP) 平台是流行的web application platform,不少网站,包括海归网都是建立在此平台上.

在帮助海归网正式转移到LAMP平台之前, 笔者虽然长期做网站设计和开发方面的工作,但主要是在J2EE 或者 ASP.NET /ASP方面的应用, 具体是在application 层面, 架构设计主要考虑功能/可扩充性和scalability, 而网站反应速度/性能方面一般不是问题–或者流量不大,或者硬件架构足够强(hardware load balancer, cluster, dedicated web/middle tier/DB tier/team等). 在海归网, 让我有机会在LAMP环境下接触和学习到许多以前做应用或自己玩操作系统时难以接触到的问题– 除了系统和网络管理外, 有许多是关于性能优化和scalability方面的.

在这篇里分享一点积攒的LAMP环境下PHP网站的性能优化经验. (谢谢老狼和海归网提供的给我一个发挥点业余爱好的机会); 以后有时间谈谈scalability/availability等.

有许多中小网站都和海归网一样只有一台服务器(海归网有一台dedictaed的dell, 更多更差的网站shared hosting的则是几十几百个网站公用一台server), 而这台服务器需要身兼web server, application server,database server, firewall等等所有一切功能…在网站建设的初期只能在有限的硬件条件下最大限度地进行优化充分利用所有的资源保证基本的功能/性能和稳定性.

1. 编译php/apache/mysql 时的优化选项

一般来说, 用不着自己编译这些东西,直接下载binary packages就可以了–无论是debian 的apt-get 还是redhat的rpm /yum. 但是这些现成的安装包编译时一般并未根据你的服务器硬件配置做优化, 而通过选择合适的C编译器 flags 和其他选项,自己编译往往能使总体性能提高几个到几十个百分点. Continue reading »

可耻汉奸：抗战时中共军队投日干部档案曝光

杂事杂谈没有评论 »

9 月 162010

下面这些败类都是团以上的军事干部，不包括投敌叛国的党政要员。

　　1，朱镇，东北抗日联军第2军独立师师长，1934年率部投日。
　　2，罗英，东北抗日联军第4军政治部主任，1936年2月率部投日。
　　3，兰志渊，东北抗日联军第3军2师师长，1937年1月率部投日。
　　4，胡国臣，东北抗日联军第1军军需部长，1937年12月21日率部投日。
　　5，安光勋，东北抗日联军第1军参谋长，1938年2月13日率部投日。
　　6，张绍东，八路军115师344旅687团团长，1938年2月25日在晋东南的皋落镇投敌。
　　7，兰国清，八路军115师344旅687团参谋长，1938年2月25日在晋东南的皋落镇投敌。
　　8，高世魁，东北抗日联军第3军10师师长，1938年4月率部投日。
　　9，秦秀全，东北抗日联军第8军1师师长，1938年5月率部投日。
　　10，王振祥，东北抗日联军第9军2师师长，1938年5月率部投日。
　　11，陈云升，东北抗日联军第3军4师师长，1938年夏率部投日。
　　12，赵庆珍，东北抗日联军第8军6师师长，1938年6月率部投日。
　　13，程斌，东北抗日联军第1军第1师师长，1938年6月29日率部集体投日。 Continue reading »

Comsenz的7个短视之处

网络学院没有评论 »

9 月 162010

1.顽固坚持php4，迟迟不愿拥抱php5

其实这是我最不能理解的一点，Discuz现在的代码竟然还是以php4.3.0为最低标准的。

这种做法虽然说可以做到最大限度的兼容，php4的运行效率也确实比php5高不少。可是为了向下兼容，不得不牺牲很多高版本php的优秀特性。事实上，php5已经在各方面非常完善，面向对象方面的支持全面提升，PDO， json等类和函数相比php4强大太多了。

在CPU并行性能空前强大，内核数量4个8个12个递增的今天，php运行效率真的有那么重要吗？要知道现在web2.0网站的第一瓶颈是数据库服务器，而不是php服务器，即使php服务器压力较大，也有反向代理、动态DNS等各种各样简单有效的负载均衡方法解决。真的有必要为了些许的php运行效率，而放弃高版本php的强大功能吗？

2.代码架构混乱，不采用MVC框架，不面向对象

说实话，写了12年程序，Discuz代码我是下了十几次决心才敢开始阅读的。因为这套代码实在非常丑陋。

和我一起创业的同伴一直和我有一个争论，他坚持认为discuz发布出来的代码一定是生成出来的，内部开发的时候一定是另外一种结构。因为他认为discuz代码的可读性已经远远超过了正常人理解能力。

虽然康盛一直试图改进代码结构，在最新的Discuz！X中，我们看到他整齐的把function， class， plugins放在各自的目录里，但由于它不采用php5，也不采用MVC框架，因此代码中仍然充斥着global， require_once等等，和系统底层紧耦合且效率低下的糟糕写法。

由于没有运用MVC框架，也不面向对象，导致了插件机制难以实现，二次开发举步维艰。其实这对Comsenz自己开发团队成员，也造成了单元测试的困难。

3.缺乏国际化的眼光，偏爱gbk而不选择utf8 Continue reading »

Discuz!X的研究和质疑

网络学院没有评论 »

9 月 162010

3月28日，戴志康释出了传说以久的内部代号为UltraX的体验版。大概是希望借用discuz已有的巨大号召力，UltraX在发布之前还是改成了discuz!X。

我在第一时间去discuz.org注册体验了一下，体验感受和我之前预计的相差无几，整理一下写出来，大家讨论：
SNS、门户、论坛互相冲突

X项目的最本质目的，应该是把Comsenz旗下的三大项目：Discuz、SuperSite和UCenter Home进行融合，减小项目和项目之间的隔阂，使之能更好地融合成为一个网站。

这一定是广大站长向Comsenz反应的一个共同心声。可是，站长们真的明白自己需要什么吗？融合了之后真的能让网站更好吗？Comsenz在大刀阔斧之前想清楚了吗？

一般来说，网站的内容质量从高到低可以分成三个档次：

   1. 媒体型，内容质量很高，有高水平的，固定成员的编辑团队。访问者到网站来大多数为了看内容，用户群结构上是一群读者围绕着一个牛人。这种类型适合建CMS型站点或者是博客。
   2. 草根型，虽然没有明确的编辑团队，但是大部分用户都有创造内的能力，用户有时候会创造内容，有时候也会阅读评论内容。内容水平虽然够不上出版，但还不错，有信息量有价值，以垂直主题为核心。这种类型适合BBS形式。
   3. 灌水聊天型，用户的文化程度不高，讨论漫无边际，并且常会出现小圈子，用户和用户之间通过人际关系维系。这种用户类型适合建SNS站点。

不管是网站的哪一个板块，都大抵是同一批人在访问。同一批访客，就有相似的需求，具有相似的特性。基本上，个人站点都只能属于上述三种情况之一，而很少会出现媒体型和灌水型混合的情况。 Continue reading »