Category tech.

webp のインストール

homebrew で入れる。

$ brew install libtiff
$ brew install --HEAD webp
    • HEAD つけないとコンパイル済みの TIFF 非対応バイナリがインストールされるので注意

Export Actions にシェルスクリプトを置く

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

にスクリプトを置くと、書き出しダイアログで選べるようになる。書き出したあとスクリプトの引数に現像済みファイル名が渡されるので、これを処理するようにすればよい。

以下のようなファイルを webp.rb という名前で 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

Lightroom の書き出し設定

ファイル設定

  • TIFF
  • 8 bit/チャンネル

として

「後処理」で「webp」を選ぶ

で書きだし。

問題点

EXIF が消える。cwebp が TIFF の EXIF デコードに非対応のため

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

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

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

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

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

nginx

nginx -V の結果に --with-ipv6 があることを確認する。

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

という感じにして ipv6 側もlistenするようにする。

h2o

listen: 80 と書いてる場合、デフォルトで v6 も listen するようになっているのでやることはない。

DNS サーバの IPv6 対応

ここでの「DNS サーバの IPv6 対応」はDNS サーバへの通信が IPv6 でできるかという話になるが、value-domain の NS1.VALUE-DOMAIN.COM とか、さくらインターネットの ns1.dns.ne.jp は対応していないっぽい?

IPv4 で解決できるなら別に問題ないんだけど、IPv6 オンリーの環境 (あるの?) からだと名前がひけないことになる。

確認

http://ipv6-test.com/validate.php これが便利

備考

自分に IPv6 アクセス環境がないので、とりあえず1つのドメインだけ対応させた。現状ではとくに IPv6 の対応したからといってメリットがないのが微妙。。。

  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. サイトの負荷のシミュレーション