首先安装好gd
假设gd是安装在/usr/local/gd2，php是安装在/usr/local/php-cgi的话
cd /usr/local/src/php-5.2.8/ext/gd/
/usr/local/php-cgi/bin/phpize
./configure –with-gd=/usr/local/gd2 –with-php-config=/usr/local/php-cgi/bin/php-config
make && make install
然后再修改php.ini文件
手工修改：查找/usr/local/php-cgi/etc/php.ini中的extension_dir = “./”
修改为extension_dir = “/usr/local/php-cgi/lib/php/extensions/no-debug-non-zts-20060613/”
并在此行后增加以下几行，然后保存：
extension = “gd2.so”
接着昨天那个iconv问题继续研究，发现iconv函数数据输出为空。经过分析基本判断为gd库和iconv的冲突问题只要php编译中加入gd库支持就会导致这一情况，但是在x86系统里面缺完全没有这个问题，看来只是x64的问题。解决方法是把gd或者iconv作为作为动态模块加载，总之避免gd和iconv同时使用静态方式编译就行。ps：后来我发现我有一台x64的机器都是静态编译的但是就偏偏没有这个问题真是奇怪了。看来这问题还是有一定前提的
一个兄弟网站的discuz论坛换了台新的服务器，从apache换到了nginx结果发现换了之后wap访问论坛出来的页面没有任何中文字（英文还是存在的）。我在看了之后一开始以为是wap程序php取数据库编码的问题。后来做了几次修改尝试后发现并非数据库输出内容无中文，而且经过和我们的对比发现连普通的静态内容的中文也都是没有的，一下子就想到问题出在了php上面，于是安装wap下面原来的index.php输出方式手写了一个临时php调试，发现php输出都没问题，有乱码出现，看来问题出在编码转换上面。于是自己看了下discuz的编码转码的库文件chinese.class.php，发现这台新服务器是启用iconv函数的，里面检测到了iconv然后使用iconv函数进行编码转换，忽然想到可能是系统iconv函数库的问题。于是找的了判断iconv的代码：
1
2
3
4
5
6
7
| if(function_exists('iconv') && $this->config['TargetLang'] != 'BIG5' && !$ForceTable) {
$this->iconv_enabled = true;
} else {
$this->iconv_enabled = false;
$this->OpenTable();
}
...... |
修改了这段代码绕过了iconv检测，强制设为不存在iconv的方式处理编码转换。
1
2
| $this->iconv_enabled = false;
$this->OpenTable(); |
然后测试果然中文又回来了。
以前也是一时起兴，顺手试了试结果php configure的时候出错，就放在那一直也没空弄。
最近打算把部分虚拟机扩到8G内存测试下压力所以又把64的系统装起来再次尝试。
吃好晚饭忽然觉得有点头晕恶心，什么事情都干不了，就在那里翻config的log，结果发现原来是krb5没装，yum install krb5 krb5-devel后重新configure搞定。忽然发现头也不疼了哈哈。
Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？
A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：
- 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
- 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
- 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
- 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
- 5、 PHP不存在表的锁定问题；
- 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。
至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。
列出一些 PHP 中执行排序更优的情况：
- 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
- 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
- 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
- 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；
列出一些必须在 MYSQL 中排序的实例：
- 1、 MYSQL 中已经存在这个排序的索引；
- 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
- 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
- 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]
从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。
–EOF–