isweb time

04300

iswebに接続を試みると、負荷分散を行なっているためだと思いますが、
つなげるたびに、SERVER_ADDRが変わるようです。
サーバー間で数分の違いが存在するようですし、
2003/10/05の段階では、９時間づれていたものを一台見つけました。

iswebさんの方で10/7 PMに、サーバー間の時間合わせを行ってくれたようです。
現在(2003/10/11)、極端な時刻のずれはありませんが、運が悪ければゲームCGI等で
time関数を使用している場合、10秒程度は間違って計測しそうです。
時間の経過と共にこの差がどうなるかモニタする必要がありそうです。

ただ、調べてみたところファイルのアクセスタイムに関しては、
SERVER_ADDRの違いに依存しないようです。

http://midoriya-web.hp.infoseek.co.jp/cgi-bin/iswebtime/iswebtime.cgi
にて確認できます。LOGは、
連番　file:file作成時刻　time:アクセス時刻　SERVER_ADDR:file-time
となっています。

アクセス時に作成したファイル時間が【file:file作成時刻】、
次がtime関数で求めたサーバーの時間【time:アクセス時刻】です.
【file:file作成時刻】は、単純増加で、逆戻りは観測されません。

以下の内容は、サーバー時刻の設定に大きな不具合が観測された、2003/10/05のデータに関してのものです。
この不具合は、2003/10/07に一旦、解消されています。

2003/10/05(Sun) 12:14:56 - 2003/10/05(Sun) 18:15:34の120件のLOGを次のリンクで参照できます。
iswebtime.txt

SERVER_ADDR=172.20.4.70 のログ、1,2,23をみると、
time:アクセス時刻が、file:file作成時刻に比べて、９時間進んでいることがわかります。

23	file:2003/10/05(Sun) 13:26:12	time:2003/10/05(Sun) 22:30:29	172.20.4.70:-32657
2	file:2003/10/05(Sun) 12:15:01	time:2003/10/05(Sun) 21:19:18	172.20.4.70:-32657
1	file:2003/10/05(Sun) 12:14:56	time:2003/10/05(Sun) 21:19:13	172.20.4.70:-32657

それ以外のマシンでも5分以上進んでいるものが結構あるようです。

また、3,4,5の【time:アクセス時刻】が、戻っていくのがわかります。

5	file:2003/10/05(Sun) 12:15:44	time:2003/10/05(Sun) 12:20:02	172.20.4.52:-258
4	file:2003/10/05(Sun) 12:15:36	time:2003/10/05(Sun) 12:20:36	172.20.4.74:-300
3	file:2003/10/05(Sun) 12:15:24	time:2003/10/05(Sun) 12:21:09	172.20.4.75:-345

すなわち、３から４に行く際に、【file:file作成時刻】は、
2003/10/05(Sun) 12:15:24　→　2003/10/05(Sun) 12:15:36
と12秒進んでいるにもかかわらず、【time:アクセス時刻】が
2003/10/05(Sun) 12:21:09　→　2003/10/05(Sun) 12:20:36
と、33秒戻っています。

これ以外にも、
(13,14)(35,36)(64,65)(84,85)(88,89)(90,91)(96,97)(99,100)(118,119)
に、時間の逆戻りが見られます。

上記、プログラムのソースは、
http://midoriya-web.hp.infoseek.co.jp/cgi-bin/iswebtime/src.txt
にて、参照できます。
（生ログ： http://midoriya-web.hp.infoseek.co.jp/cgi-bin/iswebtime/iswebtime.txt）

iswebのサーバーにてファイルのアクセス時刻と、
timeで求めた時刻の間に、結構な違いが発生しています。

同時アクセスによるログ破壊を回避する為に、
lock処理を行いますが、この差が60秒以上あると、
以下のロジックでは、実質上、ロックが無効になってしまうのでは？

sub lock {
	# 1分以上古いロックは削除する
	if (-e $lockfile) {
		local($mtime) = (stat($lockfile))[9];
		if ($mtime < time - 60) { &unlock; }
	}

ここは思い切って600(10分程度)くらいにした方がいいかもしれませんね？

		if ($mtime < time - 600) { &unlock; }

本サイトで配布している、『夢カウンタ for isweb』および『Flushカウンタ用DayX for isweb』では、
次のような修正を行いました。

	if (-e $lockfile) {
		my ($mtime, $ctime);
		if ($ENV{'HTTP_HOST'} =~ /infoseek\.co\.jp$/) {
			if ($lockkey != 1) { &error; }
			link "$lockfile", "$lockfile.infoseek";
			unlink ("$lockfile.infoseek");
			($mtime, $ctime) = (stat($lockfile))[9..10];
		} else {
			($mtime) = (stat($lockfile))[9];
			$ctime = time;
		}
		if ($mtime < $ctime - 60) { &unlock; }
	}

現在(2003/10/11)は、極端な時刻のずれは解消されているので60のままで問題ないと思われます。
ただ、「古いロックは削除」という処理の発生理由等を考慮すれば、10分程度にしていても実害はないでしょう

現在(2004/01/18)は、3分以上の時刻のずれが観測されていますので60のままでは問題があると思われます。
ただ、「古いロックは削除」という処理の発生理由等を考慮すれば、600(10分程度)にしていても実害はないでしょう