ZOZOTOWNにおける検索速度改善までの道のり - ZOZO TECH BLOG
こんにちは。ZOZOテクノロジーズZOZOTOWN部 検索チーム 兼 ECプラットフォーム部 検索基盤チームの有村です。 ZOZOTOWNでは先日公開した記事の通り、すべての検索をElasticsearchへ置き換えました。置き換え直後は順調に見えたのですが、実際に数%ずつリリースしていく中で一部時間帯、一部リクエストでレスポンス速度の低下がみられました。 本記事ではその解決のために行ったパフォーマンス調査、チューニング方法についてご紹介します。なお、一般的に行われるであろうElasticsearch本体のパラメータチューニングの話ではなく、クエリやmapping、setting面の話がメインとなります。 改善前後の速度について 詳細な内容の前に、本改善によるレスポンス速度の最終的な改善結果を示します。 今回の計測では、一定パターンのリクエストを10秒間繰り返し、95%tileのレスポンス
PostgreSQL 12β1が公開。Bツリーインデックス周りの性能向上や、インデックスの並列処理による再構成が可能に
オープンソースのデータベースであるPostgreSQLの次バージョンとなる「PostgreSQL 12」のベータ版が公開されました。このベータ版にはPostgreSQL 12最終版で予定されているすべての機能が搭載され、試せるようになっています。 PostgreSQL 12の主要な改善点を、ブログから一部引用します。 まずPostgreSQL 12では、インデックス周りの性能向上やサイズ削減などが行われているとのこと。 PostgreSQL 12 improves the overall performance of the standard B-tree indexes with improvements to the space management of these indexes as well. These improvements also provide a reductio
手元のコードのパフォーマンスを計測するperformance.markのスニペット
一部の機能をパフォーマンス改善したときにそれを計測したり、データを集めたいときがあります。 しかし、それだけのためにライブラリを追加するのも面倒くさい(実装後に計測コードは外すので)し、コンソールに結果を出すのもデータ収集的にイマイチです。 // よくあるコンソールに表示するパフォーマンス計測コード const start = performance.now(); // ------------ // 計測したい処理を書く // ------------ console.log(`${performance.now() - start}ms`); 結果をコピーしてSpreadSheetなどで可視化できたり、処理時間と関連する要素も保存しておきたいです。 (コンソールに出力すると埋もれたり、加工がめんどうです) そのようなときによく使っているPerformance.mark()とPerfor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Level up your MySQL query tuning
