動作が遅く、メモリを大量に消費する製品があった場合。
これら 2 つのオプションの間で何を決定するか、またその理由は何ですか?
- 5 桁、場合によっては 6 桁の「ザ」サーバーを購入すれば、この製品は完璧に機能します。
- それを変更するためのソースとリソースがあり、問題を修正するためのオプション 1 とほぼ同じ費用がかかりますが、4 桁のサーバーを取得できます。
13 に答える
8
私は 2 票を投じます。単純に、1 年後に製品がより頻繁に使用され、より多くのデータが処理され、より多くのリソースが必要になると、より大きなサーバーを再び購入する必要がなくなるからです。
そして、より大きなハードウェアを手に入れることができなくなる時が来るかもしれません.
于 2009-09-01T18:49:56.157 に答える
3
#1 を採用します。なぜなら、#2 は実際には時間がかかり、あなたが考えるよりも少なくとも 5 倍の費用がかかることを保証できるからです :-)
于 2009-09-01T18:49:54.830 に答える
3
プロファイリングし、遅いセクション (ボトルネック) を書き直すか更新します。コード ベース全体を書き直さないでください。このアプローチは、課題を解決しながら、費用対効果が最も高くなるはずです。
于 2009-09-01T18:54:21.140 に答える
2
いくつかの質問:
- しばらくして、アプリケーションのユーザー数が増えたために、さらに強力なサーバーが必要になった場合はどうなるでしょうか?
- これは起こりえますか？
- アプリケーションを書き直すのにいくらかかりますか?
最初の質問に対する答えが「新しいサーバーは 1 年では十分に強力ではない」という場合は、アプリケーションを最適化する必要があります。
「どれくらいの費用がかかりますか」に対する答えが本当に多い場合...まあ、私が考えていることを推測させてください;-)すべては前のポイントへの答えに依存します。
その質問に対する答えを知らなければ、あなたを助けることは非常に難しいでしょう.
私の提案は次のとおりです。書き換えずに、できる限り最適化してください。これにより、少なくとも時間がかかります。そうすれば焦らずに考えることができます。
これにより、より良い書き直しが可能になり、結果として得られるアプリケーションははるかに優れたものになります。また、おそらくスケーリングも向上します。これは、より多くのユーザーがいると思われる場合に非常に重要です。
そう ：
- 最適化
- 考える時間をとってください
- 書き直し、最適化、スケーリング、メンテナンスについて考える
于 2009-09-01T18:49:51.913 に答える
2
コストが同じであることをほのめかしているので、次に考慮すべきことは配達時間です。
1 おそらく 2 よりも短い時間で実装できます (2 を構築するコストが 5 桁または 6 桁の場合、かなりの時間になります)。
プロジェクトを早期に取得することにも利点があります。
これに対して、将来的にシステムを強化する予定があり、それが長寿命である場合は、製品を改善することで保守コストを削減できます。
于 2009-09-01T18:54:04.307 に答える
2
お金がなくなるまで問題を延期するだけなので、それは2番目でなければなりません.
とは言え、ボトルネックは？クイックフィックス:
- ディスク構成 (例: SCSI 15K RAID 10、Whizzier コントローラー)
- より多くの RAM (データベース ボックスには常に適しています)
- 64 ビット OS/再コンパイル
- プロセッサを追加します (おそらくコード用ではなく、ボックスで他のタスクを実行するため)
于 2009-09-01T18:55:11.637 に答える
2
通常の場合と同様に、「場合による」。通常、事業主は利益を最大化する方向に動きますが、リスクと影響を慎重に分析した後でのみです。正しい決定は、多くの要因の影響を大きく受けます。
コストを最小限に抑えるものは何ですか? 6 桁のメインフレームは、既存のコードを書き直すための 6 桁の開発作業よりも安くはないかもしれません。
どの程度の改善が必要ですか？ほとんどの CPU およびメモリ バウンド アプリケーションでは、問題にハードウェアを投入するだけで 5 倍以上のスピードアップを実際に期待することはできません。特定のクラスの問題については、適切に作成されたデータ構造とアルゴリズムにより、アプリケーションのランタイムを文字通り何百万倍も高速化できます。
リスクを最小限に抑えるものは何ですか？レガシ コードを書き直すことは、既存のソフトウェアに新しいバグを書き込むための保証され、実績があり、実証済みの方法です。
どの程度のスケーラビリティが必要ですか? 一部の計算は、計算の小さな部分を複数のサーバーに分散できるように記述できるため、ハードウェアを追加することで計算を直線的にスケーリングできます。このようにソフトウェアを作成するには、慎重な計画が必要です --- そして、最初からスケーラビリティがゲーム プランの一部でなかった場合は、ほぼ確実にコードを書き直す必要があります。
あなたの個々の状況についてもっと知らなければ、あなたの質問に対する良い答えはありません.
于 2009-09-01T19:03:05.083 に答える
1
両方の価格は同じなので (時間はどうですか?)、(2) を修正/開発します。一方、ほとんどのプログラマーは開発時間とコストを過小評価しているため、時間内に問題を修正するのは幻想かもしれません。
于 2009-09-01T18:51:53.187 に答える
0
パフォーマンスの低下が問題領域に正比例する場合は、書き換えが唯一の選択肢になる可能性があります。
于 2009-09-01T18:53:52.247 に答える
0
黒か白かではなく、1つまたは2つ。ぶら下がっている成果を見つけるところを最適化し、最適化が難しいハードウェアを購入する必要があると思います。選択するのではなく、バランスを見つけてください。
私は選択肢 2 を好む傾向があります。それは、一部には楽しいと思うからであり、一部には応答時間の短縮など、他の良い副作用があるかもしれないからです。
アプリケーションを多数のサーバーに分散できる場合は、アーキテクチャも考慮する必要があります。その場合、非常に高価な 1 台のサーバーではなく、2 台の安価なサーバーで対処できる可能性があります。
于 2010-08-07T12:34:58.670 に答える
0
Depends on where the bottlenecks are. I wouldn't make this decision without knowing that first. Faster, better equipment may not solve your problem if the problem is poor design or badly written queries and then where are you after having spent the whole budget?
于 2009-09-01T20:51:19.220 に答える
0
ハードウェアの変更には、ほぼ直線的なメリットがあります。ムーアの法則に本当に乗れるのであれば、しばらくの間、ほぼ指数関数的になる可能性があります。最終的には、Moore 以外の要因 (予算や冷却要件など) に達し、線形に低下します。
書き換えをうまく行えば、パフォーマンスだけでなく動作も変わります。現在のソフトウェアに幾何学的動作 (O(n^2) など) がある場合、成長するにつれて幾何学的に優れたハードウェアが必要になります。線形の動作 (O(n) など) を取得すると、より多くの余裕が生まれます。
于 2009-09-01T19:00:22.140 に答える
0
これが社内アプリケーションの場合は、オプション 1 を使用します。コストはどちらのオプションでも同じですが、アプリをすぐに導入できます。一方、ハードウェアのコストは下がり続けています。まもなく、5 ～ 6 桁のサーバーが 4 桁のサーバーになります。
ユーザーに出荷するものであれば、オプション 2 の方が信頼性が高いように思えますが、それは出荷をどれだけ早くする必要があるか、ユーザーがサーバー機器に費やす意思があるかによって異なります。
于 2009-09-01T19:05:35.127 に答える