Shibuya Perl Mongers テクニカルトーク #17 に参加して #shibuyapm
6/2 に開催された Shibuya Perl Mongers テクニカルトーク #17 に参加してきました。
自分は初参加だったのですが、なんと前回開催から4年ぶりの開催とのこと。
「もうみんな Perl なんて書いてませんよね」というアイロニーな雰囲気が漂いつつも、「やっぱり Perl 書いてる」という人もたぶん 40% 以上ぐらいはいて、LT の盛り上がり具合から見てもみんな Perl が好きなんだなと感じるひとときでした。
以下、セッションの内容になります。
一部資料はネットにアップされているようです。 観測範囲で捕捉したものは、順次本記事にも追加していきます。
例によって愚直にメモを取っていたら、かなりの分量になってしまったのですが、あまり削ったりせずに、ほぼそのまま上げておきます。
開会の挨拶
@takesako さん
- 前回 - 正規表現祭り 2011/7月
- shibuya.pm のサイト
- blosxom 2008/10/2 released
- アンケート結果
nginxのパフォーマンスチューニング
@cubicdaiya さん
- 自己紹介
- Author of nginx-build, ngx_small_light, ngx_dynamic_upstream
- WEB+DB PRESS vol.72 - nginx 特集
- mozaic.fm #18 出演
- Agenda
- nginx.conf
- デフォルトだと保守的な設定が多い
- ディレクティブたくさんある
- core だけで70個以上
- core functionality
- worker_processes - ワーカプロセス数
- worker_connections - ワーカごとのコネクション数
- worker_rlimit_nofile - OS依存だったり
- worker_processes
- cpu コア数目安に
- auto にしておけばコア数になる
- 接続数に応じて大きくする
- CPUバウンドになりそうならさらに大きめにする
- cpu コア数目安に
- worker_connections
- 通常は1024 - 8192
- 万単位でもいけそうだけどやったことない
- worker_processes とセットで考える
- ※プロキシ先の接続数も含まれる点に注意
- 通常は1024 - 8192
- worker_rlimit_nofile
- fd の最大数
- 65535
- sendfile
- sendfile システムコールの有効化
- デフォルト無効
- 基本 ON でいい
- keepalive_timeout
- クライアントとの keep-alive 通信
- open_file_cache
- 一度開いたファイル情報をキャッシュ
- ファイルのfd, サイズ、更新日時
- `open_file_cache max=100 inactive=20s;``
- 一度開いたファイル情報をキャッシュ
- tcp_nodelay
- tcp_nopush
- TCP_NODELAY, TCP_NOPUSH
- 本来、相反する動き
- NODELAY - パケットをできるだけ即座に送信する
- NOPUSH - できるだけまとめて送信
- 全部有効にすると一番効率がいい
- パフォーマンスに影響する listen パラメータ
- spdy - SPDY
- backlog=N - listen backlog
- net.core.somaxconn 等も忘れずに
- fastopen=N - TCP Fast Open
- nginx と h2o のベンチマーク
- c4.8xlarge on EC2
- h2o-1.2.1-alpha1
- nginx-1.8.0
- h2o.conf (最適化前)
- h2o.conf (最適化後)
- num-threads: 16
- max-connection - 10240
- nginx.conf (最適化前)
- worker_processes: 1
- nginx.conf (最適化後)
- 結果
- 最適化前だと h2o が圧倒的
- 最適化すると Nginx がちょっと速い
- nginx と gzip 圧縮
location ~ ... { gzip_static always; gzip on; }
- zopfli で更に圧縮
- deflate 互換の圧縮...アルゴリズム
- nginx とバッファリング
- バッファリングの On/Off
- proxy_buffering (default: on)
- ストリーミング相当の処理をする際は off にするか要検討
- proxy_request_buffering (default: off)
- 大きなファイルのアップロードがあるときに on にするか?
- proxy_buffering (default: on)
- バッファリングと I/O
- nginx の各バッファのサイズは比較的小さめ
- だいたい数KB
- バッファが足りなくなるとディスクに書き出す
- tmpfs 使う
- nginx の各バッファのサイズは比較的小さめ
- バッファリングと tmpfs
- 書き出し先を選ぶディレクティブがある
- HTTPS 関連のチューニング
- バッファリングの On/Off
- まとめ
H2Oのパフォーマンスか機能に関する未発表の何か(仮)
@kazuho さん
- How h2o started
- 2014末ごろ公開
- HTTP/1, 2 サポート
- 高パフォーマンス
- Benchmark
- Nginx との比較
- PicoHTTPParser
- Plack の中で使われている HTTP Parser
- node で書かれたものの 5倍ぐらい速い
- h2o 設計哲学
- 良い設計で一からコードを書く
- picohttpparser - code 量小さい
- 良い設計で良いパフォーマンスを出す
- h2o 設計
- イベント・ドリブン
- マルチスレッド
- Nginx はマルチプロセス(?)
- multi-protocol
- 最初から HTTP/2 , TLS サポート
- h2o の目的
- 速いこと
- IoT, microservice, ...
- ユーザ体験の向上
- 使いやすい, 設定が楽
- chacha20/poly1305 - Chrome の暗号化スイート
- OpenSSL には入ってないけど
- 動的に設定変更可能
- chacha20/poly1305 - Chrome の暗号化スイート
- 速いこと
- 主な機能
- h2o を使うことで UX 向上するのか
- HTTP/1 の問題 <= HTTP/2 で修正された
- HTTP/2 の優先度付け
- ベンチマーク取ってみた
- 環境
- HEAD の中に css x 5, JS x 8
- 18 個のアセットファイル
- network - 4G 相当
- Nginx (HTTP/1.1) + Chrome
- 1.8 sec
- Nginx (SPDY/3.1) + Chrome
- 1.8 sec ちょい
- h2o (HTTP/2) + Chrome
- 1.8 sec ちょい
- Why ?
- Chrome の優先度付けの制限による
- h2o (HTTP/2 + repriotize:ON) + Chrome
- Nginx (HTTP/1.1) + Firefox
- Nginx (SPDY/3.1) + Firefox
- 1.9 sec 遅くなった
- h2o (HTTP/2) + Firefox
- 1 sec 未満 ★★ <= Firefox の優先度付けが賢いので
- 環境
- ベンチマークまとめ
- h2o で速くなる
- 結論
- h2o + HTTP/2 で速くなる
- ベンチマーク取りましょう
- 今後
- v1.3 - 今週?
- 今日紹介した http2-repriotize-blocking-assets
- FastCGI サポート
- v1.3 - 今週?
- Q&A
- h2o 以外の HTTP/2 サーバ実装
- nghttp2 - サーバ/クライアント両方使える
- 日本はどうなのか
- http2study
- 海外の技術者も日本の人にお世話になってる
- Debug どうするの?
- h2o 以外の HTTP/2 サーバ実装
LT
スライド(発表資料)
Test::WWW::Stub from ast_j
https://speakerdeck.com/shoichikaji/debug-perl
ppencode 2 - ppencode @shinh
聴講メモ
- ドキッ!記号だらけの無名関数 - @tsurumau
- lambda を定義、呼びだそう
- 準備
- カッコのみ
- [], (), {} ... OK
- 組み合わせると NG
- ()[()] ... OK
- カッコのみ
- リストをリストコンテキスト以外で評価したときのアレ
("foo")[()] # "" scalar(("foo")[()]) # foo (sub{"foo"})[()] # foo (sub{"foo"})[()]->(1) # runtime error
- perl 楽しい
- %1 => sub { $_[0] }(仮) - @tokuhirom
- タイトル変えた - Server::Starter meets Java
- Server::Starter
- server を起動するサーバ
- graceful restart できる
- 無停止で hot deploy
- Java では?
- 無理そう・・・?
- System.inherit...
- inedtd support のため
- Server::Starter が socket を 0番で渡してくれればいい
- --port=8080=0
- port:8080, fd:0
- できた!
- Java の ver-up 安全にできる
- ClassLoader 使うとリークするけど、これならそういう問題ない
- OS X だと動かない
- inetd が有効でない
- DEMO
- Perlでコマンドラインサーバを書いてCPANモジュールに同梱する - @songmu
- 🍣現状確認会用ネタ - @tomita
- API request/response tests
- PHP からやりたかった(?)
- PPI
- Perl to PHP
- Perl to JavaScript
- http://perlingual.koneta.org/
- なでしこにも変換できる
- Inner World of Perl::Lint - @moznion
- APIクライアントを作ろう! @__papix__
- APIクライアント
- Reactio
- 名前空間
- Net, WebService, WWW
- どれ使うの?
- Net - ネットワークプロトコル
- WebService, WWW - アプリケーション
- 依存ライブラリ
- 少ないに越したことはない
- WebService::Simple
- クライアント用のシンプルなフレームワーク
- テスト
- ドキュメント
- SYNOPSIS 書く
- eg/ にサンプル置く
- APIクライアント作ろう
- Test::WWW::Stub のご紹介 @ast_j
- Gazelle & CPAN modules for performance. @kazeburo
- Perl で debug してわかったこと @ks0608
- ドキュメントの生成とか @toku_bass
- one source code で「複数のサービスに対応するが schema 構成は微妙にに違います」という要件に直面したら開発はどうすればいいのか、僕なりに何日か考えた上でのややベターな結論のようなもの @Yappo さん
- ppencode2 @shinh
- ppencode 2 - ppencode2 デモサイト
- 昔 ppencode というのがあった
- ppencode - JavaScript demo
- 実装は割とかんたんで、1文字ずつ print するといい
- 予約後だけで任意コード実行したい
- できそうで意外と難しい
- 10年が経った
- Yuine
- Quine の亜種みたいな
関連リンク
- Shibuya.pm#17でnginxの話をしました - 考える人、コードを書く人 ... スピーカーの @cubicdaiya さんのブログ
- Kazuho's Weblog: HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY ... スピーカーの @kazuho さんのブログ
- Redirecting… ... LT発表者 @tomita さんのブログ
- ppencode2 - 兼雑記 ... LT発表者 @shin さんのブログ