komake: Make の -j オプションに潜む罠とその解決策
ビルドツールのダジャレの大家と言えば @shinh さんですが、それはさておき、皆さんは今でも Make を使ってビルドすることが多いと思います。かく言う私も、その一人。 最近は CPU のコア数も多いですから、当然 -j 16 とか、やりたいわけです。大きいプロジェクトになればなるほど、威力絶大ですね。 ですが、ここで問題がひとつ。大規模プロジェクトでは Makefile が別の Makefile を呼び出すような依存関係が良く見受けられます。この際、ターゲット間の依存関係で菱形が存在すると（例: ターゲット sub1 と sub2 が shared に依存）、make shared が make sub1 と make sub2 から同時に起動されることが起こりえます。CMake で生成した Makefile の場合も、ターゲット毎に make を起動しますね。 二重起動が発生すると、
mmapを使ってファイルベースの巨大なバッファを確保する話
小さなバッファはインメモリでもつが、メモリに収まらないような大きなバッファはテンポラリファイルを作り、file I/Oでアクセスする、というのが昔からの汎用的なバッファ実装のアプローチ。 だが、バッファに格納するデータ量によってアクセス手段を変えるというのはめんどくさいし、そこを抽象化すると無駄なオーバーヘッドが発生する。 幸いなことに最近は、メモリ空間が広い 64bit CPU だけ考えればいい。なので、ファイルの「読み込み」については、めんどくさいから全部mmapするというのが一般的なアプローチになってきている（例: LLVMのリンカであるlld）。 同様のことが、テンポラリファイルを使う可変長のバッファについても可能であり、h2o では実際に実装している。詳しくは h2o_buffer_reserve 関数の実装を見てもらえばいいと思いますが、ざっくりとした手順は以下のとおり： ▪️
Name Constraints を使った独自CAの運用手順
ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 本稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva
Optimizing performance of multi-tier web applications using HTTP/2 push
Optimizing performance of multi-tier web applications using HTTP/2 push Push is a feature of HTTP/2, that allows a server to speculatively send response to a client, anticipating that the client will use the response. In my earlier blogpost, I wrote that HTTP/2 push does not have significant effect on web performance when serving static files from a single HTTP/2 server. While that is true, push d
Using H2O with Let's Encrypt
Let's Encrypt is a new certificate authority that is going to issue certificates for free using automated validation process. They have announced that they will enter public beta on Dec. 3rd 2015. This blogpost explains how to setup a H2O using the automated process. Step 1. Install the client % git clone https://github.com/letsencrypt/letsencrypt.git Step 2. Obtain the certificate If you already
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
H2O version 1.4.0 released with outstanding support for forward secrecy and load balancing (and the experimental mruby handler)
H2O version 1.4.0 released with outstanding support for forward secrecy and load balancing (and the experimental mruby handler) Today I am happy to announce the release of the H2O HTTP/2 server version 1.4.0. There have been a few changes and bug fixes from version 1.3.1 (that showed big performance improvements over the older generations of HTTP servers without support for request prioritization)
H2OとPHPを組み合わせるの、超簡単です（もしくはmod_rewriteが不要な理由）
FastCGI対応機能がH2Oにマージされたことを受けて、uzullaさんが「H2OでPHP（がちょっとだけ動くまで）」という記事を書いてくださっています。 ありがたやありがたや。 その中で、 http://hoge/entry/1 みたいなのをphpにマップする方法はまだよくわかってません。その内しらべます github.comを読む限り FastCGI (or PHP) applications should be as easily configurable as it is for the Apache HTTP serverということで、やったぜ！ってなるんですけど、nginxはもとより、Apacheにおいても現状ルーターをつかっているようなアプリだとhtaccessをいちいちかかないといけないので、Apacheみたいなスタイルが楽なのか？というとちょっと疑問があります。 （たと
HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY
HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY HTTP/2 is expected to offer better user experience than HTTP/1.1, the unanswered question is how much the benefit is in practice. Tonight I have given a presentation regarding the issue, showing HTTP/2 performance of H2O HTTP server at shibuya.pm, a popular technology meetup at Tokyo. This blog post is a summary of the presentation at
Kazuho's Weblog: HTTP/2 is much faster than SPDY thanks to dependency-based prioritization
HTTP/2 is much faster than SPDY thanks to dependency-based prioritization Background HTTP/2 provides two methods to prioritize streams (e.g. files being served). One method is called weight-based prioritization. In weight-based prioritization, every stream is given a weight, and the value is used by the server to proportionally distribute the bandwidth between the streams. The other method is depe
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
URL パーサにおける IPv6 対応
プログラマにとって IPv6 対応といえば、C言語のような低レベルな言語の話であって、ホスト名を文字列で扱うスクリプト言語には関係ないと考えがちです。ですが、実際には、文字列の取り扱いにおいても対応が必要になるところがあります。 その代表例が URL のパーサです。多くのエンジニアがイメージする URL の書式は「protocol://host:port/path#fragment」です。この書式を見れば、「:」と「/」を用いてトークンを分割するのが自然であり、RFC を参照せずに記述された URL パーサは、host の中に「:」が含まれないことを前提としていることがあります。あるいは、/[0-9A-Za-z_-\.]+/ のような正規表現を使って、ホスト名または IPv4 アドレスをチェックしている場合も多いのではないでしょうか。 ところが、IPv6 アドレスの文字列表現には「:」が含
プログラミング言語における正規表現リテラルの必要性について
Twitterに書いたことのまとめです。 プログラミング言語の仕様の一部として正規表現リテラルを提供することの得失について、JavaScriptを例に説明します。 ■より簡潔なコード 言うまでもありませんが、正規表現リテラルを使った方が簡潔なコードになります。 (new RegExp("abc")).exec(s) // リテラルを使わない場合 /abc/.exec(s) // リテラルを使った場合 また、正規表現リテラルがない場合は、文字列リテラルとしてのエスケープと正規表現としてのエスケープが二重に必要になる結果、コードの保守性が低下します注1。 new RegExp("\\\\n"); // リテラルを使わない場合 /\\n/ // リテラルを使った場合 ■エラー検出タイミング 正規表現リテラルがない場合、実際にその正規表現が評価されるまで記述エラーを検出することができません。正規表
GitHub で submodule ではなく subtree を使うべき理由
GitHub には、タグを打つとソースパッケージを自動的にリリースするという機能があります。スクリプト言語においては、それぞれの言語について一般的なパッケージ管理システム注1があるため、この機能を使うことが少ないかと思いますが、デファクトのパッケージ管理システムが存在しないC等の言語で書かれたプログラムや、単独で動作する管理用のスクリプトを GitHub で開発・配布する際には、本機能はとても便利なものです。 しかし、この機能は git-archive コマンドのラッパーとして実装されているため、サブモジュールのファイルが含まれないという問題を抱えています。この点は GitHub の人たちも認識しているものの、今のところ GitHub で独自に対応するということは考えていないようです注2。 私がこの問題を 知ることになったのは、picojson の issue で指摘を受けたからです。pi
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
[メモ] root権限でrsyncする方法
サーバの移転作業時など、rootしかアクセスできない設定ファイルやアクセス権を保ったままrsyncしたいことってありませんか？ そういった際には、sudo の -A オプションと rsync の --rsync-path オプションを使うと良いようです。 まず、リモートサーバに、パスワードを標準出力に出力するスクリプトファイルを配置します（ファイルのパーミッションを厳しくするのを忘れずに）。 % cat > bin/askpass #! /bin/sh echo "{{my_password}}" % chmod 700 bin/askpass % そして、rsync を実行する際には --rsync-path オプションを使い、リモートサーバの rsync を sudo -A 経由で起動するようにすれば良いのです。 % sudo rsync -avz -e ssh \ --rsync-p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git で全ブランチから検索
HTTP/2の課題と将来について、YAPC Hokkaidoで話してきた
Velocity in Amsterdam 2016 で HTTP/2 とその先にある最適化について話してきた