現代のコンピューティングの時代、「典型的なビジネスアプリ」-なぜパフォーマンスが重要なのですか?[閉まっている]


29

これは一部の人にとっては奇妙な質問のように思えるかもしれません。

私は趣味のJavaプログラマーです。いくつかのゲーム、音楽を作成するAIプログラム、ペイント用の別のプログラムなどを開発しました。これは、私がプログラミングの経験を持っているが、ビジネスアプリケーションの専門的な開発の経験がないことを伝えるためです。

このサイトでパフォーマンスについて多くの話を聞いています。多くの場合、タスクを実行するためにC#で最も効率的なアルゴリズムとは何か、Pythonが低速でJavaが高速な理由などについて議論されています。

私が理解しようとしているのは、なぜこれが重要なのですか?

パフォーマンスが重要な理由がわかるコンピューティングの特定の領域があります:ゲーム、一定の更新ループで毎秒何万もの計算が行われている、OSやVMなどの他のプログラムが依存している低レベルシステム

しかし、通常の典型的な高レベルビジネスアプリの場合、なぜパフォーマンスが重要なのでしょうか?

何十年も前に、なぜそれが重要であったのかを理解できます。コンピューターは非常に遅く、メモリもはるかに少なかったため、これらのことについて慎重に考える必要がありました。

しかし、今日、私たちには非常に多くのメモリがあり、コンピューターは非常に高速です:特定のJavaアルゴリズムがO(n ^ 2)であるかどうかは実際に重要ですか?この典型的なビジネスアプリのエンドユーザーに実際に違いをもたらすのでしょうか?

典型的なビジネスアプリでGUIボタンを押すと、背後でO(n ^ 2)アルゴリズムが呼び出されますが、最近のコンピューティングの時代では、実際に非効率を感じていますか?

私の質問は2つに分かれています。

  1. 実際、今日の典型的な通常のビジネスプログラムではパフォーマンスは重要ですか?
  2. もしそうなら、パフォーマンスと最適化が重要なそのようなアプリケーションの場所の実世界の例を教えてください。


パフォーマンスが悪い場合は重要です。
マイクダンラベイ14

回答:


40

あなたは正しい、だビジネスアプリケーションにおけるパフォーマンスが本当に重要な課題とそれはほとんどのプログラマによって議論されている方法ではありません。通常、プログラマーから聞いたパフォーマンス関連の議論にはいくつかの問題があります。

  • それらは主に時期尚早な最適化です。通常、誰かが「最速の方法」で明確な理由なしに操作を行い、ほとんどのコンパイラで行われるコード変更(除算の乗算による置き換えやメソッドのインライン化など)を行うか、変更を行うのに何日も費やします。これは、実行時に数マイクロ秒を獲得するのに役立ちます。

  • 彼らはしばしば投機的です。Stack OverflowとProgrammers.SEでは、質問がパフォーマンスに関連している場合にプロファイリングが頻繁に言及されますが、プロファイリングがパフォーマンスについて議論していることを知らない2人のプログラマーを見ると失望します。コードで行う必要がある関連変更。彼らは、変更によりすべてが速くなると信じていますが、実際には毎回、目に見える効果がないか、物事が遅くなりますが、プロファイラはそれらを簡単に最適化でき、80%を浪費するコードの別の部分を指し示します当時の。

  • 技術的な側面のみに焦点を当てています。ユーザー指向のアプリケーションのパフォーマンスとは、感覚に関するものです。高速で反応が良いと感じますか、それとも遅くて不格好だと感じますか?これに関連して、パフォーマンスの問題は通常、ユーザーエクスペリエンスデザイナーによってはるかによく解決されます。単純なアニメーション化された遷移は、多くの場合、非常に遅いと感じるアプリと応答すると感じるアプリの違いであり、どちらも600ミリ秒を費やします。操作を行う。

  • それらは、技術的な制約に関連している場合でも、主観的な要素に基づいています。それはの質問ない場合は感じて、高速で応答性、そこにあるべき指定がどのように高速動作が特定のシステム上で実行されている、特定のデータに対して実行されなければならない非機能要件。現実には、それはもっとそのように起こります。マネージャーは、何か遅いものを見つけたと伝え、開発者はそれが何を意味するのかを理解する必要があります。「30ミリ秒未満である必要がありますが、現在は10秒を浪費している」などのように遅いのですか、「10秒から9秒に期間を短縮できる」などのように遅いのでしょうか。

プログラマーとしてのキャリアの早い段階で、私は多くの顧客のためにソフトウェアを開発していました。私はこのソフトウェアが世界に幸福をもたらす次の素晴らしいものであると確信したので、明らかにパフォーマンスに関心がありました。

「プロファイリング」や「ベンチマーク」などの用語を聞いたことがありますが、それらの意味がわかりませんでした。さらに、私はCに関する本、特に最適化手法が議論された章を読むことに集中しすぎていました。コンピューターが除算よりも速く乗算を実行することを発見したとき、可能な限り除算を乗算に置き換えました。メソッドの呼び出しに時間がかかることがわかったとき、以前の100個のLOCメソッドがまだ問題になっていないかのように、できるだけ多くのメソッドを組み合わせました。

時々、夜に変更を行って、誰も望んでいない遅いアプリと、誰もがダウンロードして使用したい速いアプリとの間に違いがあると確信しました。このアプリに興味を持っている2人の実際の顧客が実際の機能を要求したという事実は、「アプリが遅い場合、誰が機能を必要とするだろうか」と私を悩ませませんでした。

最後に、2人の顧客のみがアプリの使用を停止しました。私のすべての努力にもかかわらず、驚くほど速くはありませんでした。主な理由は、インデックスが何であるかがわからず、アプリがデータベース集約型である場合、何か問題があるからです。とにかく、1か月に1回使用されるコードの実行を数マイクロ秒改善するパフォーマンス関連の変更を行ったとき、顧客は変更を確認しませんでした。彼らが見ていたのは、ユーザーエクスペリエンスがひどく、ドキュメントが欠落しており、彼らが何ヶ月も要求していた重要な機能がここになく、解決すべきバグの数が絶えず増えているということです。

結果:このアプリが世界中の数千の企業で使用されることを期待していましたが、今日、インターネット上でこのアプリケーションに関する情報を見つけることはできません。2人の顧客だけがそれを放棄し、プロジェクトも同様に放棄されました。それは決して販売されず、公に宣伝されることもありませんでした。そして今日、PCでコンパイルできるかどうかさえわかりません(元のソースも見つかりません)。実際に重要なことにもっと焦点を合わせていれば、これは起こりませんでした。

これは言われていることですが、一般パフォーマンスは重要です:

  • 非ビジネスアプリでは、それが重要になる可能性があります。ある組込みソフトウェア、上のソフトウェアRAN サーバ(あなたは大きな、パフォーマンスが問題になり始めるということではありません秒あたりの要求の数千を持っている場合)、上のソフトウェアRAN スマートフォンビデオゲーム専門家のためのソフトウェア(ハンドルしようとするには、それほど高速ではないマシンのPhotoshopで50 GBのファイルを納得させて)、多くの人に販売されている通常のソフトウェア製品(Microsoft Wordがすべての操作を行うのに2倍の時間を費やす場合、失われた時間に数を掛けたもの)ユーザーの問題になります)。

  • ビジネスアプリケーションでは、アプリケーションの多くの例がある感じゆっくりし、ユーザーに嫌われますが。あなたはそれを望んでおらず、あなたの懸念に基づいてパフォーマンスを行います。


4
特に、無意味なパフォーマンスの議論と無意味な最適化に重点を置いているため、素晴らしい答えです。
ドックブラウン14

1
a simple animated transition may often be the difference between an app which feels terribly slow and the app which feels responsive-これらは確かに控えめに使用する必要がありますが、アニメーションやトランジションをいたるところに散らかすアプリでは、それらのトランジションを毎日見つめるとイライラする可能性があります!
宇宙のオシフラジ

引用元は何ですか?
アダムジョンズ14

1
@AdamJohns:ソースなし。私のブログでまだ公開されていない私自身の記事の下書きから引用されています。
Arseni Mourzenko

@MainMa素晴らしい。あなたのポイントの小さなイラストを本当に楽しみました。
アダムジョンズ

44

はい。はい、そうです。実行時の速度だけが懸念事項ではありません。また、1982年のように差し迫っていたり、低電力の組み込みシステムの場合と比べてそれほど重要ではありませんが、常に懸念事項であり、理解することが重要ですなぜそうなのか。

一つには、あなたが言及する漸近的な複雑さは、入力サイズが大きくなるときのプログラムの振る舞い説明します。10件のアイテムとの取引が余計な仕事をしていると逃げることができますが、それはちょうど遅いようですが、ないので1日あなたは、1000年に対処しなければならないとき、それはあなたをかむこと非線形計画、はるかに遅いです。そして、100,000アイテムに到達するまで、そのポイントが100アイテムにあるのか、1000アイテムにあるのか、またはそうでないのかは(詳細な分析とベンチマークなしでは)わかりません。信じがたいかもしれませんが、当然のことながら、すべてのルーチンでこの点を推定し、この推定に基づいて実装を選択するよりも、実際のところ、最適なアルゴリズムを選択する方がはるかに簡単です。

また、ユーザーエクスペリエンスの基本についてもお読みください。応答時間(10ミリ秒、100ミリ秒、数秒など)に応じて、プログラムとの対話がどのように知覚されるかを決定する、よく研究されたしきい値があります。これらのしきい値の1を横断すると、アプリケーションから外れるようにユーザーを引き起こし、そしてあなたは、人々がいることを独占ソフトウェアを書くの幸せな位置にある場合を除きます持って使用することは、顧客の損失につながるため、解放ユーザーは、負のビジネス価値に直接変換されます。

これらは、プロのプログラマーアルゴリズムの複雑さを知り、責任を持って処理しなければならない理由のほんの一部です。最近では、タイムクリティカルな内部ループであることが判明しない限り、邪魔にならず、特に最適化された読みにくいコードをプログラムする必要はありませんが、明らかに必要以上に複雑なクラスを呼び出さないでください仕事をする。


2
アルゴリズムの選択に関して覚えておくべきもう1つのこと:ライブラリと抽象化のために、多くのアルゴリズムの選択が既に、または少なくとも「内部」で行われています。それらがパフォーマンスに与える影響をまだ知っている必要があります。そして、そのパフォーマンスは重要です。
joshin4colours 14

14

はい、そうです!

あなたが例を求めたので、いくつかの毎日の状況が思い浮かびます:

  1. ビッグデータの処理:多くのビジネスアプリケーションはデータベースに支えられており、多くの場合、これらのデータベースはデータであふれています。また、ドライブスペースは安価であるため、記録および保存されるデータの量は非常に多くなります。先週、顧客は、平均数を表示するだけでアプリケーションが非常に遅いと不満を言いました(数百万行以上のクエリ...)-また、日常使用では、いくつかのリーグのランタイムでバッチデータ変換と計算があります時間。昨年、アルゴリズムの最適化により、1つのバッチのプロセス時間が8時間から4時間に短縮されました。これで、日中シフトとの衝突がなくなりました。

  2. 応答性:ユーザーの満足度が応答性に大きく関係しているというユーザビリティの調査がありました(時間があれば、ux.seの関連する質問へのリンクを追加します)。応答時間に200ミリ秒と400ミリ秒の差があると、顧客の大部分が簡単にコストをかけられ、競合他社に追いやられてしまいます。

  3. 組み込みシステム:コンピューターは高速化されておらず、低速化と小型化が進んでいます^ _ ^モバイル開発はアプリケーション開発に大きな影響を及ぼします。確かに、現代のデスクトップコンピューターではJelly BeansのようなメモリとCPUサイクルを使用できますが、今度は上司から、フリーキンウォッチまたはSIMカードに睡眠分析アルゴリズムを実装するように求められます...


4

実際、今日の典型的な通常のビジネスプログラムではパフォーマンスは重要ですか?

典型的な通常のビジネスプログラムが何なのかわかりません。私が知っていることは、ユーザーは常に計画よりもはるかに多くのデータをプログラムに供給することで終わることです(多くの場合、それがどれくらい大きいかを確認してセキュリティマージンを追加した後)、そしてその場合、彼らは実行時に、log n動作を受け入れ、他に何かが発生するとアプリケーションがフリーズすることを訴えます。また POVからすべての入力データを処理する必要があることが明らかな場合を除き、結果のサイズを入力のサイズよりも考慮する傾向があります。

そのため、少なくとも複雑なレベルでのパフォーマンスが重要です。複雑さのクラス内のミクロ最適化は、実際には重要ではありません。ただし、競合よりも明らかに悪い場合(一部の市場のベンチマークまたは生の認識のいずれかで、進行中のクラスを変更する「瞬間的」、「瞬時ではなく、ユーザーが「他の何かに切り替えない」、「ユーザーがアクションのフローを中断するリスクがある他の何かに切り替えるのに十分遅い」、「ユーザーがタスクを起動して時々チェックするのに十分遅い」、「十分に遅いユーザーが昼休み、夜間、週末にタスクを起動することを計画していること」)。


4

現代のビジネスアプリケーションでは、パフォーマンスの問題はCPUやメモリの不足という形ではありません。しかし、それらはネットワーク遅延、I / Oパフォーマンス、およびそれらすべてを隠す抽象化という形をしています。それはすべて、設計の質と開発者の経験次第です。クエリを実行する代わりに一度に1行ずつDBからプルする場合、単純なCRUDアプリケーションでもクロールを停止できます(N + 1問題とも呼ばれます)。

問題は、優れた設計と経験豊富な開発者がいると費用がかかることです。また、実際のパフォーマンスの最適化に投資するよりも、ユーザーをいらいらさせる方が通常はるかに安価です。顧客が高いパフォーマンスを必要とする場合(Webブラウザーなど)がありますが、一般的なビジネスアプリケーションにはほとんど適用されません。


3

サーバーベースのアプリケーションの場合、数百、数千、または数百万のユーザーが同時に物事を行おうとしていることに注意してください。このような状況での効率のわずかな節約は、要求の処理に必要なハードウェアの量に大きな影響を与える可能性があります。


5
実際、ほとんどの一定の要因は、問題に対してより多くのハードウェアを投入することでよりよく解決されます。これは、通常、物を最適化するよりも多くのハードウェアが安くなるためです。この問題は、漸近的(スケーリング)の悪い動作です。これは、ハードウェアを追加してもあまり役に立たないためです。
Jan Hudec 14

3
最適化は1回だけですが、毎月電気料金を支払います。
ジェイディー14

2
@JanHudec:現在あなたがいるウェブサイト(私たちの親愛なるStack Exchange)が世界中で月間560Mのページビューを提供しているとき、真っ直ぐな顔で25台のサーバー上で実行しているとあなたが本当に言うことができる方法はわかりません。
Mehrdad 14

2
@Mehrdad:代わりにCで記述し、おそらく25台ではなく20台のサーバーで実行することもできました。しかし、開発時間の延長を節約しても節約できないからではありませんでした。多くのWebサービスは、一般的に最も遅い言語の一部であるPythonおよびPHPで実装されていますが、開発時間の増加が報われないため、それらをより高速に書き換えることを考えている人はいません。多くの場合、一定の要因は、ハードウェアを追加するだけで解決されます。もちろん、(漸近的な)問題のスケーリングも別の問題です。
Jan Hudec 14

3
...そして公平を期すために、データベースは、うんざりする作業のほとんどを行っているものであり、高速に動作するように最適化されています。
Blrfl 14

3

それは確かに重要です。

主な問題は、GUI要素が2回または3回描画されたときに不必要な遅延を経験する(統合グラフィックスで問題になります)、または単にプログラムの実行に時間がかかるなど、ユーザーを悩ますことでもありません... (ほとんど面白くないもの)。もちろん、それも問題です。

3つの重要な誤解があります。

  1. ほとんどの典型的なビジネスコンピュータは「それほど強力ではありません。一般的なビジネスコンピューターは、キックアスグラフィックカードと16 GBのRAMを備えた8コアi7ではありません。ミッドクラスのモバイルプロセッサ、統合グラフィックス、2GBのメインメモリ(運が良ければ4GB)、5400RPMディスク、およびさまざまなリアルタイムウイルス対策ソフトウェアとポリシー適用ソフトウェアを搭載したエンタープライズバージョンのWindowsを搭載したノートブックです。バックグラウンド。または、ほとんどのコンサルタントにとって、「コンピューター」は単にiPhoneです...
  2. ほとんどの「典型的なビジネスユーザー」は技術者ではありません。10〜12の相互参照タブ、150列、30,000行のスプレッドシートを作成することの意味を理解していません(これらの数字は想像するほど非現実的ではありません!)どちらも知りたくない。彼らはただそれをします。
  3. 二度目の損失は費用かかりませんが、明らかに間違った仮定です。

私の妻は、そのような「典型的なビジネス環境」の上限で働いています。彼女が使用しているコンピューターは、約3.5時間の勤務時間に相当します。Microsoft Outlookの起動には、準備が整うまで約3分(サーバーに負荷がかかっている四半期末には6〜8分)かかります(良い日には)。上記の3万行のスプレッドシートの一部は、コンピューターが「フリーズ」している間に値を更新するのに2〜3秒かかります(最初にExcelを起動して開くのにかかる時間は言うまでもありません!)。デスクトップを共有する場合はさらに悪い。SAPを使用しないでください。
10万人が1日あたり20〜25分間何も待たずに失うかどうかは確かに重要です。それらは数百万人が失われたそれらを失う代わりに、配当として支払う(またはより高い賃金を支払う)ことができます。
確かに、ほとんどの従業員は賃金表の下端にいますが、下端の時間でさえお金です。


3

何十年も前、なぜそれが重要であったのかを理解できます。コンピューターは非常に遅く、メモリもはるかに少なかったため、これらのことについて慎重に考える必要がありました。

N ^ 2の成長速度を過小評価しているようです。コンピューターがあり、N = 10の場合、N ^ 2アルゴリズムに10秒かかるとしましょう。時間が経過すると、元のコンピューターの6倍の速度の新しいプロセッサーができ、10秒の計算は2秒未満になります。Nは元の10秒の実行時間にどれだけ大きく、それでも収まりますか?24アイテムを処理できるようになり、2倍強になりました。10倍の数のアイテムを処理するために、システムはどれくらい速くなければなりませんか?まあ、それは100倍速くなければなりません。データは非常に速く成長し、N ^ 2アルゴリズムのコンピューターハードウェアの進歩を一掃します。


別の例:1つの要素の処理に30 CPUサイクルまたは10 ns(これは非常に安価です)を要する場合、10000の要素しかない場合、アルゴリズムはすでに1秒かかります。10000要素は多くのコンテキストではあまりありません。
CodesInChaos 14

1

私たちが職場で使用しているサードパーティのビジネスプログラムの量は信じられないでしょうし、それらの多くは私の個人的な基準に比べてとてつもなく遅いです。プログラムが私が自宅で使用しているものであった場合、私はずっと前に別のプログラムに置き換えていたでしょう。

一部のプログラムは、1日に達成できるタスクの数に直接影響を与えるため、生産性と請求可能なアイテムの量が低下するため、場合によっては、違いが直接コストに影響します。ですから、ビジネスプログラムにとっても、少なくとも収入を制限する項目にならないように十分なパフォーマンスを発揮することが非常に重要だと思います。

たとえば、15分間隔で作業を測定するインシデント管理(サービスデスク)です。プログラムが1つのチケットをプッシュするのに15分以上かかるほど遅い場合(実際の作業を含む)、プロセスが非常に遅くなります。1つの原因は、ユーザーがアクション(解決の詳細の入力、作業情報の更新など)を行うたびに単に「しばらく待つ」データベースアクセスの低下です。病院の患者の緊急中毒事件の詳細など、遅いプログラムがさらに重要なことに影響を与える可能性さえある場合があると想像できます-多分薬アレルギーなど?


1

他の回答の多くは、このトピックを完全に網羅しているので、理由と理論的根拠についてはそれらに従うことにします。代わりに、アルゴリズムの選択が実際に意味を持つ可能性があることを示すために、実際の例を挙げたいと思います。

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

リンクされた記事では、Windows XPの更新を計算するアルゴリズムのバグについて説明しています。Windows XPのほとんどの期間、更新アルゴリズムは正常に機能しました。このアルゴリズムは、パッチが新しいパッチに置き換えられたかどうかを計算するため、インストールする必要はありません。しかし、終わりに向かって、置き換えられた更新プログラムのリストは非常に長くなりました*。

更新アルゴリズムは指数関数的であり、新しい更新はそれぞれ、前の更新()の計算に2倍の時間がかかりました。リストが40個の更新範囲(* long)に達すると、更新を確認するために最大容量で実行され、最大15分かかりました。これにより、更新中に多くのXPマシンが事実上ロックされました。さらに悪いことに、更新プログラムをインストールしようとすると、アルゴリズムが再び実行され、さらに15分かかります。多くのマシンには自動更新が設定されているため、ブートごとに15分間、場合によっては一定の周期でマシンがロックされる可能性があります。O(n) = 2n

マイクロソフトは、この問題に対処するために、短期的なハック(更新リストからアイテムを削除する)と長期的な修正の両方を使用しました。Windowsの最新バージョンも同じアルゴリズムを使用しており、ある日同じ問題に直面する可能性があるため、これは重要でした。

ここで、アルゴリズムの選択が本当の意味を持つことがわかります。間違ったアルゴリズムは、製品の寿命の大部分では問題ありませんが、将来的にはマイナスの影響を与える可能性があります。


0

パフォーマンスについての質問の量は、パフォーマンスの改善が難しいことを認識するのではなく、ビジネスアプリのパフォーマンス要件が重要であることを示すものとして解釈していると思います。単純に機能させるには、ブルートフォースの手法、試行錯誤、またはサンプルコードのコピーと貼り付けを行うことができます。

誰でも幸運を得ることができ、何かがより速く実行されるまで変更を続けることができますが、それはめったに機能しません。経験が不足しているため、開発者は外部からの支援を受けることになります。一部の環境では、パフォーマンスの向上は独自の問題であるため、StackOverflowなどのサイトで特定の質問をすることが唯一の選択肢になる場合があります。また、多くのコンサルタントは、この種の問題に介入して修正することでお金を稼ぎます。


-1

「良好なパフォーマンス」をどのように定義するかに大きく依存します。アルゴリズムは常に可能な限り最高の複雑さを使用する必要があります。抜け穴を悪用して、平均的なケージを高速化します。対話型プログラムで可能な限りバッファリングおよびプリロード/プリコンパイルします。

「良好なパフォーマンス」の別の定義があります。複雑度クラスの定数を最適化することです。これは、C ++が彼の肩書きを取得する場所であり、人々はJavaの呼び出しを遅くし始めます。この定義を使用すると正しいです。コンピューターのハードウェアは時間とともに複雑になりますが、コンパイラーはますます良くなります。ある時点で、コンパイラーよりもローエンドのコードを実際に最適化することはできません。そのため、アルゴリズムに専念してください。

その時点で、Java / Haskell / C ++を使用することは、設計上のもう1つの決定になります。数値演算は、GPUのOpenCLを介して実行できます。ユーザーインターフェイスには一定時間のアルゴリズムが必要であり、優れています。キャッシュの使用率が20%向上するようにクラスを調整するよりも、出力とモジュール性が重要です。マルチスレッディングは重要になります。人々は高速なアプリを望んでおらず、応答性の高いアプリを望んでいるからです。重要でないのは、アプリが常に10%遅くなることです。50%でも問題ありません(ただし、人々は質問を始めます)。正確性、応答性、モジュール性に集中してください。

Haskellまたは少なくとも関数形式(C ++であっても)でのプログラミングが大好きです。プログラム全体のテストを簡単に作成できることは、バッチジョブで少し速くなることよりもはるかに重要です。


-1

非常に簡単:コスト

私の以前の雇用主は、SaaSモデルとして物理サーバーでホストされていた学習管理システムを持っていました。JVMのヒープは、古いマシンでは2 GB、新しいマシンでは3 GBに構成されており、マシンごとにいくつかのインスタンスを実行しました。それで十分だと思います。

始める前に、システムの応答性と規模の拡大を担当するパフォーマンスチームがいました。彼らは、データベースから継続的にクエリを実行する特定のデータがあることを発見しました。1つの列を取得するために、ほとんどのクエリに参加したテーブルが1つありました。そのデータはめったに変更されません。

問題は、使用する2 GBがあったことです。そのため、明らかな解決策は、頻繁に読み取られるすべてのデータのキャッシュを開始することです。それから、私が乗船する直前から始まるメモリの問題がありました。

これについては、2つの考え方がありました。

  1. 一般的に、メモリとハードウェアは一般的に安価です。キャッシュを増やすために、RAMを追加購入するだけです。
  2. 学習管理システムに3 GB以上のRAMが必要なのはなぜですか?SQLクエリを発行し、リダイレクトを送信してコースを開始し、コースの学生の進捗を評価します。

2番目の引数は勝ち、私は1年以上メモリ使用量の調整に費やしました。

私の現在の雇用主も学習管理システムをホストしていますが、それは少し異なります。スケーラビリティは非常に低いため、単一のインストール(4つの負荷分散仮想サーバーに分割)は80人の顧客しか処理できません。大規模なお客様の中には、独自のサーバーセットを入手するものもあります。これにつながる問題のほとんどは、すべてのCPUサイクルを占有するSQLクエリ、メモリリーク、同じことを複数回行う冗長コードなど、パフォーマンスの問題です。サーバーのパフォーマンスが低下していないときにサーバーを再起動することを唯一の目的とする社内アプリも構築されています。(他の責任とともに)そのツールを保守する従業員がいます。

彼らは、私が上記で述べた最初の考え方に同意しました。ハードウェアのコストは開発者の給与よりも安いため、ハードウェアを追加してください。

これは予想したほど経済的にはうまくいきませんでした。サーバーを処理するためのハードウェア、ソフトウェアライセンス、およびサポート担当者の間で、開発者がコードのプロファイリングに時間を費やさないように、毎年数百万を費やしました。

私が入社したとき、可用性の問題を修正する責任がありました。可用性の問題のほとんどはパフォーマンスの低下が原因であるため、コードのパフォーマンスチューニングを行っており、スケーラビリティが大幅に向上し、アップタイムが大幅に向上しています。密度を上げる準備が整いました。言うまでもありませんが、私の給与は100万に近いものではありません(希望!)

TL; DR

徹底的なコスト/利益分析を行うと、コードを修正する方が安価であることがわかります。あなたが無視する既知のパフォーマンスの問題は、技術的な負債に変わります。


1
すべてのコスト/利益分析が「コードを修正」するわけではありません。プログラマ...非常に高価であり、あなたはプログラマのコストよりも少ないためにRAMを追加し、それでも問題を解決することができれば
ロバート・ハーヴェイ

クラウドホスティングの状況に非常に移行しているので、実際に電力料金を支払っていることがわかります。たとえば、データベースにはAmazon RDSを使用します。最大のインスタンスと2番目に大きなインスタンスの違いは約です。年間3500ドル。これは、プログラマーが最適化するのに多くの時間を費やす価値があるかどうかを調べて判断できる数値です。
Carson63000 14

@RobertHarvey確かに、絶対に外に出すべきではなかった。私が言いたかったことは、絶対に「ハードウェアは開発時間よりも安い」というのは絶対に真実ではないということでしたが、あなたは正しいです。
ブランドン14

-2

私はあなたの質問を次のように理解しました:十分なパフォーマンスを達成するために(つまり、ユーザーが満足しており、私のバックエンドが縮まない)、アルゴリズムの複雑さの理論を理解する必要がありますか?

「典型的な」ビジネスアプリケーションの意味に依存します。多くの場合、特に単純なCRUDのような情報システムでは、答えはノーになります。これらの場合、パフォーマンスのボトルネックをトレースできるようにする必要があります(データベースのインデックスが欠落していませんか?)。ネットワーク経由で大量のデータを送信しますか?angular.jsフロントエンドに1000個の$ watchがありますか?これは、健全なアーキテクチャを構築し、技術スタックを十分に理解し、無意味なことを回避することです。あなたが優秀なクラフターであり、必ずしもコンピューター科学者ではない場合、それを達成できます。別の言い方をすれば、Oracleクエリオプティマイザーを作成した人たちはアルゴリズムの複雑さを扱っているので、提供されたものを適切に使用するだけです。

現在、例外があります。ビッグデータや機械学習について話している場合、利用可能なデフォルトのアルゴリズムを使用するだけでなく、自分が何をしているかを知る必要があります。フロントエンドでも、高度なデータ視覚化の構築を開始する場合、それらの一部は非線形の複雑さのコスト(たとえば、強制レイアウトチャート)を意味する可能性があります。

現在、これらの例外はますます一般的になりつつあり、それらを処理できる人を探しているとき、市場はかなり乾燥しています。そのため、はい、コンピューターサイエンスのバックグラウンドがなくても成功できますが、一部のコンピューターサイエンスではさらに成功します。


-2

他のレスポンダーは基本的なポイントのほとんどをカバーしましたが、並列化できるタスクでは、非効率なソフトウェアはより多くの電力を使用し、より多くのスペースとメンテナンスを必要とするサーバーの形でハードウェアコストの増加につながります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.