5

これはしばらくの間私を悩ませてきました。

デプロイされた PHP Web アプリケーションでは、変更された php スクリプトをアップロードし、更新されたファイルを再起動せずに Web サーバーに取得させることができます。

問題?Ruby、Groovy、Python などはすべて、言語の表現力、簡潔さ、パワーなどの点で、PHP よりも「優れています」。

現在、Groovy を (Grails 経由で) 楽しんでいますが、実際には、JVM は、アプリケーション コードの本番環境での動的なリロードを (まったく) うまく処理できません。基本的に、Permgen のメモリ不足エラーは事実上の保証であり、これはいつでもアプリケーションがクラッシュすることを意味します。これは良くありません。

Rubyフレームワークは、私が読んだことからこれをある程度解決しているようです.Passengerには、次のリクエストでポーリングされたディレクトリに変更されたファイルを動的にリロードするオプションがあります(したがって、接続されているユーザーが切断されたり、セッションが失われたりするのを防ぎます).

スタンドアロンの Python については、まったくわかりません。PHP のように、Web サーバーを再起動せずに Python スクリプトを動的にリロードできます。

私たちの Web 作業に関する限り、仕様がどれほど詳細で綿密に計画されていたとしても、クライアントは常にデプロイされたアプリケーションに変更を加えたいと思うようになります。クライアントに「確かに、明日の午前 4 時に [単純な] 変更を実装します [接続しているユーザーに混乱を引き起こさないようにするため]」と伝えても、うまく行きません。

2011 年現在、動的リロードとスクリプト言語に関して、私たちはどこにいるのでしょうか? PHP の利便性に追いやられ、PHP 以外の楽しみに追いやられ、デプロイされたアプリケーションの再起動を余儀なくされるのでしょうか?

ところで、私は JSP、GSP、Ruby、Python の同等のテンプレートを再読み込みできるにもかかわらず、まったく好きではありません。これは簡単なスレッドであり、アプリケーションのあらゆる側面を変更でき、再起動する必要はありません。

4

2 に答える 2

4

Web サーバーが指定されていません。Apache を使用している場合、mod_wsgi は Python Web アプリを実行するための最善の策であり、サーバーの再起動を必要としないリロード メカニズムを備えています。

于 2011-02-16T08:27:57.820 に答える
4

あなたは実際よりも大きな取引をしていると思います。

毎分 1/2 ダウンしないことが非常に重要なアプリケーション (ファイルの変更を取得するためにサーバーを再起動するのに必要な時間) は、潜在的な障害を処理するために複数のアプリケーション サーバー インスタンスが必要です。個々のインスタンスの。障害を処理するアプリケーション サーバーが複数ある場合は、問題を引き起こすことなく、メンテナンスのために個々のインスタンスを安全に再起動することもできます。

于 2011-02-16T08:30:15.727 に答える