Mono（2.10）XSP4 Webサーバーを使用して、オープン埋め込みLinux（ARM）上で実行されているASP.Net MVC3 Webアプリケーションをホストしています。 XSP4を起動すると、準備ができて要求を受け入れるまで数秒かかります。これまでのところ問題ありません。Mono XSPでホストされているWebアプリケーションへの最初のブラウザ要求の遅延が大きい
しかし、ブラウザ/ウェブサイト訪問者からの最初のリクエストが行われたとき、XSP4はWebブラウザがWebブラウザに表示されるまで、約55秒間取得できるすべてのCPUを使用します。これは、XSPの起動/再起動のたびに発生します。
私の最初の考えは、これがWebアプリケーション全体のジャストインタイムコンパイルであるということでした。そこで、バイナリ、.css、.js、およびビュー（.cshtml）のみを含む展開パッケージを作成しました。それはうまくいったが、依然としてこの巨大な遅れがあった
次に、Visual Studioを使用してそのWebアプリケーションをあらかじめコンパイルしようとしました（一部のMonoリリースノートに記載されています）。再びウェブサイトはうまくいったが、巨大な遅延はまだ残っていた。
私の心の中で実際にいくつかの質問：
- 最初のブラウザ・リクエストが入って来ているとき、誰もがXSPのウェブサーバが何をしているか知っていますか？これはあらかじめコンパイルされたWebアプリケーションであってもジャストインタイムコンパイルですか？
- なぜ始動後にもう一度やりますか？
- 一般的に何とかして大きな遅延を減らすことはできますか？
- 巨大な遅延を減らすことができるので、Webアプリケーション更新後の最初のブラウザ要求（XSPの後続実行間でキャッシュされる）でのみ行われますか？
どのようなヘルプやアイディアも素晴らしいでしょう。
更新：私は遅延がモノ/ ASP.NetコンパイラのDCM建物によって引き起こされ、メモリにマッピングされ/tmp/root-aspnet.../にMVC3かみそりビューをコンパイルすることを見出しところでしたがって永続的ではありません。私は現在、XSP4/Mono.WebServer/Mono-Asp.Netがこれらのコンパイル済みファイルを格納する場所を制御する方法を探しています。もし誰かがこれに慣れていると私に知らせてくれます;-)
おかげで、この素敵なヒントのためにたくさん：AOTing the system librariesはあなたのスピードアップを与えるかどうかを確認できます。システムライブラリはまだコンパイルされています（AOTing）;-) 私がまだ理解していないのは、XSPの開始時にJITが実行される理由です。以前はJITされたアセンブリをディスク/フラッシュ上に永続的にキャッシュして再利用できませんでしたか？ – Marc
もう一つのアイデアがあります。組み込みARMデバイスで時代を過ごすWebアプリケーションのスタートアップコードそのものです。この方法では、JIT /コンパイラの問題ではありません。 – Marc
私たちのコードではなく、遅れているコンパイラであることを確認しました。 – Marc