DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
任意のコマンドのサブコマンドにエイリアスを設定できる salias をつくった - blog.syfm
動機 最近のコマンドは大抵サブコマンド形式になっています。 $ docker pull hello-world このように、コマンド名 + サブコマンド + 対象 みたいな形式。 サブコマンドには大きく2種類あって、サブコマンドに動詞を指定するタイプと、リソースを指定するタイプがあります。 感覚的に、コマンドのパターンが多くなってくるとリソースを指定するタイプが主流になっている気がします。 最近だと Docker が以下のように動詞タイプからリソースタイプに移行しつつあるようです (現在はどちらのコマンドも利用できる) $ docker run hello-world # 動詞タイプ $ docker container run hello-world # リソースタイプ 動詞タイプのほうがタイプ数は少ないが、リソースタイプのほうが階層化されているので秩序がある。 とはいえ、割りと頻繁に利
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
