$ brew install libtiff
$ brew install --HEAD webp

~/Library/Application Support/Adobe/Lightroom/Export Actions

#!/usr/bin/env ruby

require 'logger'

logger = Logger.new('/tmp/webplog')
logger.info ARGV.inspect

begin
	ARGV.each do |f|
		dir = File.dirname(f)
		out = File.join(dir, File.basename(f, ".tif") + '.webp')
		logger.info "%s => %s" % [f, out]
		IO.popen([
			'/usr/local/bin/cwebp',
			'-metadata', 'all',
			'-preset', 'photo',
			'-q', '90',
			'-o', out,
			'--',
			f
		], :err=>[:child, :out]) do |io|
			while l = io.gets
				logger.info l.chomp
			end
		end
	end

rescue Exception => e
	logger.fatal e.inspect
end

1. トップ
2. tech
3. Lightroom で webp の一発書きだし

リバースプロキシとして使っている h2o で

proxy.reverse.url: http://localhost:5001/

みたいに書いていたら確率的に connection failure がでて悩んだ。結局

proxy.reverse.url: http://127.0.0.1:5001/

で解決

1. トップ
2. tech
3. h2o の proxy.reverse.url で localhost を指定していたら確率的に connection failure

start_server が listen してないポートは以下のようなエラーになる。

cp socket:(null):80 is not being bound to the server

h2o は SIGHUP で graceful restart が可能だが、listen するポートが変わった場合は実際にlistenしている親プロセス (start_server プロセス) の再起動が必要になる。

1. トップ
2. tech
3. h2o で listen するポートを増やしたときは master プロセスの再起動が必要

これまで HTTPS (443) だけ h2o で処理していたが、nginx に使ってるぶんのメモリ量がMOTTAINAIのでh2oだけでやるようにした。さようなら nginx。

複雑なことをしているホストは全くなかったので普通に書きかえていっただけ

1. トップ
2. tech
3. nginx をアンインストール

最初からアドレスついてたので意外とやることない。

ifconfig すると既に v6 のアドレスがついている。Scope:Global になっているやつがグローバルIPアドレス (正確にはグローバルユニキャストアドレス)

inet6 addr: 2001:e42:102:1807:160:16:210:51/64 Scope:Global

これを該当ドメインの AAAA レコードでひけるようにする。

server {
    listen   80; 
    listen [::]:80;
    ...
}

1. トップ
2. tech
3. さくらのVPSのウェブサーバでIPv6の接続をうける

どのぐらいまで生きていられるのか気になったので試してみる。wrk を使う (ab だとうまく高負荷にできなかった) wrk は brew で入る。

ベンチの際いくつか注意する

• Transfer/sec が十分に低いこと
  • 帯域を使いきってると負荷をかけきれない
• Non-2xx or 3xx responses がではじめたら限界
  • 発生しなかったときは表示されない

$ wrk -c 170 -d 10s -t 16 https://...
Running 10s test @ https://...
  16 threads and 170 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   164.27ms   64.53ms 852.22ms   80.26%
    Req/Sec    61.56     22.99   170.00     72.60%
  9278 requests in 10.10s, 44.31MB read
  Non-2xx or 3xx responses: 22
Requests/sec:    918.52
Transfer/sec:      4.39MB

日記システムは、これぐらいでCPUは使いきってちょいちょいエラーが発生する感じだった。

ヤフー砲が瞬間最大で100req/sec、継続的に30req/secぐらいらしいので、現実的にはこの日記が負荷で死ぬことはまずなさそう。他のサービスも同居してて相互に影響してる(バックエンドプロセスのワーカーを共有してる)けど。

1. トップ
2. tech
3. サイトの負荷のシミュレーション

サーバ移行のタイミングでつかいはじめた。監視をちゃんとするようにしようという感じ。loadavg5 と filesystem でひとまず監視。メトリクスの保存とグラフ化はフリープランだと1日だけなのであまり重視してない。

しかし、さくらのVPSはホスト不具合で落ちるってことは滅多にないので、やりたいことはサーバ自体の死活というよりウェブサーバの監視になる。このへんはプラグインでごにょごにょやってみている。パフォーマンス(応答時間のパーセンタイル値とか)とエラー数あたりでアラートが出せればいいかなという感じ。

1. トップ
2. tech
3. Mackerel つかいはじめた

高誘電体 MLCC は容量が時間経過で減少していくが、約125度(キュリー温度)まで加熱すると容量が回復する特性がある、らしい。

エージングで容量が減っていくというのはいいとして、一定より温度をあげると回復するというのを知らなかったのでびっくりした。

PS3/PS4 の修理方法でとにかくホットブローするみたいなのがあるけど、はんだクラックだけではなくて容量回復するという意味合いもあるのだろうか。

1. トップ
2. tech
3. チップコンデンサ(MLCC)の容量回復