タグ: WordPress

キャッシュや持続性接続で、瞬間的に早い場面が増えたが、一定時間経過するとやはり遅くなる。
DBやPHPの動作を見ていると、アイドル時間が一定に達したタイミングでプロセスが終了したり、DBセッションが終了していた。
今日はこれを変更してみる。

データベース – Azure Database for MySQL

Azureのポータルから「Server parameters」より以下の設定を120から変更
モニタしていると１２０秒きっちりに持続性接続が失われていたので、この設定を変更した。
28800秒→480分→8時間
なんとなく日本の１日のフルタイム就業時間。
（ただし、リクエストがあると残業対応）

App Service

Azure のポータルから「アプリケーション設定」よりPHPの設定をオフ

とすると、当然PHP動かなくなる。
次にサイトルートの web.config でハンドラの設定追加。

<configuration>
  <system.webServer>
  <fastCgi>
     <application fullPath="D:\Program Files\PHP\v7.2\php-cgi.exe"
           arguments=""
           maxInstances="0"
           idleTimeout="28800"
           monitorChangesTo="php.ini"
           activityTimeout="600"
           requestTimeout="601"
           instanceMaxRequests="10000"
           protocol="NamedPipe"
           flushNamedPipe="false">
        <environmentVariables>
           <environmentVariable
              name="PHP_FCGI_MAX_REQUESTS"
              value="10000" />
        </environmentVariables>
     </application>
  </fastCgi>
    <handlers accessPolicy="Read, Script"> 
      <add name="PHP-FastCGI"
         path="*.php"
         verb="GET,HEAD,POST"
         modules="FastCgiModule"
         scriptProcessor="D:\Program Files\PHP\v7.2\php-cgi.exe"
         resourceType="Either"
         requireAccess="Script" />
     </handlers>
  </system.webServer>

アイドルの時間をidleTimeout=”28800″として、上記のDB接続の就業時間に合わせた。他は、おそらく元と同じ設定になってるはず…。
（10000要求こなした場合も、就業終了。）

これで、ポータルからアプリケーション再起動させて、無事に起動。
Kuduで見る限り、アイドル時間の長いプロセスが増えてる気がしている。

追記

この Web.config に記述する方法は、Managedな App Service の機能を一つ殺しているので、当然お勧めしない。（要するに運用する手間が増える。今後想定外の動きになる可能性がある。）また持続性や永続化に伴って、小さな問題が積もって大きな問題になる可能性もあるので、経過を見てみる必要がある。