アカウント名:
パスワード:
ソフトウェア開発側からすると載せれるだけ載せろという話にしかならないし、ハードウェア保守側からすると最小限構成の方が安定性や、交換リスクが軽減するという話になる。プロデューサーサイドからすると予算枠があるから最小構成に偏りがちなんだよね。
どういう論理構成やプレゼンでメモリマシマシの構成を進言すれば良いんだろうか。おすすめの論点とかありますか？
更改なら現行のスループットや負荷状況の実績を算出過去から現在の負荷の伸び率から将来においての予測を立てて拡張が必要になった際は予備を開放すればいけるでしょう、という構成見積もりなら見た
0から構築は知らん
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
メモリ容量の見積もり (スコア:1)
ソフトウェア開発側からすると載せれるだけ載せろという話にしかならないし、
ハードウェア保守側からすると最小限構成の方が安定性や、交換リスクが軽減するという話になる。
プロデューサーサイドからすると予算枠があるから最小構成に偏りがちなんだよね。
どういう論理構成やプレゼンでメモリマシマシの構成を進言すれば良いんだろうか。
おすすめの論点とかありますか？
Re:メモリ容量の見積もり (スコア:0)
更改なら現行のスループットや負荷状況の実績を算出
過去から現在の負荷の伸び率から将来においての予測を立てて拡張が必要になった際は
予備を開放すればいけるでしょう、という構成見積もりなら見た
0から構築は知らん