sitemap.xml を送信した翌日ぐらいに Googlebot からの連続したアクセスがくるようになる。Googlebot は HTTP/1.1 で Keep-Alive が有効なため、普段にパラパラくるアクセスよりも、このときのように連続してアクセスされる場合、多くの場合でコネクション時間がなくなるために高速にレスポンスを返せる。

連続したアクセスの場合、2分ぐらい Keep-Alive している。

これは結果として Search Console の「クロールの統計情報」に表示されている「ページのダウンロード時間 」のグラフにも反映されているような感じで、sitemap.xml を追加した次の日あたりで平均ダウンロード時間がかなり少なく表示される。

1. トップ
2. tech
3. Google Search Console のページのダウンロード時間

Server::Starter は hot deploy 用の汎用スーパーデーモンで、Perl で書かれています。h2o の起動にも使われているのでみなさんおなじみでしょう！

Server::Starter がやってることは、Server::Starter 側で listen したソケットの fd を環境変数につっこんで子プロセスを起動というものです。子プロセス側では渡ってきた環境変数を読んで、fd について accept すれば良いことになります。

これを node.js でやるには以下のようにすれば良いようです。

//#!/usr/bin/env node
"use strict";

const http = require('http');

const server_starter_port = process.env['SERVER_STARTER_PORT'];
if (!server_starter_port) {
	console.log('SERVER_STARTER_PORT is not set');
	process.exit(1);
}
const fds = server_starter_port.split(/;/).map( (i) => i.split(/=/) );

const server = http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
	res.end('Hello World\n');
});

process.on('SIGTERM', () => {
	console.log('server exiting');
	server.close();
});

for (let fd of fds) {
	console.log('listen', fd);
	server.listen({ fd: +fd[1] });
}

起動はたとえば以下のように

start_server --port=5001  -- node server.js 

http.Server の listen() のドキュメントには fd を渡せるバージョンが書いてありませんが、net.Server の listen() がサポートしているので、同様に渡せるようです。

これだけで node.js のプロセスの hot deploy が簡単にできます。

1. トップ
2. tech
3. Server::Starter を node.js のサーバ起動に使う

このサーバはVPS 1台で動いていて、メモリは1GBしかありません。常時メモリ上限まで使いきっており、スワップファイルもそこそこあります。そういうわけで、できるだけメモリ消費をケチりたいのです。

builder {
    mount 'http://lowreal.net' => do {
        my $guard = cwd_guard("lowreal.net/");
        Plack::Util::load_psgi("script/app.psgi")
    };
    mount 'http://env.lowreal.net' => do {
        my $guard = cwd_guard("env.lowreal.net/");
        Plack::Util::load_psgi("script/app.psgi")
    };
};

export KILL_OLD_DELAY=15
export ENABLE_AUTO_RESTART=1
export AUTO_RESTART_INTERVAL=3600

exec setuidgid cho45 \
        $PERL/bin/start_server --path=/tmp/backend.sock --port=5001 -- $PERL/bin/plackup -p 5001 -s Starlet\
        --max-workers=5 \
        --max-reqs-per-child=500 \
        -a backend.psgi

shared-memory-size.pl `pgrep -f /srv/www/backend.psgi`
PID     RSS     SHARED
29583   55460   47792 (86%)
29584   55760   44688 (80%)
29585   65224   41396 (63%)
29586   56280   44704 (79%)
29587   55352   44660 (80%)
29588   58908   46748 (79%)

1. トップ
2. tech
3. 複数の psgi を1つのサーバでサービスするときにメモリをケチる

アクセスログを見ていたら Applebot なるものからのアクセスがあった。

https://support.apple.com/ja-jp/HT204683

ほんとに Apple のウェブクローラらしい。ただ

と書いてあって、それはどうなんだ、という感じがする。

1. トップ
2. tech
3. Applebot

今までのページャは良くある ?page=2 みたいな形式でした。これは内部的には offset / limit を使う SQL になります。

変更したページャは /.page/20160509/3 という形式です。20160509 が表示するページ番号、3 がそのページに表示する最大の数です。ページ番号はトップページからのページの場合、日付になっており、内部的には日付ベースの where 句になります。3 は limit です。

これらによって、サーバ側のエントリ表示数のデフォルト設定によらず、URLによって決まる内容が生成されます。よって

• キャッシュ無効化の負荷が減る
  • 古い形式だと ?page=xxx なキャッシュは1つエントリが増えるたびに全て無効にしないといけません
• 古いページを表示したときの負荷が減る
  • offset / limit はそのページに至るまでの全てのエントリをソートして辿る必要があるので古いページをページ指定すると不穏な空気が流れます
• 検索流入したとき見たいコンテンツがないことが防げる

1. トップ
2. tech
3. ページャの実装変更