> # docker-compose.yml
MYSQL_HOST / MYSQL_USER / MYSQL_PASSWORD / MYSQL_DATABASE
# ~/env.sh
MYSQL_HOST / MYSQL_USER / MYSQL_PASS / MYSQL_PORT / MYSQL_DBNAME

なので、各言語実装がマージされたタイミングで、変数名の修正をする

• make all が動かないので.PHONYをつける

• SQL に物件が存在するか問い合わせる
• 本来ならメールを送る処理があることをコメントで入れておく
• 物件の資料請求された回数を SQL に保存する

• ~/isucon10-qualify/Makefile
• ~/isucon10-qualify/cloudbuild.yaml
• ~/isucon10-qualify/webapp/kataribe.toml
• ~/isucon10-qualify/webapp/logs
• ~/isucon10-qualify/webapp/nginx
• ~/isucon10-qualify/webapp/frontend

#121 でのバグだと思うんですが、verify のフェーズで rand.Intn() によって initial-data/result/verification_data/*_detail/0.json が選択されると正しいステータスコードは 404 であるため「レスポンスの内容が不正です」になってしまっています。

• isucon10-qualify/bench/scenario/verifyWithSnapshot.go

  Lines 106 to 109 in a0c1bb3

  	default:
  	if err == nil {
  	return failure.New(fails.ErrApplication, failure.Message("GET /api/chair/:id: レスポンスの内容が不正です"))
  	}

• isucon10-qualify/bench/scenario/verifyWithSnapshot.go

  Lines 219 to 222 in a0c1bb3

  	default:
  	if err == nil {
  	return failure.New(fails.ErrApplication, failure.Message("GET /api/estate/:id: レスポンスの内容が不正です"))
  	}

diff --git a/bench/scenario/verifyWithSnapshot.go b/bench/scenario/verifyWithSnapshot.go
index 7384c59..0b1ca82 100644
--- a/bench/scenario/verifyWithSnapshot.go
+++ b/bench/scenario/verifyWithSnapshot.go
@@ -459,7 +459,7 @@ func verifyWithSnapshot(ctx context.Context, c *client.Client, snapshotsParentsD
        } else {
                for i := 0; i < NumOfVerifyChairDetail; i++ {
                        wg.Add(1)
-                       r := rand.Intn(len(snapshots))
+                       r := 0
                        go func(filePath string) {
                                err := verifyChairDetail(ctx, c, filePath)
                                if err != nil {

みたいにすると webapp/go に対するベンチでも100%再現するようになります。

スコアが parameter.BoundaryOfLevel[11] を超えると負荷レベルが 12 になり parameter.ListOfIncWorkers[12] を参照しようとするため、ベンチマーカの負荷レベルが最大まで上がると panic: runtime error: index out of range [12] with length 12 でクラッシュしています。

workload がどこまで増加したのかを一目で確認する術がないため、点数とエラーメッセージだけからでは整合性の確認がしづらい

現状標準出力に出しているが、証跡を残すために、実行結果をファイル名を指定してファイル出力できるようにしておきたい。
求める内容は2種類で、１つはErrの情報が全て乗っていること、もう一つは競技者に見せる結果と同じデータが入っていること。

問題

こだわり条件検索を高速化する手段がない

うまくいかない想定解（いずれも，ジェイウォーク自体の解決後を想定する)

それぞれの単一フィーチャーごとに，view countのパーシャルインデックスをはる
それぞれの単一フィーチャーごとの，それが存在するサブテーブルを作っておく

うまくいかない理由

フィーチャーが増えるごとに，検索へのヒット数が減るという前提があるが，現状はフィーチャーの数を1-10の一様分布で決めている
ゆえに，検索条件が増えていってもかなりの数が検索結果として残ってしまい，インデックスが聞かない状態のOFFSETを強要され死んでしまう．

一様分布にしているコーど

改善案

上記のコードを変更して，イスがもつフィーチャーの種類数を少ない方に偏らせることが考えられる

コードが作成されたときとrustのstableバージョンが異なるため、Rustアプリケーションに含まれる lexical-core のビルドが失敗します。

結果として、 ansible-playbook を用いたサーバの構築が失敗します。

workaround

以下のコードを変更することにより、ansible-playbookが通ることのみを確認していますが、当方がrustに詳しくないため、アプリケーションが意図した動作をするかの確認ができていません。

/home/isucon/.cargo/bin/rustup default 1.46.0

もしくは、allinone.yaml や competitor.yaml の対象のroleをコメントアウトすることで回避することが出来ます。

関連

• rust-lang/rust#81654
• Alexhuszagh/rust-lexical#56

イスと物件のダミー画像を、いらすとやから実写のものに差し替える