TOEICの申し込みサイトにアクセス集中 受け付けを一時中止
コメント
注目のコメント
一時的な応募者数急増による弊害みたいですね。
コロナにより7月まで資格試験が中止になり、9月再開に伴う申し込み増加と。
toeicをたかが資格と思いきや、大学進学や入社条件だったりするところもあるようで、死活問題の方も多いみたい。
"英語試験の代表格「TOEIC」は進学や就職などでスコアが必須となることが多いが、運営側は7月までの試験中止を発表。次に実施されるのは9月だ。"
https://news.yahoo.co.jp/articles/75799ef33da2f793d899a827f345ca91929b6e5a直らないという事は単純にサーバを足せば良いという状況ではないんでしょうね。
DBにとんでもないクエリが飛んでるのかな...。index効かないクエリを平然と投げる開発者いますからね...。あとjoinしたりとか。
サーバ増やせばキャパが増えると思ってる方は世の中にたくさんいらっしゃると思いますがそういうものでもないんですよ。
変に作ってもサーバ増やせばほんのいくらかキャパ増えるのは事実ですが、それも無限に続くわけじゃありません。途中から全く増えなくなります。
最初から増やせるように作らないとダメなんですよね。で、一番影響力が大きく改修が難しいのがプログラムです。そもそもそういうふうに作ってない場合は書き換えるわけですが、大規模改修になりやすく、当然テストも必要ですからすぐにリリースできないし、dbのスキーマを変える必要がある場合が多いので最悪メンテです。
すごく単純な例。
申込みする時に過去の申込み記録を全部洗って重複がないかチェックするみたいな事をしてる場合、ループ数が申込み記録の分だけ増えていきます。100万件あれは100万回。その処理に10秒かかるとしたら、サーバのworkerは10秒間そのリクエストに占有されます。1サーバに20workerあげたとして10台あれば10秒間に200人しか捌けない。それを20台にすれば400にはなりますが、今度はworkerの接続先DBが同時にいくつコネクション張れるかの問題になる。
結局は無駄な申込みチェックを本人のidの申込みだけに絞ってループを10回に減らし1リクエストを0.1秒に変えない限りは焼け石に水なんですよ。
変なDBクエリを投げるとDBの応答に数秒待ちとかレコードロックの範囲が被って400個全workerが順番待ちの行列に並んで順番が来るまで応答返せないとか普通に起こります。実装がちゃんとしてる上でサーバ追加は効果を発揮します。前回の申込数踏まえれば、今回どのぐらい申込みが来そうかなんてある程度予測できそうですが。
受験生は１ヶ月間TOEIC対策してきたのに、TOEIC運営側は対策足らずだったと。
