アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
運用のノウハウ (スコア:4, 参考になる)
こういう期限付きのエントリをWebで行う時は、ピーク時の負荷を下げるために運用方法を考えないと・・・
例えば学部毎に申し込み開始と終了を変えて、それぞれをダブらないようにスケジューリングします。もちろん学部毎の人数も考慮して最適化しない
Re:運用のノウハウ (スコア:3, 参考になる)
ちなみに、別の某大学でもピーク負荷に履修登録システムが耐えない という問題があったと聞いたのだが。。。 開学２年めで4百数10人×２しか居ないのにピーク負荷に 耐えられないというふざけたシステムだったそうな。
やぱし負荷と運用では？ (スコア:1, 興味深い)
事前の予想をはるかに超える接続要求が学外からあり、ポータルシステムにログインが不能となった。
その後、(ポータルログイン問題)解消後も～、と続けられていて、
(接続要求問題)解消後も～、となってる訳ではないから
これは結局の所やっぱり接続要求量を見誤ったつう事ではないかな。
無論、別件報告の物含めてソフトに問題は有っただろうし、
サーバ２台壊れ引き続きロードバランサも壊れさらにルータ設定？もおかしかったというハード障害も
どこまで本当だか解からないが有ったのかも知れないけれども。
でもむしろそれよりは４万４千人からが学外から一斉に接続可能なシステムで
端末制限ないし学部別、学年別に受付時間分ける等の運用工夫が全然見えてこないところが
ツリー元と同じく気になるところ。そういうのは今回全く無かったんだろか？
さらに言えばどんなに人数で計算して負荷に余裕持たせても、これだけの学生が
上手い例えが見つからないけれど列作って順番に毛を刈られるおとなしい羊の様にサイト上で
履修登録に必要最小限の動作だけして済ませてられると考えるのには無理あると思うのだけどなあ。
学生がそうでないと誰がそれを保障するのだろ＾＾；
これまた上手い例えではないけど監視なしで試験実施すれば何が起こるか自明なのと同じレベルで
一斉解放でなく事前の運用ルール工夫が必須な場合だったと思うけどなあ。
いんたあねっとでこんぴゅうたあだからあいていで、いつものその辺気にせずに何でもＯＫとか
考えてたのでは無いとは思うけれど。
実際の所はどうだったんだろね。
＃まあ他分野でどちらかといえば競合企業所属なのでＡＣ
やぱしプロトタイプだからでは？ (スコア:1)
ところで、この程度の「プロトタイプ」を開発する期間を見積もるとすれば、いったいどのくらいになるものでしょうか？
門外漢なのであてずっぽうですが、NTT-COM や NEC だからそれなりの頭数は確保できるとして、半年ぐらいでしょうかねぇ。まさか１年はないですよね。
-- 環境負荷に配慮して言葉のオブラートを少なめにしています --
Re:運用のノウハウ(オフトピ) (スコア:0)
こういうときには「四百数十人」と書きます。
# 7 転び 8 起きとか 1000 載 1 遇なんて書く人もいるようだが。
Re:運用のノウハウ(オフトピ) (スコア:1)
> こういうときには「四百数十人」と書きます。
4X0人じゃないんですか？
PCにECC Registeredメモリの利用を推奨します。
Re:不徹底だな (スコア:0)
それに、ちょっと桁が多いようだが。
Re:運用のノウハウ (スコア:0)
ちょっとシステム的にしんどいかも。
ピークをそこに儲けてしまうと、過剰な投資になってしまいがちですよね。
（もちろんお
Re:運用のノウハウ (スコア:0)
学内にそんなにたくさん端末はありません。
という事もあったりして。
Re:運用のノウハウ (スコア:0)
学籍番号とかを使った認証画面を設けて。(当たり前だけどパスワード付ね。)