说说Wordpress和Drupal

上次就想把Wordpress和Drupal做一个对比，这次补上。 Wordpress和Drupal都是目前比较流行的开源CMS，用户数量也比较多。以下将从比较常用的几个方面进行比较。 平台支持 作为典型的LAMP结构的应用软件，WP仅支持Mysql，而DP支持mysql和Pgsql两种数据库。从某种虽然像本站这样从pgsql迁移到mysql的平台几乎很少，而且国内很少有Pgsql的空间，作为一个开源项目，提供多个备选数据库还是不错的。 从响应时间上看，同样采用了Mysql的数据库，DP的响应速度快了WP不少，但换成了Pgsql之后，速度慢了整整一个数量级——这跟Pgsql本身有关。故可以认为同等数量下，DP的硬件要求相对较低。 数据结构 看了WP的数据结构，了了10张表，感觉很干净。每个表的字段命名方式也足够清晰。初学者不需要多少时间就能理解整个数据流程。而且默认会在表名前添加wp_前缀，方便那些虚拟主机用户添加别的系统。 DP的数据结构比较复杂，40几个表的数量相对比较惊人。冗余度很高表名，字段名，重复的很多，也有很多缩写，初学者很容易给吓住。默认没有前缀，虽然可以设置前缀，但相对比较麻烦。 逻辑结构 WP的逻辑结构是一个内核程序已经可以完成大部分的功能，其他的功能通过plugin的方式实现。DP的逻辑是整个程序是由若干个Module实现，每块的功能都可以通过设置进行开关设置。相对灵活性比较好，但设置自然而然的复杂了很多。 安装步骤 WP的安装步骤相对较多，很详细的流程向导。WP的安装只要设置好数据库就OK，但不够清晰，特别是管理员添加采用的方式，很容易让人迷糊，同时不注意的话，默认注册用户就会有管理员权限。 本地化实现 WP的本地化通过.mo文件实现，等于是基于内核的实现，速度几乎不受影响。DP的本地化基于Module实现，每出现一个词组就需要一次数据库查询，相对效率低下。 主题开发 由于DP特有的逻辑，主题方面本身也是一个Module，可以通过扩展的方式支持各种同样的模板引擎，很适合于大团队进行主题的开发。WP相对主题开发比较困难，默认不支持页面引擎扩展，主题制作需要一定的PHP基础。 插件开发 DP的插件相对比较复杂，涉及到很多内容，需要对整个系统有一定的了解才能完成。WP的插件相对比较简单，对于简单的插件只要明确“在什么地方出现什么”就可以完成，甚至默认还提供了一个Hello Dolly伪插件作为范例。 管理界面 DP的管理界面与用户界面高度统一，同时提供了详尽的日志方便查阅。WP采用独立的管理控制台，可查阅的内容不多。 其他 默认状况下，WP提供了一个反垃圾插件很是有效。 个人觉得，两个系统都各有所长： WP方便简单，很适合于个人网站的快速部署。DP功能很强，同时支持企业级的Pgsql，适合具有一定规模的网站。 WP很容易开发出一些小插件，但界面开发有一定难度，最好找个主题自己修改。DP可以很容易的进行大规模的模块、主题HACK且不会对系统做成太大影响，前提是你要对他有足够的了解。

Oracle+Sun=?

刚刚得到的消息，Oracle以每股$9.50的价格，总计74亿美元收购了Sun。具体官方报道

上回说到IBM的收购案，被IBM收购可以看作对SUN的一种讽刺甚至于侮辱。在一次次的谈判无果之后，忽然间传出了这么一条冷门消息。MS说明与IBM谈判是假，Oracle是真啊。

Oracle收购Sun之后，Java的悖论总算不会发生了，Oracle一直梦想的"进军操作系统"也得以实现。Sun呢？有了Oracle作为摇钱树，系统整合中又多了数据库这一块的业务。看来，我们又一次见证了另外一个IBM的诞生。

整合以后的Mysql如 何？mysql作为独立的一部分业务，本身就有oracle的股份存在。同时,mysql和oracle也不存在市场竞争（最终用户是不同的） 对于此次收购本人认为对于mysql的影响不大。即便Oracle不需要Mysql，Mysql最有可能也不过就是交由社区维护，无非由一个.com变成 了.org而已。

总之，祝今后的新Oracle一路走好！

Mysql的几个设置值

mysql数据库的优化――老声长谈的话题，总是有那么多的话题好谈。闲来无事，谈谈几个关键优化参数的设置问题。注意的是，本文主要针对于MyISAM引擎，其他的，日后再吧。

在此之前，如果对mysql的命令和配置不很熟的情况下，phpmysql是必要的。

首先，到状态选项栏，拉一个系统状态表下来，或者执行mysqladmin variables extended-status �u root �p  ，同时计算下系统的uptime.

配置文件一般保存在/etc/my.cnf中，直接修改其中的内容即可。

此外，我的设置中还有如下内容：

skip-networking #不使用网络连接
skip-innodb #不使用innodb引擎

thread_concurrency = 4 #这个数值等于cpu核心数x2

 

key_buffer_size参数的设置:索引缓冲池大小，决定了处理索引的速度。官方文档说最多这将会有238%的性能提升。什么，你的表不加索引？来人啊，把他拖到这个页面。

1. 算法一：把系统中所有在用的表的索引加起来，个人习惯取一个最接近此数的2的n次方。如32M，64M，128M……
2. 算法二：设置到Key_reads  ：Key_read_requests 至少应该1：500以上，越大越好，例如我的：
   [root@www ~]# mysqladmin variables extended-status -u admin -p  |grep Key_re
   Enter password:
   | Key_read_requests        | 7335599   |
   | Key_reads                          | 9137      |

两种方式随个人喜好啦，个人习惯用后面的方式进行配置。

query_cache_size：返回结果缓存，数据库会将返回值缓冲，当然会快，如果想要强制关闭该功能，可以在sql中加入SQL_NO_CACHE。

[root@www ~]# mysqladmin variables extended-status -u admin -p  |grep Qcache
Enter password:
| Qcache_free_blocks       | 115       |
| Qcache_free_memory       | 27422464  | #剩余的缓冲空间
| Qcache_hits              | 15257     |
| Qcache_inserts           | 11492     |
| Qcache_lowmem_prunes     | 0         | #出现缓存过低的此数
| Qcache_not_cached        | 29        |
| Qcache_queries_in_cache  | 1115      | #缓存的结果数
| Qcache_total_blocks      | 2441      |
| Questions                | 43849     |

次数值大致算法：最大返回大小x每5分钟查询次数。

原则上，如果内存足够的情况下，可以尽量调大此数值。个人认为  uptime 秒数/Qcache_lowmem_prunes  应该小于300。这意味着至少不是每5分钟系统就报一次缓存过低。

要注意的是配置了此参数的时候，请同时设置 query_cache_type= 1

table_cache：表缓冲数量。

mysqladmin variables extended-status -u admin -p  |grep Open
Enter password:
| Open_files               | 191       |
| Open_streams             | 0         |
| Open_tables              | 132       | #打开的表
| Opened_tables            | 138       | #已经打开的表

我这边设置的table_cache为512，uptime为2小时，暂时看不出有什么问题，如果系统一开没多久Open_tables就已经等于设置的table_cache的时候，请将此数值再调大。

关于索引：刚才被拖走的兄弟可以回来了^_^
很多人最初接触索引的时候，以为索引越多越快。其实不然，过多的索引往往会拖慢系统，按照惯例索引字段最多只占字段总数的40%。多则无益。

索引字段的类型，尽量选择numeric下属的类型或者date time下属的类型，如果非要用string，可以尝试使用char来取代varchar，很多情况下不影响使用，但性能提升一个档次。

关于内存

经过上面的折腾，内存耗用量应该大有提升。很多人觉得内存占用高了性能会下降――这似乎是windows桌面的问题。要知道，作为一个数据库服务器而言，痛苦的不是内存用完了；而是内存用不掉，IO用光了。 能把内存用的光光但swap基本不动，这才是高明的系统管理员。

正常负载下，mysql的内存耗用要保证大于空闲内存。

sql语句的问题

尽管这不属于系统管理员的工作内容，但要知道，一个到处是select * 语句的程序是绝对会影响系统性能的。

关于备份

作为日常工作的一部分，经常性将数据拷来拷去的做备份。久而久之就觉得没有定义备份策略的系统就是一个极度危险以及极度不健全的系统。

然而备份以后又如何呢？

前些日子从箱底找出了高中时期的几张软盘，其中甚至还有一张720K的3寸盘，上面有当时我初学电脑时的见证。打算怀旧一下。于是借来了整个公司唯一的3.5寸移动软驱――这本身已经很是不容易了，幸好没有使用当初学校里的5寸盘保存。然而无一例外都说那句经典的"磁盘未格式化"。手抖，不敢确认，生怕格式化之后所有数据再也找不回来了。几经斗争后，决定放弃。即便能够读取文件，谁又能保证现在的系统能够完美的打开wordstar wps cced 以及Qbasic的文件呢？

曾经说过，一本书在250年之后尚没有影响可读性。但是就目前的存储方案来看，有什么方法可以存放250年以上？纸面备份似乎是唯一的方法。（貌似没有这样的需求）

IT业在不断增加着数据创造的速度，数据复制的速度，同时也在大幅降低着数据媒介的保存时间。正如石刻可以保存上千年，书本只能保存几百年，磁盘的寿命估计也就是那么几年吧。

我们的文化瑰宝，伴随着白话运动丧失了根基，导致了现在只要见过胡适或者鲁迅的人都敢称国学大师；伴随着简体化丧失了韵味，出现了fuck goods这种低级笑话；伴随着网络化和云存储时代的到来，难不成有一天会因为一块硬盘的崩坏而彻底崩坏么？

说说C2C

前不久有人问我，为什么现在不在taobao和ebay上开店了。

其实之前开店的目的很单纯――之前小站提供了很多*nix镜像下载，后来有访客说下载太慢，或者太费事，希望从我这里直接买。仅此而已。后来陆续的处理一些自己的二手硬件以及朋友弄来的东西。

之后，由于种种原因，其中一部分是由于个人原因，没有这个精力去维护这些小店。另一方面，本人实在不敢苟同部分买家、网站以及第三方的做法。

首先要说的是物流方面的问题：小站上本身一套光盘最多也就是卖个5块钱，运费上却经常要出到10~15元。明摆着是给物流公司做销售员的活。摆着为访客服务的态度，不赚钱也好，赔钱也好，我都认了。可那个时候的物流公司简直可以用"非常不专业"来形容。答应买家当天肯定到，早上8点刚过，打电话给物流公司取件，加急当天件，本以为9点钟肯定来的了取件。谁知一拖拖到了下午4点，其间电话催了不知到多少次，总算来了。上来就说："你们要发当天是吗？"拜托，用点心想一想，4点钟都过了，除了你们可以多赚一倍的钱之外，当天件有意义吗？这里且不说损坏或丢失或延误的情况，这些似乎已经成为可以接受的问题了，虽然也经常碰到。

接着就是买家的素质问题：这个其实作为卖家而言，本无可挑剔的。可有些买家真是太把自己当上帝了。5块钱买了一套盘，甚至根本没买东西，不管现在是几点，愣是打电话询问这询问那。搞得我比redhat的全球支持中心都累，还要7×24x365的支持。问题在于，买redhat服务的顾客大多都懂一点技术的，可我的上帝们有些连怎么用光盘启动机器都不会。实在憋不住了，说了句很重的话。OK，惨了，人家会以给差评或者退货相威胁。钱赚不到，气受了一包。

最后是所谓不良竞争或者恶意买家的问题：这个就是购物网站的责任了。本身小店是不赚甚么钱的，也是我搞不懂了，为什么偏偏不赚钱的生意也有人嫉妒――恶拍的、恶评的、拿了东西不给钱的、不给钱还给差评的，嗑瓜子掉出个臭虫，什么人（仁）都有――几乎每个月都有几次。应付这些问题，实在不值。

作为买家，咱们也不妨说下：假货横行的问题，恐怕是最主要的。在C2C上买过特别是服装类的朋友都知道的定式是"照片里是原版的，卖的是翻版的"。曾经在网上看到200块的"劳力士"对表，询问了一下，对方还敢兴势旦旦的跟我保证是"可以走的真货"。我这个晕。

经常看到买家对于c2c网站的投诉也好，抱怨也好，仿佛买家是弱者。通过我个人的实际经验得到的结论，其实C2C网站很多情况下卖家才是弱者。买家反正是受《消费者保护法》保护的，永远不吃亏，卖家呢？个人觉得，最终的结果会是B2C在最终零售市场上压到性的取代目前的C2C。

Sun的身前身后事

最近业界的有个传闻很引人注意，那就是IBM正在与Sun进行收购谈判。最终结果如何都是大家期待的。一代枭雄的Sun再也支撑不住，似乎大厦将倾了……

当大家都在关注Sparc平台，Java中间件，Solaris操作系统以及一大堆应用的何去何从时，业界的另一个比较有趣的话题逐渐的浮出水面——作为Java下的应用，同时又是IBM竞争对手的Oracle和SAP是否还会继续支持Java？选择继续无疑于与虎谋皮；选择放弃Java，拜托，这么多的客户岂不是要倒戈？

这些只是作为一些题外话，不管今后Sun怎样，不妨总结下Sun的贡献吧。

首先，在开源领域中，Sun的地位可以说是无可撼动的领头羊。目前最大的3个开源项目，分别是Sun主导的opensolaris，Sun主导的Openoffice，以及Sun主导的OpenJava。是不是感觉到了点什么？除此之外，还有Sun支持的mysql也可以说是最为常用的开源系统之一了。

系统集成上，Sun同时拥有了硬件平台，到操作系统再到桌面生产力工具和IDE。可以说目前连微软也是做不到的高度（至少MS没有自己的CPU）。唯一可以与之匹配唯独IBM这个蓝色巨人。然而一旦IBM==SUN，这又意味着什么？

Java的出现也是一大创举。过去企业要做开发，需要BS,CS,甚至于OA等多个开发团队来实现。Java的很空出世，加上Oracle和SAP的协助，对于企业平台而言，数据库之需要一个，平台只要一个，开发团队只要一个，空前的统一！

最后，OpenSparc的标准也成为开源硬件的一大创新性尝试。
window.google_render_ad();

IBM方面呢？

蓝色巨人的最大竞争对手倒下了。白捡了客户，减少了竞争对手。这世界顿时清静了。

控制了JAVA，间接的抑制了Oracle对于DB2，SAP对于Domino的市场冲击。

拿到了SPARC的研发团队，弥补了自己power平台的技术缺失。

…………

难道PowerPC版本的Solaris就是对于现状的预兆？

所谓现代的经济，就是在定期和不定期的执行“破坏性创造”。输赢只在乎破坏力来自何方，来自自己，你是赢家；来自竞争对手，很遗憾，You Lose!

关于 load average

很多人都知道uptime命令会得到如下的返回：
12:00:59 up 20:24,  1 user,  load average: 0.49, 1.40, 1.61

其中的load average根的3个数字，分别表示系统在1分钟，5分钟和15分钟的平均负载情况。这个数字是系统每5秒钟会自动检测一下活跃的进程数量（即top命令看到的n running），然后得出结果。具体感兴趣的话可以研究下Linux内核中include/linux/sched.h， kernel/timer.c，fs/proc/proc_misc.c

所谓活跃的进程，需要满足：

• 没有被终止或者正在调用wait。
• 不是正在等待I/O操作。

很多网上说这个数字除上CPU的数量如果得到的结果大于5就说明系统在超负荷运转。对于这个结论本人持保留意见。

1. 对于双核或者多核的CPU，如果按照1个CPU来计算，那么明显的状况就是对于多核心的不公。如果按照多个CPU来计算，那又是对于多路CPU，甚至是独享内存总线多CPU的不公。对于基于HT技术的"假多核"更是如此。
2. 对于不同平台的CPU而言，目前公认的是X86架构"不耐压"，特别在于高并发的情况下。本人明显觉得SPARC的架构相比X86在压缩同一个文件的时间更长；但是同时进行多个压缩的时候Sparc的平台占有绝对优势。
3. 超负荷的界定：有的系统，在1.5的情况下已经能够感到明显的延时；同样有的系统在10以上还能迅速响应。