戌狗』。『花花的世界

用simplexml处理atom数据

很多博客使用atom来输出数据，但是atom使用了名称空间(namespace)，所以现在请求被命名的元素和本地名称时必须指定名称空间统一资源标识符（URI），还有一点就是simplexml的xpath方法无法直接query这个xml tree。

从 PHP 5.1 版开始，SimpleXML 可以直接对带名称空间的文档使用 XPath 查询。和通常一样，XPath 位置路径必须使用名称空间前缀，即使搜索的文档使用默认名称空间也仍然如此。registerXPathNamespace() 函数把前缀和后续查询中使用的名称空间 URL 联系在一起。

下面是使用xpath查询atom文档title元素的例子：

用simplexml处理rss数据

wordpress可以输出rss2的数据源，这里面也有一些不同的namespace，比如dc。一个使用simplexml解析rss2的例子：

这个例子中，使用children方法来获得名称空间中的数据：

Performance tuning is one of the top disciplines (if not THE top discipline) that database professionals want to excel at. Being able to take a system that's running sluggish and turn it into one that's running as fast as a scalded dog is a talent that's part art and part science, but whatever the combination necessary to make it happen, there will always be strong demand for folks who are good at it.

When a database performance analyst begins to look at a poorly performing database, there are usually several forms of analysis that they will use:

• Bottleneck analysis – this concerns itself with answering the question "what is my database waiting on?" Perhaps it's a case of lock contention or other I/O bottleneck that's causing a database to slow down, but whatever the issue, the end goal is to get things "unclogged" so the database can get back up to speed.
• Workload analysis – this type of analysis deals with two things: who is logged on and what are they doing?  Here you are looking at user load (active, idle, etc.), physical and logical I/O activity, and the SQL code that is being executed along with how many times various statements are executed.  Anyone familiar with database tuning knows it only take one well-timed bad query from hell to send everything down the drain in short order.
• Ratio analysis – this is the least useful form of analysis, but it can be somewhat helpful to get some basic rule of thumb measurements.  Using various SQL scripts, you can get measurements such as memory vs. disk reads (cache hit ratios) and other like statistics.

If you've been using MySQL for a while, you know that – sadly – MySQL doesn't have as rich a performance management interface as some of the other proprietary databases like Oracle, so doing a thorough diagnostic analysis of a slow-running system can be challenging.  Fortunately, new versions of MySQL are introducing more and improved diagnostic objects to help you better troubleshoot MySQL servers.

One of the new performance management enhancements is found in the new Falcon transactional storage engine that was introduced in MySQL 6.0. The Falcon team has designed a set of new Information Schema tables to help you understand how well Falcon is performing and where issues may be developing.  Let's take a quick look at some of these new tables and see how you can make use of them when you're working with Falcon.

Falcon Diagnostic Tables Overview

In MySQL 5.0, the Information Schema (IS) was introduced to help MySQL users get metadata on objects, security privileges, and more info that exists on a particular MySQL server.  In MySQL 6.0, the Falcon storage engine adds the following new tables to the IS:

mysql> use information_schema Database changed mysql> show tables like 'FAL%'; +-------------------------------------+ | Tables_in_information_schema (FAL%) | +-------------------------------------+ | FALCON_TABLES                       | | FALCON_RECORD_CACHE_SUMMARY         | | FALCON_SYSTEM_MEMORY_DETAIL         | | FALCON_SERIAL_LOG_INFO              | | FALCON_VERSION                      | | FALCON_TRANSACTION_SUMMARY          | | FALCON_DATABASE_IO                  | | FALCON_SYNCOBJECTS                  | | FALCON_TRANSACTIONS                 | | FALCON_RECORD_CACHE_DETAIL          | | FALCON_SYSTEM_MEMORY_SUMMARY        | +-------------------------------------+ 11 rows in set (0.00 sec) 

Some of the new Falcon tables only provide information when the server is in debug mode – these include the FALCON_RECORD_CACHE_SUMMARY, FALCON_RECORD_CACHE_DETAIL, FALCON_SYSTEM_MEMORY_SUMMARY, and FALCON_SYSTEM_MEMORY_DETAIL tables. But the others contain valuable diagnostics that you can access to determine the health of Falcon-related database performance.  

The most basic Falcon table is the FALCON_TABLES object, which simply shows the various Falcon objects in a MySQL instance and their database and tablespace assignments: 

mysql> select * from information_schema.falcon_tables; +-------------+--------------------+-----------+-------------+--------------------+ | SCHEMA_NAME | TABLE_NAME         | PARTITION | TABLESPACE  | INTERNAL_NAME      | +-------------+--------------------+-----------+-------------+--------------------+ | GIMF        | BROKER             |           | FALCON_USER | BROKER             | | GIMF        | CLIENT             |           | FALCON_USER | CLIENT             | | GIMF        | CLIENT_TRANSACTION |           | FALCON_USER | CLIENT_TRANSACTION | | GIMF        | INVESTMENT         |           | FALCON_USER | INVESTMENT         | | GIMF        | INVESTMENT_TYPE    |           | FALCON_USER | INVESTMENT_TYPE    | | GIMF        | OFFICE_LOCATION    |           | FALCON_USER | OFFICE_LOCATION    | +-------------+--------------------+-----------+-------------+--------------------+ 

The other tables are more performance-related and less concerned with general database metadata.

Looking at Falcon I/O Performance

Suppose we have a Falcon database that resembles the following model (which, by the way, was created in MySQL Workbench, MySQL's new data modeling tool that you can download at: http://dev.mysql.com/downloads/workbench/5.0.html):

As Falcon doesn't support foreign keys yet, ignore the FK relationships you see in the above model.  The model/database is a simple design centered around an investment firm.  If the MySQL server was just started, that would mean no data has been accessed on the system yet; as a result, the Falcon diagnostic tables would be empty:

mysql> select * from information_schema.falcon_database_io; Empty set (0.00 sec) 

But once we access a Falcon object, then the system contains data we can analyze:  

mysql> select count(*) from gimf.client_transaction; +----------+ | count(*) | +----------+ |    18675 | +----------+ 1 row in set (0.56 sec)  mysql> select * from information_schema.falcon_database_io; +------------------+-----------+---------+----------------+--------+---------------+-------+ | TABLESPACE       | PAGE_SIZE | BUFFERS | PHYSICAL_READS | WRITES | LOGICAL_READS | FAKES | +------------------+-----------+---------+----------------+--------+---------------+-------+ | FALCON_MASTER    |      4096 |    2560 |             51 |      1 |          1041 |     0 | | FALCON_TEMPORARY |      4096 |    2560 |              1 |      0 |             0 |     1 | | FALCON_USER      |      4096 |    2560 |            299 |      0 |         56028 |     3 | +------------------+-----------+---------+----------------+--------+---------------+-------+ 

Tables such as the FALCON_DATABASE_IO table can be used for both workload and ratio-based analysis.  For example, to get an overall cache hit rate for falcon, you could use this SQL:

mysql> select 100 * 1-(sum(physical_reads) / sum(logical_reads)) falcon_hit_rate     -> from information_schema.falcon_database_io; +-----------------+ | falcon_hit_rate | +-----------------+ |         99.9938 | +-----------------+ 

So 99+% of the Falcon I/O has been memory-based (logical) vs. physical, which is good by a simple rule of thumb but in no way indicates things are performing well overall.  You can also get per tablespace statistics by using this query:

mysql> select tablespace,     -> 100 * 1-(sum(physical_reads) /     -> sum(if(logical_reads > 1, logical_reads,1))) falcon_hit_rate     -> from information_schema.falcon_database_io     -> group by tablespace; +------------------+-----------------+ | tablespace       | falcon_hit_rate | +------------------+-----------------+ | FALCON_MASTER    |         99.9510 | | FALCON_TEMPORARY |         99.0000 | | FALCON_USER      |         99.9947 | +------------------+-----------------+ 

Again, don't confuse high hit rates with being able to nod off on your DBA job.  Plenty of systems have been brought to a crawl with excessive logical I/O that wreaks havoc.  Instead, you should focus your attention on reducing all forms of I/O – both logical and physical – as well as the number of SQL statement executions as best you can.  And don't forget about the MySQL query cache; if used in the right scenarios, it can greatly help reduce the I/O strain on a MySQL server.

If, however, you see great volumes of physical reads, you do have fairly low hit rates, and you've done your research on minimizing overall executions and feel confident about your indexing strategy, then it's a fair bet you want to look into increasing the Falcon record and page cache sizes (falcon_record_memory_max, falcon_page_cache_size).

Another I/O area to review is Falcon log performance. The serial log is used during normal operation as a performance boost for write operations, and after a crash for database recovery.  During normal operation, the serial log allows Falcon to write out many data changes at once when a transaction commits, rather than writing out pages scattered in different parts of the database file. When a transaction commits, it creates a log entry saying it is committing, then writes log entries with the final state of every record it modified to the log file in memory. It then flushes the log file to disk.  That write makes the transaction durable (the D in ACID).

Falcon has a diagnostic table to view how busy the log has been:  

mysql> select * from information_schema.falcon_serial_log_info; +---------------+--------------+--------+---------+---------+ | DATABASE      | TRANSACTIONS | BLOCKS | WINDOWS | BUFFERS | +---------------+--------------+--------+---------+---------+ | FALCON_MASTER |            0 |      0 |      34 |      20 | +---------------+--------------+--------+---------+---------+ 

You can also check the parameter setting for the Falcon log with this command: 

mysql> show global variables like '%falc%ser%buf%'; +---------------------------+-------+ | Variable_name             | Value | +---------------------------+-------+ | falcon_serial_log_buffers | 20    | +---------------------------+-------+ 

So the diagnostic table tells us that all buffers have been accessed and that no current transactions are open at this time. When you first view the table, there may be a point of confusion since there is both a WINDOWS and BUFFERS column.  WINDOWS is the number of windows in to the serial log being tracked by internal Falcon code objects and this number may be higher than the falcon_serial_log_buffers setting.  The BUFFERS column shows how many of those code objects actually have 1 MB buffers and the statistic never gets larger than the falcon_serial_log_buffers setting.

When the serial log is opened, all the buffers requested are allocated initially and they are handed out to the internal code objects on an as-needed basis.  When they are all in use, they are switched between windows when they are not in use by another.  Finally, note that this diagnostic table reports how many internal code objects are active in regards to windows and how many of them have buffers; it does not currently indicate whether those buffers are in use.

If you see that the BUFFERS column never reaches that amount you've set for the falcon_serial_log_buffers parm, then you can likely reduce that value as you could be wasting memory.

Looking at Falcon Transaction Bottlenecks

One key to understating database performance is getting a handle on transactional activity and bottlenecks in a busy system. To help with this, Falcon supplies two tables that help with the analysis of global transaction traffic and detailed transactional work. Let's create a blocking lock situation and see what these tables tell us:

*** first session ***

mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> update investment_type set investment_type_name = 'hi'    -> where investment_type_id = 1; Query OK, 1 row affected (0.03 sec) Rows matched: 1  Changed: 1  Warnings: 0 

*** second session ***

mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> use gimf Database changed mysql> update investment_type set investment_type_name = 'hi2'    -> where investment_type_id = 1; 

*** back to first session ***

mysql> select a.id thread, a.user,b.id txn_id,a.db,b.waiting_for, substr(statement,1,30)     -> from   information_schema.processlist a,     -> information_schema.falcon_transactions b     -> where  a.id = b.thread_id; +--------+------+--------+------+-------------+--------------------------------+ | thread | user | txn_id | db   | waiting_for | substr(statement,1,30)         | +--------+------+--------+------+-------------+--------------------------------+ |      2 | root |      6 | gimf |           0 |                                | |      3 | root |      7 | gimf |           6 | update investment_type set inv | +--------+------+--------+------+-------------+--------------------------------+ 

Falcon helps us easily see what transactions are blocking other work on the system via the FALCON_TRANSACTIONS table, which can be joined to another IS table – the PROCESSLIST table.  We can see both connections involved in the block along with the SQL statement being blocked. If we rollback both transactions, we can then look at the global Falcon transaction table and see what's happened on the system:

mysql> select * from information_schema.falcon_transaction_summary; +---------------+-----------+-------------+--------+----------------+--------------------+ | DATABASE      | COMMITTED | ROLLED_BACK | ACTIVE | PENDING_COMMIT | PENDING_COMPLETION | +---------------+-----------+-------------+--------+----------------+--------------------+ | FALCON_MASTER |         0 |           2 |      0 |              0 |                  0 | +---------------+-----------+-------------+--------+----------------+--------------------+ 

Being able to quickly see transaction bottlenecks, such as the above, that are occurring inside Falcon can be a big help when things suddenly seem to freeze up on a system.

Conclusions

Performance tuning will always be a top priority for database pro's, and being able to separate the wheat from the chaff in terms of knowing what to focus on vs. knowing what to disregard will be a coveted skill in this discipline.  With Falcon, you have a number of good, new diagnostic aids to help you when you start your analysis in the area of bottlenecks, workloads, and ratios.

Keep in mind that the new Falcon diagnostic tables are still in beta form right now, so you may encounter bugs and such when using them.  The Falcon team would certainly appreciate you logging any bugs you find in our bug system at http://bugs.mysql.com/.

You can download a copy of the current Falcon beta at: http://dev.mysql.com/downloads/mysql/6.0.html (Note: the 6.0 binary may be labeled ‘alpha' but it does contain the Falcon transaction engine beta).  Please give Falcon a try and let us know what you think.  

As always, thanks for your support of MySQL!

基于Eclipse和PDT，加入了ZendStudio的专用特性，支付ZF框架，ZendCore Zend Platform。
Zend Studio一直是很多PHP开发者的首选工具，它与Java的关系一向甚为亲密，Zend Studio 5一直都是基于Java Swing的，现在好了，Zend Studio直接改投Eclipse了,它的主要功能如下：

编辑器和文件管理功能

• PHP4和PHP5支持
• 语法高亮，代码辅助
• 模板（PHP, PHPDoc, New File）
• 代码折叠（类，函数和PHP文档）
• 实时错误检测
• 书签
• 智能源代码+当前代码跳转支持
• 自动插入（括号，PHPDoc）
• 括号匹配
• 注释/非注释PHP代码
• PHP（项目）浏览器
• 打开资源（文件/函数）
• PHP手册集成
• 查找PHP元素
• 文件/项目/PHP检测（概况）
• 高级代码格式化（缩进，括号，空字符和空行）
• 文件中查找替换
• 任务
• 项目包含路径
• 问题查看
• 拖拽或在文件浏览器中打开文件
• 简易的新文件创建
• 头文件代码辅助

代码生成

• Getter/Setter函数
• 覆盖/实现函数
• 新建PHP类/接口

JavaScript支持

• 语法高亮
• 基本JavaScript块的代码辅助
• 在PHP/HTML视图中查看JS元素

HTML支持

• 所见即所得编辑
• 语法高亮
• 代码辅助
• 代码折叠
• 拖拽HTML组建
• 设计和源代码视图切换
• 属性查看 源代码控制
• 本地历史
• CVS
• Subversion

PHPUnit测试支持

• 测试代码支持
• 可视化测试结果支持
• 栈轨迹和过滤

Debugging

• 本地Debug
• Web服务器Debug
• 本地部署
• 字符集支持
• 管道支持
• Web服务器管理
• 文件内容传输（使用本地/服务器拷贝）
• SSL通信
• 浏览器工具栏支持
• PHP可执行效率
• Web服务器性能
• 代码覆盖

远程系统部署支持

• FTP
• SFTP

SQL/数据库支持

• 查询编辑器 - 语法高亮，代码语法辅助
• 新建连接探测向导
• 可编辑表视图
• 对象树 - 表，视图
• JDBC驱动

杂项

• 高级PHP代码分析
• RSS阅读器
• Web Services编辑器
• Web Services支持（向导和分析器）
• PHP文档支持
• BIRT集成（代码辅助，样例项目，模板）
• Java桥接 - Java类和包的代码辅助

Zend Platform集成

• 基本集成（开放平台GUI）
• 事件列表查看
• Debug/性能事件
• 自动允许服务器Debug/管道（使用WSDL）
• 平台API

Zend框架集成

• 代码辅助
• 框架工程
• 代码模板
• 样例工程
• MVC视图
• MVC代码生成

其他集成

• Zend代码片段查看器
• Zend代码片段交互（建议，投票）
• Zend Guard集成

Zend Studio 5.5移植

• Zend Studio键映射
• 导入Zend Studio工程

安装程序/文档/支持

• 包/安装程序
• 多语言支持
• 每日一贴
• 网页和电话支持
• 自动更新

Zend Studio for Eclipse 正式版下载地址

Linux 版：
http://downloads.zend.com/studio-eclipse/6.0.0/ZendStudioForEclipse-6_0_0.tar.gz

Windows 版：
http://downloads.zend.com/studio-eclipse/6.0.0/ZendStudioForEclipse-6_0_0.exe

Build a Secure Logging Server with syslog-ng
日期：April 4, 2006
作者： Carla Schroder
翻译：latteye

管理Linux系统以及应用程序的日志非常重要且具有趣味性。我们想要得到的是重要的、有用的信息，并不是大量的垃圾。你得有能力在日志中找到你需 要的信息。古老的 syslogd 工具已经工作了许多个年头。但它现在已经不足以面对更加复杂的需要。为了代替它，我们有了新一代的 Linux 日志管理工具，syslog-ng(syslog-next-generation)。

比较 syslog ，syslog-ng 具有众多高级的功能：更好的网络支持，更加方便的配置，集中式的网络日志存储，并且更具有弹性。比如，使用syslogd时，所有的iptables日志 与其他内核日志一起全部存储到了kern.log文件里。Syslog-ng则可以让你有选择性的将iptables部分分出到另外的日志文件中。 Syslogd仅能使用UDP协议，Syslog-ng 可以使用UDP和TCP协议。所以你可以在加密的网络隧道中传输日志到集中日志服务器。

安装

所有的Linux发行版本已经默认提供了Syslog-ng包。目前的稳定版本为1.6。如果你使用yum或者apt-get等工具安装 Syslog-ng，他们会自动卸载sysklogd包。如果sysklogd没有被自动卸载，亲你手动删除它并且确保syslogd服务已经停 止。（sysklogd 是软件包名，syslogd 是服务名）

配置文件结构

由于功能具有弹性，所以配置文件的学习可能稍微曲折。Syslog-ng 的配置文件在 /etc/syslog-ng/syslog-ng.conf ，或者是 /etc/syslog-ng.conf 。你可以通过 man 5 syslog-ng 来学习所有的选项以及字段的含义。一般 syslog-ng 可能含有以下5个章段：

options{}
全局设置。 These can be overridden in any of the next four sections

source{}
信息来源, 来源可以是文件, 本地 sockets, 或者远程主机。

destination{}
信息目标, 可以是文件, 本地 sockets, 或者远程主机。

filter{}
过滤选项非常强大且复杂；你可以过滤日志中的任何方面，比如基础的 syslogd 快捷字段（facility names–man 5 syslog.conf 获取更多信息），log 等级，主机名，以及任何log中出现的字段或者是数字。

log{}
此段将来源 目的 过滤 都给连接起来并且告诉syslog-ng如何处理日志。

一些典型的全局选项：

options {

    sync (0);
     log_fifo_size (2048);
     create_dirs (yes);
     group (logs);
     dir_group (logs);
     perm (0640);
     dir_perm (0750);
     };

在 /etc/syslog-ng.conf 中使用的全局选项字段必须是被定义过的。 上面例子的具体含义是：

sync
在写入磁盘之前保留多少行的消息输出队列。（这里将日志输出称为“消息”。）0 是首选的数值，这可以让你确保捕获了所有信息，且磁盘也不会在系统以外掉电时丢失信息。

log_fifo_size
输出队列中消息的最大行数。默认为100行。你可以通过计算得出一个合适的数值，以下是引用一份邮件列表，里面提到了相关的内容：

每个消息来源最大接收数据的1024字节。单条日志信息为20至30字节。所以程序的一次执行可以送出1024/20=50条消息。对每个日志发送方，你的 log 接受能力必须满足这个数值。若你有两个日志源，则你必须能一次接受100条信息。
Each message source receives maximum 1024 bytes of data. A single log message is about 20 to 30 bytes. So on a single run each log source may emit 1024/20 = 50 messages. Your log fifo must be able to hold this number of messages for each source. So for two sources, you’ll need at least 100 slots in your fifo.

那两个选项非常容易混淆。 来自远程主机的消息会突然到达，所以你要保证你的 log_fifo_size 参数足以接纳那些突然增加的消息。 不然你就会丢失日志了， 当然这还受限于你的网络速度以及I/O速率。

create_dirs
启用或禁用自动为目标文件创建目录的功能。 在上文中值为“yes”, 所以远程主机会更具需要自动创建目录。

group
dir_group
设定日志文件以及目录的所有人（owner），所以你不必以超级用户（root）的身份去浏览那些日志。

perm
dir_perm
默认新日志文件的权限设置。

Source, Destination, 和 Filter 描述
Source, destination, 和 filter 的名字可以是任意的，看看下面的例子：

source s_local { internal(); unix-stream(”/dev/log”); file(”/proc/kmsg” log_prefix(”kernel: “)); };
destination d_auth { file(”/var/log/auth.log”); };
filter f_auth { facility(auth, authpriv); };

如果你喜欢你可以将 “source s_local” 改为 “source frederick_remington_depew”，当然 “destination d_auth” 也可以为 “destination moon.” 通常我们将 source 的名字中含有 “s” 字段，destination 的名字中含有 “d” 字段， filter 的名字中含有 “f” 字段，但这并不是必须的。source, destination, 和 filter 中其他的选项必须使用已经定义的字段，你可以通过 man 5 syslog-ng.conf  查看这些参数。

上面的例子 “source s_local” 将所有本地生成的日志信息作为一个信息源。而 “destination d_auth” 选项又将这些日志输入了 /var/log/auth.log 文件，当然这是通过 “filter f_auth” 将它们连接起来的。 auth 和 authpriv 是 syslog 标准的设备名称。

最后的日志申明（Log statements）将他们链接到了一起：

log {source(s_local); filter(f_auth); destination(d_auth); };

那么这四行就将本地所有的 auth 和 authpriv 日志筛出并写入了 /var/log/auth.log。

启用远程日志记录

当然，使用老的 syslogd 也可以很好的完成远程日志记录的工作，但那真的不太好，因为他只使用UDP协议传送数据包。首先你需要将所有的客户端上都装好 syslog-ng。并且在日志服务器的 syslog-ng.conf 文件中加入以下配置文件，这样才可以接受远程客户端日志，并将每台机器的日志写入单独的文件。

source s_remote { tcp(); };
destination d_clients { file(”/var/log/HOSTS/$HOST/”); };
log { source(s_remote); destination(d_clients); };

这是一个非常简单但十分有用的例子，他收集所有客户端本地的日志并将日志发送至远程日志服务器：

#sample syslog-ng.conf for a remote client
source s_local { internal(); unix-stream(”/dev/log”); file(”/proc/kmsg” log_prefix(”kernel: “)); };
destination d_loghost {tcp(”192.168.1.10″ port(514));};
log { source(s_local); destination(loghost); };

syslog-ng.conf 配置参考

一份完整的样板配置文件会显得比较长，你可以查看 syslog-ng 安装时附带的配置文件。Debian 用户得到的是一份通过 syslogd 配置而定制的配置文件。我们将给出一份日志服务器的配置文件，以及一个远程日志客户端的配置文件，来看看他们是怎么工作起来的吧：

#sample syslog-ng.conf for a central logging server
options {

    sync (0);
     log_fifo_size (2048);
     create_dirs (yes);
     group (logs);
     dir_group (logs);
     perm (0640);
     dir_perm (0750);
     };

source s_local { internal(); unix-stream(”/dev/log”); file(”/proc/kmsg” log_prefix(”kernel: “)); };
destination d_auth { file(”/var/log/auth.log”); };
filter f_auth { facility(auth, authpriv); };

source s_remote { tcp(); };
destination d_clients { file(”/var/log/HOSTS/$HOST”); };

log { source(s_remote); destination(d_clients); };
log { source(s_local); filter(f_auth); destination(d_auth); };

修改完 syslog-ng 之后要重启服务：

# /etc/init.d/syslog-ng restart

测试
现在你可以在日志服务器以及客户端上进行一些测试了。由于在本地服务器中最先出现的日志一般是认证日志，所以你可以先尝试着打开一个新的登录窗口，使用 su 或者是 sudo 都可以。接着检查 /var/log/auth.log 文件。在客户端上做一些操作，接着检查 /var/log/HOSTS 是否已经为远程客户端创建了新的目录。

另外一个方法是使用更加高级的 logger 命令：

# logger “this is a test”
# logger -p auth.debug “this is a test”

这将在你的日志文件中创建如下内容：

Apr 1 16:08:42 localhost.localdomain logger: this is a test

现在我们已经掌握了 syslog-ng 基本的功能，下周我们讲学习如何将 syslog-ng 客户端以及服务器按照你的意愿配置的更加有规则、易于管理，并且讨论如何建立一个安全的、加密的 syslog-ng 传输。

安装了Zend Optimizer,然后安装xcache.
结果提示PHP Fatal error: [Zend Optimizer] Zend Optimizer 3.3.0 is incompatible with XCache 1.2.2 in Unknown on line 0

解决方法:
用 zend_extension*** 先载入 xcache.so 后载入 zend***.so


xcache-1.2.2]# /opt/server/php/bin/php --version
PHP 5.2.5 (cli) (built: Mar 11 2008 16:02:24)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with XCache v1.2.2, Copyright (c) 2005-2007, by mOo
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.0, Copyright (c) 1998-2007, by Zend Technologies

自上次升级服务器环境和增加内存后的再次优化.
打开网页更快了