Webアプリケーションの起動時間は本当に重要ですか?


11

アプリケーションの起動時に初期化コードを追加することについて誰かと会話し、起動時間の増加を引き起こすことについて不平を言いました。彼は本当に理由を述べることができませんでした(直感や何か、知らない)。これは頻繁に使用するアプリケーションではなく、約1分程度で開始され、年に数回展開します。

私はしばらく前にSOに関する質問でそのようなアドバイスを読んだことを覚えています。

私は30秒から4〜5分で開始したWebアプリで作業しましたが、オンラインになるとそれらは揺れ動きました。

だから私は何が欠けていますか?金融市場、医療アプリケーション、宇宙探査などのように、重要なアプリケーションでなければ...分からない...起動時間は本当に重要ですか?

PS私は厳密にWebアプリについて言及していますが、デスクトップアプリは急速に起動します。


アプリケーションの起動に定義された非機能要件がありますか、またはこれは開発中の単なる議論ですか?
StuperUser

@StuperUser:要件はなく、これまでの議論だけです。
JohnDoDo

実際に、ユーザーエクスペリエンスサイトでは、これをより適切に確認できます。
サイクロプス

@Cyclops:実際には、ユーザー側からではなく、フェンスのサーバー側の理由に興味があります。
JohnDoDo

回答:


18

開発中の大きな要因になる可能性があります。プラットフォームが実行中のアプリケーションでコードの変更をサポートしていない場合、起動時間がフィードバックサイクルの一部になり、30秒でさえ痛みを伴い、生産性への脅威になります。

実稼働環境では、実際には問題ではありません。少しのダウンタイムは許容できますが、5分はそれほど長くないか、そうではないため、何らかのライブスイッチオーバーを実装する必要があります。


はい、開発サイクルについてはよく考えましたが、コンマの変更、デプロイ、変数名の変更、デプロイなどとは異なります。私は個人的に1日に最大10回開発にデプロイします。1分間のスタートアップまたは1.2はそれほど大きな違いではありません。
JohnDoDo

7
@JohnDoDo:そのどれが本当に自然なワークフローであり、長時間の展開を習慣的にどれだけ回避していますか?迅速なフィードバックサイクルは、生産性に非常に役立ちます。時々、小さなインクリメンタルな変更を行い、すぐに結果を見ることが本当に必要なものです。50年前、人々はプログラムを紙に書いてオペレーターに提出し、翌日には印刷結果を得ました-時には単にコンパイラーエラー。それはあなたにとっては恐ろしく非効率的な方法のように思えませんか?多くのプログラマーにとって、1日あたり10回の展開はまさにそのように思えます。
マイケルボルグワード

1
可能であれば、「モック」初期化を行うオプション、またはテストデータを使用して構造をディスクにシリアル化して、開発中の起動時間を短縮するオプションを評価します。
ビンコヴサロビッチ

私はVinkoに同意します、デバッグモードでビルドするときに高価なinit()関数をオフにする方法はありますか?ただし、初期化するものがDevとProductionで異なる結果をもたらすかどうかは気にしないでください。
AndyMcKenna

4

これは、量から品質への移行というヘーゲルの有名な弁証法的原理が実際に機能する場合だと思います。

タイミングが常に重要です。開発/テスト中のクイックビルドの重要性についてのMichael Borgwardtの言葉には同意しますが、(他の方法で)ビルドにも非常に重要であると主張します。

いくつかの悪いコードを実稼働環境に展開した各開発者は、5分と1分で提供される修正プログラムが実際にはまったく異なるものであることを知っています。


2

本当の質問は、アプリが初期化なしで機能するかどうかです。「パフォーマンス」にこだわる新入社員がいます。私の答えは、あなたがどれだけ早く間違った結果を出すかは気にしません。私見は、「この方法で速くなる」ためアルゴリズムをマングリングし、他の素晴らしいアイデアはバグを導入するだけです。

初期化が必要な場合は、実行してください。エンドユーザーが間違った結果を取得し、最終的にWebアプリが間違っていることを把握し、電話して文句を言うと、戻ってデバッグ/修正/テスト/再デプロイする必要がある場合、どれくらいの時間が無駄になりますか?今、どのように時間が節約されたか同僚に尋ねてください。(そして、とにかく、サーバーコアは99%アイドル状態であると思います)


2

この質問は、特定のプラットフォームについては尋ねません。起動時間が本当に重要なプラットフォームがあります。

たとえば、Google App Engineの場合。ページにアクセスできない場合(または、同じノード上の別のアプリケーションよりもアクセス頻度が低い場合)、ページは時々アンロードされます。

したがって、サイトアクセス頻度の下位99%にいる場合、起動時間アクセス時間です。アプリケーションはほぼすべてのアクセスで再起動されます。あなたがあればある上位1%で、その後、あなたのアプリケーションは、多くのノード上に入門され、多くのページのアクセスがすでに始まっインスタンスから返されますが、いくつかはまだないでしょう、そしてあなたは、断続的な、長いアクセス時間を持っていますので、 。

これと同じことが他の多くのホスティング環境にも当てはまります。サードパーティのライブラリ、または単に発見を逃れた独自のコードでのリークは、Webサービスを実行する唯一の信頼できる方法は、非常に多くのリクエスト(多くの場合100から10,000)をリロードすることであることを意味する可能性があります起動時間は頻繁に支払われます。このパターンの使用は、アプリがリークしている場合でも許容されますが、すぐに起動します。アプリの起動に数秒以上かかると実行できなくなります。


1

あなたは、アプリケーションが標準以下またはさらに悪いことに開発能力と見なされる危険を冒しています。現在、このアプリは誰かを非常に多くの時間を節約している、および/または感謝のユーザーが長いスタートアップを過ぎて見ることができるような必要なタスクをしているかもしれません。

アプリを遅延ロードするような方法でプログラムを作成するのに時間がかかる場合がありますが、その価値があるかどうかを判断できるのは関係者のみです。55秒で実行されたレポートがありました。35に減らしました。誰も気づきませんでした。私は35から18の2倍の時間を費やしましたが、誰もがそれに気づき、感謝し感動しました。年に数回使用されるアプリを5分から3分に変更することは大したことではありません。ユーザーは、Facebookで過ごす時間やコーヒーを飲む時間が少なくなります。

知覚が鍵です。一般的に、特にこのアプリが開発チームに満足していない場合、善意を築き、スピードアップを図りたい場合があります。


ただし、Webアプリケーションの起動時間が通常のユーザーに影響することはありません。もう一方の開発者は、通常の開発の一環として1日に何度も個人的にアプリを再起動するため、イライラしています。
AndyMcKenna
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.