第一种情况比较常见，也有很多资料提及到，就是在SSH登陆时服务器端会对客户端的IP进行反解析造成登陆响应慢的问题，通常改sshd_config的“UseDNS no”即可以。

第二种情况，服务器端启用了GSSAPI。登陆的时候客户端需要对服务器端的IP地址进行反解析，如果服务器的IP地址没有配置PTR记录，那么就容易在这里卡住了。

对于这种情况，就有必要禁用GSSAPI认证以加速SSH登陆，具体有下面几种方式：

1. 解法一：使用ssh命令时使用附加的参数：ssh -o GSSAPIAuthentication=no server_address
2. 解法二：修改客户端ssh_config（/etc/ssh/ssh_config或~/.ssh/config）：GSSAPIAuthentication no
3. 解法三：修改服务器端的sshd_config(/etc/ssh/ssd_config)：GSSAPIAuthentication no

参考：

• GSSAPI
• 禁用ssh的GSSAPI提升连接速度

SSH登陆响应慢的问题 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201112/ssh-login-quite-slow/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

第一步：创建Google Profile，修改头像。同时，修改Google Profile的“以下网站的撰稿者”，增加你的博客网址在上面。

第二步：在博客文章中增加你的Google Profile链接，有几种方式：

1. 方式一：将Google Profile链接附加在每篇博文中。同时，重要是的还要设置链接的rel属性为“author”，如：

   <a href="https://profiles.google.com/102865267049130142543" rel="author">肖斌</a>

2. 方式二：
1. 创建一个“关于作者”的页面，在该页面插入Google Profile链接，但是这次rel的属性是”me”，如：

   Google Profile：<a rel="me" href="https://profiles.google.com/102865267049130142543">Google Profile</a>

2. 每篇博文增加一个指向“关于作者”页的链接，设置该链接的rel属性为“me”，如：

   <a rel="author" href="/about">About</a>

参考：

• Authorship
• Display your Profile Picture in Google Search Results
• http://schema.org/

怎样让Google在搜索结果呈现你的头像 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201111/how-to-display-author-profile-picture-in-google-srp/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

要怎样才可以在不停止ping的情况下取得ping的统计信息呢？

简单的做法就是使用按键“Ctrl+\”就可以(via)；爱折腾的同学，可以向ping进程发送SIGQUIT信号试试。

在漫长的ping过程中，这个小小技巧会很有用。

在Windows下，也有对应的按键，是：”Ctrl+Pause Break” (via)。

不停止ping的情况下取得统计信息 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201110/checking-ping-statistics-without-stop/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

<VirtualHost *:80>
    ServerAlias *.xiaobin.net
    VirtualDocumentRoot /var/htdocs/xiaobin.net/%1
</VirtualHost>

是的，就这么简单。

Apache绑定子域到目录 | 评论数(2)，添加评论
本文网址：http://xiaobin.net/201109/apache-mapping-subdomain-to-subdir-with-mod_vhost_alias/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

CREATE TABLE `user_group` (
  `id` int(11) NOT NULL auto_increment,
  `uid` int(11) NOT NULL,
  `group_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `uid` (`uid`),
  KEY `group_id` (`group_id`),
) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8

看AUTO_INCREMENT就知道数据并不多，75万条。然后是一条简单的查询：

SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;

很简单对不对？怪异的地方在于：

• 如果换成MyISAM做存储引擎的时候，查询耗时只需要0.01s，用InnoDB却会是0.15s左右

如果只是就这么点差距其实不是什么大不了的事，但是真实的业务需求比这个复杂，造成的差距也很大：MyISAM只需要0.12s，InnoDB则需要2.2s.，最终定位到问题症结是在这条SQL。

Explain的结果是：

+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+
| id | select_type | table      | type | possible_keys | key      | key_len | ref   | rows | Extra |
+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+
|  1 | SIMPLE      | user_group | ref  | group_id      | group_id | 4       | const | 5544 |       |
+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+

看起来已经用上索引了，而这条SQL语句已经简单到让我无法再优化了。最后请前同事Gaston诊断了一下，他认为：数据分布上，group_id相同的比较多，uid散列的比较均匀，加索引的效果一般，但是还是建议我试着加了一个多列索引：

ALTER TABLE user_group ADD INDEX group_id_uid (group_id, uid);

然后，不可思议的事情发生了……这句SQL查询的性能发生了巨大的提升，居然已经可以跑到0.00s左右了。经过优化的SQL再结合真实的业务需求，也从之前2.2s下降到0.05s。

再Explain一次：

+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+
| id | select_type | table      | type | possible_keys         | key          | key_len | ref   | rows | Extra       |
+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+
|  1 | SIMPLE      | user_group | ref  | group_id,group_id_uid | group_id_uid | 4       | const | 5378 | Using index |
+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+

原来是这种叫覆盖索引（covering index），MySQL只需要通过索引就可以返回查询所需要的数据，而不必在查到索引之后再去查询数据，所以那是相当的快！！但是同时也要求所查询的字段必须被索引所覆盖到，在Explain的时候，输出的Extra信息中如果有“Using Index”，就表示这条查询使用了覆盖索引。

不过，还有一个无法解释的问题就是，不用覆盖索引的情况下，为什么用MyISAM就快那么多，而InnoDB就慢这么多呢？求真相……

延伸阅读：

• High Performance MySQL, 2nd Edition. O’Reilly.  P120
• MySQL之Covering Index
• Covering indexes
• MySQL Explain
• InnoDB internal – 感谢@mysqlops推荐

一次神奇的MySQL优化 | 评论数(5)，添加评论
本文网址：http://xiaobin.net/201109/strange-sql-performance-problem/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

但是跟踪Apache+mod_php5相对就麻烦一些，因为没有独立的PHP进程。如果对httpd守护进程进行strace的话，只会获取到Apache本身的一些系统调用，如查找.htaccess，得不到PHP的系统调用。

有个老外分享了一个视频，跟踪主要分三步：

1. 通过Telnet与Apache建立连接，但是不要立刻就发送HTTP请求（可以写入头HTTP头，但不要连续两次回车），以免连接过快被断开了；
2. 新开一个ssh session，root运行

   lsof -p `pidof telnet` | perl -nle 'print "netstat -anp | grep $1" if m/:(\d+)->/' | sh | perl -nle 'print "strace -p $1" if m/(\d+)\/httpd/' | sh

3. 回到Telnet，发送HTTP请求

具体看视频（自备梯子）：

strace跟踪apache mod_php5的系统调用 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201107/strace-apache-mod_php/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

当你要两台机器之间拷贝一些大文件的时候，把nc(netcat)和pigz(parallel gzip)组合起来会是一个简单和高效的选择。不过，如果要把这些文件同时分发到多台机器，有什么好法子吗？在Tumblr，这还算蛮常见的需求，比如我们要快速的同时增加几台MySQL Slave的时候。

你可以从源机器逐个拷贝到逐台目标机器，但是往往时间也是成倍的。或者你也可以同时从源机器同时拷贝到多个目标机器，但是受制于源机器的带宽等因素，速度并不见得真的很快。

还好，借助一些UNIX工具可以做的更好。把tee和FIFO组合起来，可以形成一个文件快速分发链：处于分发链中的每台机器会保存文件，同时还分发给它的下一环。

首先，选定一台目标机器做为分发链的最后一环，在这台机器上只需要用nc监听（假定端口是1234），再通过管道由pigz解压缩，继续通过管道把数据交由tar来分解。

nc -l 1234 | pigz -d | tar xvf -

然后，再从分发链的末端往上走，设置其它目标机器，同样要经过监听、解压、分解，不过在解压之前我们通过tee命令将数据输出到命名管道(FIFO)，另外的一条shell管道会将这些未解压的数据同时分发到分发链的下一环：

mkfifo myfifo
nc hostname_of_next_box 1234 nc -l 1234 | tee myfifo | pigz -d | tar xvf -

最后，在源机器上启动分发链，让数据传输到分发链的第一环：

tar cv some_files | pigz | nc hostname_of_first_box 1234

在我的测试中，分发链中的每台机器大概损失了3%-10%的性能（相对于1对1的拷贝而言），但是相对逐个逐个的拷贝或者单台机器向多台机器同时分发，效率提升是很明显的。

—

延伸阅读：

• 网络版瑞士军刀nc作弊条
• Linux cloning over the network using netcat

高效的大文件拷贝 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201107/efficiently-copying-files-to-multiple-destinations/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

|-- index.php
`-- lib
    |-- a.php
    `-- b.php

假定有三个文件，入口文件index.php，包含lib/a.php。a.php又需要包含它同目录下的b.php：

• 方式1：include(“./b.php”) – 不工作
• 方式2：include(“b.php”) – 正常

我们通过strace来跟踪一下方式2的系统调用（我的环境下include_path=.:/tmp）：

open("/home/robin/devel/lib/a.php", O_RDONLY) = 3
open("/home/robin/devel/b.php", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/tmp/b.php", O_RDONLY)            = -1 ENOENT (No such file or directory)
open("/home/robin/devel/lib/b.php", O_RDONLY) = 3

官方文档的阐述是这样的：

Files are included based on the file path given or, if none is given, the include_path specified. If the file isn’t found in the include_path, include() will finally check in the calling script’s own directory and the current working directory before failing.

所以优先级应该是这样：

1. 有指定路径的话（如：”./”或者是”../”或”/home/…”），将直接根据路径来查找文件；
2. 没有指定路径的情况
1. 遍历include_path查找，include_path中有“.”开头的话，则指的是CWD(Current working directory，即是例中的index.php所在的目录)
2. 在calling script(也就是例中的a.php)所在的目录查找
3. 在CWD目录查找 – 不过在测试的时候发现似乎没有做到这一样。很容易测试：把include_path设成”/”避免其中有“.”，也就避免根据include_path方式查找到文件，再把b.php移到index.php同一级目录，结果包含不到。

参考及延伸阅读：

include(“./file.php”)和include(“file.php”)区别 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201107/difference-between-with-or-whitout-prefix-dot-while-include-file/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

ln -sf                                                      \
    $(                                                      \
        echo $(                                             \
            [                                               \
                "$(md5sum oauth.so | awk '{print $1}')"     \
                    = ae8268ac08af61065d2a878ef657835d      \
            ]                                               \
            && echo "oauth-1.0.so" || echo "oauth-1.2.so"   \
        )                                                   \
    )                                                       \
    oauth.so

Symbolic link target toggle | 暂无评论，添加评论
本文网址：http://xiaobin.net/201107/symbolic-link-target-toggle/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。

1. 在客户端运行ssh-agent并启用agent转发；
2. 通过SSH登入服务器，服务器端会在临时文件夹生成auth socks文件A，并将A的路径写入环境变量SSH_AUTH_SOCK；
3. 运行”screen”进入到GNU screen， screen会继承环境变量，读入环境变量SSH_AUTH_SOCK；
4. 将screen会话挂起，退出服务器，这时socks文件A将会被销毁；
5. 再一次通过SSH登入服务器，服务器会生成新的auth sock文件B；
6. 恢复screen会话，但是由于恢复screen时不会再刷新环境变量，SSH_AUTH_SOCK的值仍然是A，但是socks文件A却早就被移除掉了，ssh-agent也就失去作用；

我目前的做法是，在.bashrc增加一段代码，每次在进入bash shell时会建立一个软连接指向当时的auth socks文件，然后将SSH_AUTH_SOCK环境变量的值设置为软连接的地址，问题得以解决：

agent_file=/tmp/ssh-agent-$USER.sock

if [ "$SSH_TTY" -a "$SSH_AUTH_SOCK" -a "$SSH_AUTH_SOCK" != $agent_file ]; then
    ln -sfn $SSH_AUTH_SOCK $agent_file
    export SSH_AUTH_SOCK=$agent_file
fi

# 同时增加了一个函数，方便重建软连接，有些情况下用得着。
update_ssh_agent() {
    for sock in /tmp/ssh-*/agent*
    do
        if [ -S $sock ]; then
            ln -sfn $sock $agent_file
        fi
    done
}

SSH Agent与GNU Screen的兼容问题 | 暂无评论，添加评论
本文网址：http://xiaobin.net/201107/the-problem-between-ssh-agent-and-gnu-screen/
将之典藏 - 厚积而薄发，© 2005-2011. 如无特别声明，适用署名-非商业性使用-相同方式共享 3.0授权，你可以署名使用全部或者部分内容用于非商业性目的。