Django CGI(1.x 2.x) 2019年度版
django1.x と2.xの両方で動作可能な django.cgiを作ったので速度を比較してみた。
前回とは違うアプローチをしてみたので、1個のファイルに小さく収まりました。
ベンチマークをすると CGI起動だとdjangoは 応答速度的に使えないコと判明しました。
ただし、CGIではなく常駐で運用するとレスポンスはとても速いです。
結論
原因
※ 応答速度が1秒を超えると閲覧者に遅いとストレスを感じさせてしまいます。
※ 時間は、URL呼び出し開始からデータ取得終了までにかかった時間。
※ C言語バイナリが最小時間は一番小さかった。
CGIのサイズ
執筆:2019.07.08
編集:2019.07.08
編集:2019.07.08
django1.x と2.xの両方で動作可能な django.cgiを作ったので速度を比較してみた。
前回とは違うアプローチをしてみたので、1個のファイルに小さく収まりました。
ベンチマークをすると CGI起動だとdjangoは 応答速度的に使えないコと判明しました。
ただし、CGIではなく常駐で運用するとレスポンスはとても速いです。
結論
djangoをCGIで動かすと何もなくても 0.5~0.6秒 レスポンスまでに時間がかかります。
djangoをCGIで運用することはお勧めできません。
mod_wsgiが使えない場合は、mod_phpなら導入されているサーバーは多いので、phpのフレームワークを検討したほうが賢明です。
djangoをCGIで運用することはお勧めできません。
mod_wsgiが使えない場合は、mod_phpなら導入されているサーバーは多いので、phpのフレームワークを検討したほうが賢明です。
原因
djangoは多数のファイルに分散されて、起動時にそれを読み込むため、CGIで動作させると とても時間がかかります。
速度比較いろいろ
django1とdjango2の速度差はそれほどなく、若干django2のほうがレスポンスが速い傾向にありました。
django
サーバー | CGI |
manage.py |
mod_wsgi |
localhost | 1.11秒 | 0.01秒 | 0.03秒 |
さくらインター ネット ライト |
1.23秒 | - | - |
※ 応答速度が1秒を超えると閲覧者に遅いとストレスを感じさせてしまいます。
CGI版での速度比較 (調査日 2019年7月7,8日)
サーバー (apache2.4) |
django1(CGI) | hello.cgi | |||||
/admin/ | hello | python | php | C言語 | GO | ||
Windows10 (ローカルホスト) |
5.86秒 | 2.64秒 | 0.30秒 | 0.25秒 | 0.02秒 | 0.06秒 | |
FreeBSD11 (イントラネット) |
1.11秒 | 0.51秒 | 0.03秒 | 0.03秒 | 0.01秒 | 0.02秒 | |
さくらインターネット ライト FreeBSD9 (インターネット) |
1.23秒 | 0.64秒 | 0.08秒 | 0.12秒 | 0.06秒 | 0.06秒 |
※ C言語バイナリが最小時間は一番小さかった。
CGIのサイズ
ファイルサイズ | hello.cgiの種類 |
1,988,354 | GO バイナリCGI |
6,604 | C言語 バイナリCGI |
140 | PHP CGIスクリプト |
115 | perl CGIスクリプト |
カテゴリー: レンタルサーバーやcgi
2019.07.08
cygwin
451: $result = zlib_decode($result);
なぜか50MBしか割り当てられていないとエラーが表示されます。
確認するが 512MBきちんと割り当てられている。
zlib_decode関数が怪しい
ということでzlib_decode関数をいじめてみます。
ということは、
・cygwinのphpにメモリリーク
・phar がメモリを食いつぶしている
・composer がメモリを食いつぶしている
あたりが疑われます
これ以上の追及は時間の無駄(というかわからない)なので
dosプロンプトで実行して解決
PHP Fatal error: Out of memory (allocated 49807360) (tried to allocate 2140027 bytes) in phar:///usr/local/bin/composer/src/Composer/Util/RemoteFilesystem.php on line 451
451: $result = zlib_decode($result);
なぜか50MBしか割り当てられていないとエラーが表示されます。
確認するが 512MBきちんと割り当てられている。
php -i | grep memory_limit
memory_limit => 512M => 512M
php -r "\$s = str_repeat(' ', 1000*1000*1000);"
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 1000000024 bytes) in Command line code on line 1
zlib_decode関数が怪しい
ということでzlib_decode関数をいじめてみます。
php -r "\$s = zlib_encode(' ',ZLIB_ENCODING_DEFLATE); str_repeat(\$s, 100*1000*1000);"
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 900000024 bytes) in Command line code on line 1
予想と違う結果で、きちんと設定値が返ってきました。ということは、
・cygwinのphpにメモリリーク
・phar がメモリを食いつぶしている
・composer がメモリを食いつぶしている
あたりが疑われます
これ以上の追及は時間の無駄(というかわからない)なので
dosプロンプトで実行して解決
curl -O https://getcomposer.org/composer.phar
php composer.phar オプション
php composer.phar オプション
カテゴリー: レンタルサーバーやcgi
2018.06.20
>pip3 list --o
python3最新版をいれたのにアップグレードが表示されるとは・・・。
>pip3 install --upgrade pip
>pip3 list --o
pip (9.0.3) - Latest: 10.0.1 [wheel]
setuptools (39.0.1) - Latest: 39.2.0 [wheel]
You are using pip version 9.0.3, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
setuptools (39.0.1) - Latest: 39.2.0 [wheel]
You are using pip version 9.0.3, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
python3最新版をいれたのにアップグレードが表示されるとは・・・。
>pip3 install --upgrade pip
Collecting pip
Downloading https://files.pythonhosted.org/packages/.../pip-10.0.1-py2.py3-none-any.whl (1.3MB)
Installing collected packages: pip
Found existing installation: pip 9.0.3
Uninstalling pip-9.0.3:
Successfully uninstalled pip-9.0.3
Successfully installed pip-10.0.1
Downloading https://files.pythonhosted.org/packages/.../pip-10.0.1-py2.py3-none-any.whl (1.3MB)
Installing collected packages: pip
Found existing installation: pip 9.0.3
Uninstalling pip-9.0.3:
Successfully uninstalled pip-9.0.3
Successfully installed pip-10.0.1
>pip3 list --o
Package Version Latest Type
---------- ------- ------ -----
setuptools 39.0.1 39.2.0 wheel
---------- ------- ------ -----
setuptools 39.0.1 39.2.0 wheel
カテゴリー: レンタルサーバーやcgi
2018.06.19
さくらインターネット ライトプラン で django2.0 + python3.6
設定の仕方
サイト内 関連ページ
応答速度
ブラウザだとdjangoは少し遅く感じますが、機械的な取得だとほぼ同じという結果になりました。
djangoのデフォルトページに描画処理があるせいでブラウザだと遅いのかもしれないですね
pythonのほうは、この速度にさらに表示用のなんらかの処理を加えることになるので
phpのほうがcgi応答速度は速いということになります。
djangoは脆弱性がわりとあるようなので、ライトプランというcronが動作しない自動更新できない環境ではちょっと勇気がいる
djangoの導入は見送りになりそう。
キーワード
執筆:2018.06.15
編集:2018.06.15
編集:2018.06.15
設定の仕方
導入方法は関連ページへ
サイト内 関連ページ
応答速度
応答速度 | ||
django2.0 + python3.6 (デフォルトページ) |
PHP製のCMS (運用しているサイト) |
|
ライトプラン |
0.48 - 1.41秒 |
0.50 - 1.46秒 |
https:// min : 0.48 max : 1.41 avg : 0.85 n[20] |
https:// min : 0.50 max : 1.46 avg : 0.85 n[20] |
|
備考 | 体感で遅く感じる | 気にならない |
ブラウザだとdjangoは少し遅く感じますが、機械的な取得だとほぼ同じという結果になりました。
djangoのデフォルトページに描画処理があるせいでブラウザだと遅いのかもしれないですね
pythonのほうは、この速度にさらに表示用のなんらかの処理を加えることになるので
phpのほうがcgi応答速度は速いということになります。
djangoは脆弱性がわりとあるようなので、ライトプランというcronが動作しない自動更新できない環境ではちょっと勇気がいる
djangoの導入は見送りになりそう。
キーワード
Django2 CGI handler
Django2 CGI handler さくらインターネット 共有サーバー
Django2 python3 さくらインターネット 共有サーバー
django 脆弱性
Django2 CGI handler さくらインターネット 共有サーバー
Django2 python3 さくらインターネット 共有サーバー
django 脆弱性
カテゴリー: レンタルサーバーやcgi
2018.06.15
AH01215: suexec policy violation: see suexec log for more details
AH01215: suexec policy violation: see suexec log for more details
さくらインターネット
.cgiの1行目のパスを間違っていた
#!/home/ユーザー名/local/bin/実行名
ユーザー名を間違っていて(契約とは違う別のアカウントを指定していたため)
気が付くのに1時間以上かかってしまった。
「パスがありませんでした」くらいのメッセージにしてくださいよ。
執筆:2018.06.14
編集:2018.06.14
編集:2018.06.14
AH01215: suexec policy violation: see suexec log for more details
さくらインターネット
.cgiの1行目のパスを間違っていた
#!/home/ユーザー名/local/bin/実行名
ユーザー名を間違っていて(契約とは違う別のアカウントを指定していたため)
気が付くのに1時間以上かかってしまった。
「パスがありませんでした」くらいのメッセージにしてくださいよ。
カテゴリー: レンタルサーバーやcgi
2018.06.14