回答:
はい、デフォルトで1日に1回に設定されるのは、Webアプリでメモリリークが発生する可能性があるという心配からです。IISアプリプールを頻繁にリサイクルすることの最大のマイナス面は、web.configの読み取り、アセンブリの読み込み、asp.netページの再コンパイル、および（プリコンパイルを信じない場合）コードビハインドが発生することです。これはかなり重いプロセスであり、アプリプールがリサイクルされた後のページの次のリクエストまで発生せず、その特定のリクエストが大幅に遅くなります。IIS7には、この問題を「対処」するのに役立つApplication Warm Upと呼ばれるダウンロード可能なモジュールがあります。
個人的には、リサイクルをスケジュールするよりも、メモリベースの最大値とアプリ起動時のログオンを併用することを好みます。これにより、アプリにメモリリークがなく、アプリプールがリサイクルされたときに間違っていることが証明されます。
1740分は29時間です。
アプリケーションプールを導入したバージョンであるIIS 6が開発されていた頃、アプリケーションプールが自動的にリサイクルされる場合は、定期的な時間間隔にデフォルトを設定する必要がありました。
ウェイドが提案した 24時間を超える最小の素数であるという単純な理由で29時間をました。彼は、1日に1回よりも頻繁に発生しない、ずらして繰り返されないパターンが必要でした。ウェイドの言葉では：「あなたは共鳴パターンを取得しません」。それ以降、デフォルトは1740分（29時間）です。
この機能は、すべてがメモリをリークしなければならなかった昔のASP時代からのホールドオーバーです。ほとんどの人は、一晩でWebサーバーの再起動をスケジュールしていました。IIS6は、1740分ごとにアプリプールをシャットダウンすることでこれを自動化しました（アプリが20分間アイドル状態の場合）。IIS7は伝統を続けました。
当時マイクロソフトから得たアドバイスは、既知のメモリリークのあるレガシーアプリがない限り、これは不要だということでした。したがって、純粋にマネージコードを実行している場合は問題ありません。
シャットオフして、アプリプールを監視します。ほとんどの複雑なエンタープライズアプリケーションは多くのレガシーコードを使用しており、そのコードの多くは少し漏れやすいものです。そのため、ほとんどのインストールでは、アプリプールをときどき再起動することは悪い考えではありません。
非アクティブな時間を監視するような他のオプションがあり、それはあなたの状況により良い解決策かもしれません。
アプリプールの起動には時間がかかり、アプリケーションの応答性が低下する可能性があるため、それらを維持するとパフォーマンスが向上します。
実際、これは、存在する可能性のあるリークされたリソースをクリーンアップするためのものです。1740分だけがトリガーイベントではありません。また、要求の特定の最大数の後、またはワーカープロセスメモリの特定の量を超えた後に発生します。MSDNライブラリに非常によく文書化されています。残念ながら、このポリシーは、セッション状態やシングルトンなどの静的なものを壊します。アプリは、ユーザーエクスペリエンスを妨げないように、ユーザーを再認証したり、必要に応じてシングルトンを再初期化するのに十分な堅牢性を備えている必要があります。ASP.NETセッションではなく、データベースで認証済みセッションを管理する必要がありました。そうしないと、これらのトリガーのいずれかが原因でサーバーがリサイクルされるたびに、ユーザーはログインページに戻されます。