webpack のビルド性能を95%改善した方法(Boxの事例)

Box のエンジニアブログに「How we improved webpack build performance by 95%」という記事が投稿されました。
Box では、それまで3時間21分かかっていたビルド時間を9分に短縮させました。

  • シングルCPU
    • babel-loader でキャッシュを有効にして26%の性能改善
    • キャッシュを有効にして、 uglifyjs-webpack-plugin v1 で並列処理をして45%の性能改善
    • webpack.config.js から設定一覧をエクスポートしないようにして28%の性能改善
  • 10CPU
    • node.js Child Process API を使用して67%の性能改善

ビルドマシンにメモリ制限がある場合、webpack.config.js で設定一覧をエクスポートしない

Webpackはwebpack.config.js から複数の設定をarrayとしてエクスポートできます。
同時に25言語の bundle をビルドするのに、一つのロケールにつき1つで25設定のarrayをエクスポートするのに、この機能にメリットを感じていました。
小さな設定のみの場合はとても便利な機能なのですが、boxの場合は、ビルドプロセスにメモリと時間を非常に使います。
初期設定で、 –max_old_space_size (memory limit) のnodeプロセスでwebpackを実行するのに4GBにしていましたが、倍の8GBにしたら性能が50%改善し、ビルド時間が3.35時間から1.7時間に減りました。

同じメモリ制限では、各設定でwebpackを実行するように設定を変更すると、同時に複数の設定を処理する場合と比較して、パフォーマンスが約28%向上しました。

babel-loader でキャッシュを有効にする

babel-loader キャッシュは、cacheDirectoryオプションで簡単に有効にできます。

loader: 'babel-loader?cacheDirectory'

デフォルトでは、node_modules/.cache/babel-loaderに、babel-loaderキャッシュ結果が格納されます。
babel-loader キャッシュを有効にした後、ビルド性能が26%改善したました。

新しい uglifyjs-webpack-plugin v1 は大きな違いをもたらします

すでにwebpack 3で提供されている UglifyJSプラグイン(webpack.optimize.UglifyJsPlugin) を使用しているかもしれません。

新しいuglifyjs-webpack-plugin v1を使用して、 UglifyJS v3 で使用してwebpack 4で計画されています。
新しい機能は、複数プロセスで並列処理に対応し、キャッシュを活用しビルド性能を45%改善します。

現時点で、webpack 3で、 uglifyjs-webpack-plugin v1 を使用するためには、

  • devDependenciesに、「”uglifyjs-webpack-plugin”: “1.0.1”」を追加する
  • webpackから「-p」フラグを消し、「uglifyjs-webpack-plugin v0.4.6」が呼ばれないようにする

キャッシュと並列オプションをプラグインに追加します。

new UglifyJsPlugin({
   cache: true,
   parallel: true
})

マルチコアビルドのメリット

ビルドマシンが複数CPUを持っている場合、 node.js Cluster と Child Process API 、または worcker-fram を使用することでwebpackビルドにメリットがあります。並列に処理される9つのWebpack構成を有効にすることで、25の構成すべてをビルド性能が
67%改善しました。

Docker コンテナー起動エラー:driver failed programming external connectivity

Docker で次のようなエラーが出てコンテナーが起動できなくなってしまった時の対処方法。

ERROR: for lenet-lb  Cannot start service lb: driver failed programming external connectivity on endpoint lenet-lb (4d179b246b952fcf997b24b02c9027d0277c60feb9a3b65fef13af9c01c6a635): Error starting userland proxy: mkdir /port/tcp:0.0.0.0:443:tcp:172.18.0.7:443: file exists
ERROR: for lb  Cannot start service lb: driver failed programming external connectivity on endpoint lenet-lb (4d179b246b952fcf997b24b02c9027d0277c60feb9a3b65fef13af9c01c6a635): Error starting userland proxy: mkdir /port/tcp:0.0.0.0:443:tcp:172.18.0.7:443: file exists
ERROR: Encountered errors while bringing up the project.

結論としては、タスクバーにいるクジラマーク(Docker)のアイコンを右クリックして、「Quit Docker」でDockerを終了させたら復帰できた。ちなみに僕の時には、Mac OSの再起動では、エラーが解消しなかった。

困ったら、OSの再起動ではなく、DockerをQuitさせる。

re:dashのalertをSlackに通知する

re:dashでalertを設定し、その通知先としてSlackを設定することができます。

必要なもの

  • re:dashのadmin権限
    (これが無いと通知先設定ができないので、ない場合は管理者に依頼)

alert先の設定

1. Setttingページで、New Alert Destination ボタンをクリックします。
続きを読む “re:dashのalertをSlackに通知する” >

Symantec Endpoint Protection とHyper-V仮想マシンで必要な設定

「不一致IPトラフィックの設定」の「アプリケーショントラフィックのみを許可する」にチェックを入れたらいいらしい。

image

サーバーでポリシー制御してるので、Manager を開いて、クライアントを選択して、ポリシータブを選択。

場所固有のポリシーで、場所固有の設定で、クライアントユーザーインターフェース制御の設定を選択。

image

混合制御を選択し、カスタマイズボタンを選択する。

image

サーバーで制御に選択する。

image

クライアントユーザーインターフェースの設定タブを選択して、不一致IPトラフィックの設定を設定する。

image

Excel2016 にアップグレードしたときの注意点

Office 365 ProPlus で、Excel 2013 を使用していると、最近次の画像のように、「新しいOfficeをインストールしましょう」と表示されて、「Officeの更新」ボタンが表示されます。

76409b64-28f9-4138-a953-621cb5f52172

 

このボタンをクリックすると、Excel 2016にアップグレードできるのですが、一部問題が発生します。

言語の既定が変わってしまい、英語(米国)となってしまうようです。

08c69a0b-f228-4933-976b-0c0441bd6f1f

 

この状態で、一部文字コードでCSVをExcelで開いたときに、それまで問題なかったのに急に文字化けする事象に遭遇してしまいます。

おそらく、最新版へのインストールを促されるのですが、その際に使用されるインストーラーがen-usになっているのかもしれません。OSのロケール見て、ちゃんとja-JPのインストーラーが降ってくると良いですね。

 

ちなみに、言語の既定を日本語に変更すれば問題ないのですが、注意点が一個。
Excelファイルなどを開いてる状態でインストールしないことを強く推奨します。
開いているときに言語設定を変更すると、開いているファイルにも影響が出ます。
例えば、vlookup文法の中にある「’(シングルクォート)」が欠落してしまい、そのままの状態で保存してしまうと次回起動時に不正とみなされ修復ウィザードが動作してしまい数式が飛んでしまいます。悲しい…。