アカウント名:
パスワード:
システム構成を公開してみてほしいですね。どうせスケーラビリティを考慮してないデザインなのでありましょう。はー、どうしてこうもバカなんだ。
スケーラビリティは考慮すべきですが、今回の件に関してはサイジングのミスですな。
正しくスケーラブルにするのは、とてもむずかしい仕事です。スケーラビリティのことをよく知る優秀な人材は世界に限られております。ならば、、、もう Google App Engineの機構に乗ってシステム作ってください! すでに優秀なものがあるのに、同じものを作る必要はないでしょう!
そもそもケーラビリティって視点が必要な業務なん?って気もしなくはないですよね。それほど突発的に需要が増えるものだと思えないので。
今までだって何がしかの形では同業務を行ってきてたわけだから必要なパフォーマンスは予測可能なのだから、単純にパフォーマンス確保に失敗しただけですよね。(何処のフェーズでかはわかんないけれど)
まぁ品質保証の中でパフォーマンス保証ってもっとも困難なものなのも確かなのですけれど。
全く正しいと思います。不要なスケーラビリティ考慮は、不要なコスト増大を招くだけです。適切な見積もりができる以上、それをベースにチューニングすればいいだけ。
とはいえ、大規模システムのパフォーマンスチューニングは本当に修羅の世界と言うか魑魅魍魎の世界なので、大変なのは分かります。
クラウドサービスの充実で、スケーラービリティも簡単に手に入るようになりました。コンピューター資源を共有して有効活用。環境にもやさしい。サーバー代も安い。NoSQL でデータストアも高速。それなのに、それを使わない理由がわからない。
公的業務だからでしょ?
武雄市じゃあるまいし、センシティブ情報を扱う業務をほいほい民間サービスに同居なんてさせませんよ。常識的に。
Google じゃダメで訳の分からない多重下請けの日本人ならOKということもないでしょう。
Googleが日本式の個別契約書(役所系の契約は社長印必須のはず)を受け入れてくれてくれるなら、OKになる可能性はあるかもね。
#前提条件が真にならないと思うので、結果の方の可能性はそもそも考える意味は無いと思うけれど。
でも日本法人には権限は無いだろうし、もしもの時には日本法人は責任を取らないんでしょ。
>NoSQL でデータストアも高速。それなのに、それを使わない理由がわからない。丸投げする会社にも、丸投げされる会社にも、NoSQLとかわかる人いないんじゃないですか?
要件定義や設計段階でスケーラブルを考慮するのは難しいけれど、負荷試験の段階で考慮できていないのはおかしいでしょう。当日になって、処理件数が予定外に大きかったのか、それとも試験方法が間違っていたのか、そもそも負荷試験などしていないか。
負荷試験を削るほど低予算のプロジェクトでも、低信頼性の許容出来るシステムでも無いだろう。
高負荷なシステムなんて世の中にいっぱいあって、ノウハウなんかも蓄積されてるだろうに、負荷試験をやる意味ってどこにあるんでしょうか?つまり、負荷試験をやって不合格になる理由としては、なにが考えられるのでしょうか?
それとも、納品検査のひとつの項目として入っていて、客の目の前で実証するのが大切ということ?
おまえは何を言っているんだ?
まあ #2190988 でFAって気もしますが、たぶん #2190973 の人はソフトウェア開発経験がないでしょうから、真面目に説明すると…
> 高負荷なシステムなんて世の中にいっぱいあって、ノウハウなんかも蓄積されてるだろうに、> 負荷試験をやる意味ってどこにあるんでしょうか?
まず、世の中のシステムが完全に同一のソフトウェアを使っているなら、ノウハウもちゃんと反映されているでしょうが、ソフトウェアというのは、それぞれ全て一品モノです。全部違うわけです。したがって、世の中のありとあらゆるノウハウが全て盛り込まれている保証は全くありません。負荷耐性を
経験上確証もなしにバカにする行動に出る人は、能力が並み以下です。おそらく自身の無さが自己の優位性をでっち上げずにはおられないのだと思います。
っ 鏡
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
イディオット (スコア:0)
システム構成を公開してみてほしいですね。どうせスケーラビリティを考慮してないデザインなのでありましょう。はー、どうしてこうもバカなんだ。
Re:イディオット (スコア:1)
スケーラビリティは考慮すべきですが、今回の件に関してはサイジングのミスですな。
Re: (スコア:0)
正しくスケーラブルにするのは、とてもむずかしい仕事です。スケーラビリティのことをよく知る優秀な人材は世界に限られております。ならば、、、もう Google App Engineの機構に乗ってシステム作ってください! すでに優秀なものがあるのに、同じものを作る必要はないでしょう!
Re:イディオット (スコア:3)
そもそもケーラビリティって視点が必要な業務なん?って気もしなくはないですよね。
それほど突発的に需要が増えるものだと思えないので。
今までだって何がしかの形では同業務を行ってきてたわけだから必要なパフォーマンスは
予測可能なのだから、単純にパフォーマンス確保に失敗しただけですよね。
(何処のフェーズでかはわかんないけれど)
まぁ品質保証の中でパフォーマンス保証ってもっとも困難なものなのも確かなのですけれど。
Re: (スコア:0)
全く正しいと思います。
不要なスケーラビリティ考慮は、不要なコスト増大を招くだけです。
適切な見積もりができる以上、それをベースにチューニングすればいいだけ。
とはいえ、大規模システムのパフォーマンスチューニングは本当に修羅の世界と言うか
魑魅魍魎の世界なので、大変なのは分かります。
Re: (スコア:0)
クラウドサービスの充実で、スケーラービリティも簡単に手に入るようになりました。コンピューター資源を共有して有効活用。環境にもやさしい。サーバー代も安い。NoSQL でデータストアも高速。それなのに、それを使わない理由がわからない。
Re:イディオット (スコア:1)
公的業務だからでしょ?
武雄市じゃあるまいし、センシティブ情報を扱う業務をほいほい民間サービスに同居なんてさせませんよ。常識的に。
Re: (スコア:0)
Google じゃダメで訳の分からない多重下請けの日本人ならOKということもないでしょう。
Re: (スコア:0)
Googleが日本式の個別契約書(役所系の契約は社長印必須のはず)を受け入れてくれてくれるなら、OKになる可能性はあるかもね。
#前提条件が真にならないと思うので、結果の方の可能性はそもそも考える意味は無いと思うけれど。
Re: (スコア:0)
でも日本法人には権限は無いだろうし、もしもの時には日本法人は責任を取らないんでしょ。
Re: (スコア:0)
>NoSQL でデータストアも高速。それなのに、それを使わない理由がわからない。
丸投げする会社にも、丸投げされる会社にも、NoSQLとかわかる人いないんじゃないですか?
Re: (スコア:0)
要件定義や設計段階でスケーラブルを考慮するのは難しいけれど、負荷試験の段階で考慮できていないのはおかしいでしょう。
当日になって、処理件数が予定外に大きかったのか、それとも試験方法が間違っていたのか、そもそも負荷試験などしていないか。
負荷試験を削るほど低予算のプロジェクトでも、低信頼性の許容出来るシステムでも無いだろう。
Re: (スコア:0)
高負荷なシステムなんて世の中にいっぱいあって、ノウハウなんかも蓄積されてるだろうに、
負荷試験をやる意味ってどこにあるんでしょうか?
つまり、負荷試験をやって不合格になる理由としては、なにが考えられるのでしょうか?
それとも、納品検査のひとつの項目として入っていて、客の目の前で実証するのが大切ということ?
Re: (スコア:0)
おまえは何を言っているんだ?
Re: (スコア:0)
まあ #2190988 でFAって気もしますが、たぶん #2190973 の人はソフトウェア開発経験がないでしょうから、
真面目に説明すると…
> 高負荷なシステムなんて世の中にいっぱいあって、ノウハウなんかも蓄積されてるだろうに、
> 負荷試験をやる意味ってどこにあるんでしょうか?
まず、世の中のシステムが完全に同一のソフトウェアを使っているなら、ノウハウもちゃんと
反映されているでしょうが、ソフトウェアというのは、それぞれ全て一品モノです。全部違うわけです。
したがって、世の中のありとあらゆるノウハウが全て盛り込まれている保証は全くありません。
負荷耐性を
Re: (スコア:0)
経験上確証もなしにバカにする行動に出る人は、能力が並み以下です。
おそらく自身の無さが自己の優位性をでっち上げずにはおられないのだと思います。
Re: (スコア:0)
っ 鏡