日記帳
本ページはプロモーションが含まれています
カテゴリー
Links
blog(ブログ)マスター
アンドロイドの巣
ゼロから始めるベランダ菜園
タイトル
2024年11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

Search Results

Django CGI(5.x / 1.x 2.x)

執筆:2019.07.08
編集:2019.07.08
編集:2024.08.04



(2024-08-04)
PythonのバージョンとDjango を最新の5.0をインストールするとDjango 2.xのコードは そのまま動きました!

相変わらずオーバーヘッドが大きい

CGI版での速度 (調査日 2024年8月4日)

サーバー
(apache2.4)

django(CGI)
django 5.0
Python 3.12

ディフェンダーの設定
C:\Program Files\Python
を除外設定

/admin/
hello
Windows11
(ローカルホスト)
2.10~2.70秒 約1.5秒
★ C:\Program Files\Python\3.12\Lib\site-packages\django の除外設定だけでも効果がありました。


(2024-07-18)
しばらく使っていない間に、The latest official version is 5.0.7.になっていますね
https://www.djangoproject.com/download/

https://docs.python.org/ja/3.12/library/cgi.html
Python cgiモジュールは、バージョン 3.11 で非推奨、バージョン 3.13 で削除予定とありますね
上記ページで3.13以降のマニュアルにするとなくなっています。

ということで、Django をCGIとして動作させる裏技は将来的に封殺されるかもしれないです。

CGIアプリケーションを作りたい場合は、Pythonは候補からはずれるということです。

格安運用でdjangoがいい場合は、共有サーバーではなく、安いVPS(仮想専用サーバー)を借りないといけないのかもしれないですね~。400円/月くらいですか?
VPSは自己管理なので面倒ですよね~

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で動作させると とても時間がかかります。

速度比較いろいろ

django1とdjango2の速度差はそれほどなく、若干django2のほうがレスポンスが速い傾向にありました。

django

サーバー CGI

manage.py
runserver

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秒
※ 時間は、URL呼び出し開始からデータ取得終了までにかかった時間。
※ C言語バイナリが最小時間は一番小さかった。

CGIのサイズ
ファイルサイズ hello.cgiの種類
1,988,354 GO バイナリCGI
6,604 C言語 バイナリCGI
140 PHP CGIスクリプト
115 perl CGIスクリプト
2019.07.08

さくらインターネット ライトプラン で django2.0 + python3.6

執筆:2018.06.15
編集:2018.06.15


設定の仕方
導入方法は関連ページへ

サイト内 関連ページ
  1. さくらインターネット ライトプランに python3をインストール
  2. Django2 CGI handler + apache2.4

応答速度
応答速度
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 脆弱性
2018.06.15

Django2 CGI handler + apache2.4 : メモ

執筆:2018.06.13
編集:2018.06.13


概要
python3.6 + django 2.0.6
  1. .htaccess に cgi用のエントリを追記する
  2. start-django.cgi を設置する(名称はなんでもいい)
    wsgi_emulate.py または wsgi_over_cgi.pyをimportする
  3. wsgi_emulate.py または wsgi_over_cgi.py を settings.py と同じフォルダに設置する
以上をすませて、アクセスすると CGIモードで動作する

基本的に wsgi_over_cgi.py 内の
from wsgiref.handlers import CGIHandler
from . import wsgi
app = wsgi.get_wsgi_application()
CGIHandler().run(app)
だけで動かないといけないのですが、django内の処理が間違っているために、環境変数名の変更 及び
PATH_INFO、FORCE_SCRIPT_NAMEの変更設定がwsgi_emulate.py または wsgi_over_cgi.py および setting.py内に追加されています。


IfModuleで条件指定しているため
wsgiモジュールが有効になった場合は自動的にwsgiで動作する

必要な設定
.htaccess

# 追加分
<IfModule !mod_wsgi.c>
<FilesMatch "\.(?i:pyc?)$">
order deny,allow
deny from all
# RewriteRule "" - [L,R=404]
</FilesMatch>

# wsgi_emulate.py 内で この値をもとに正しいURLを生成できるように成形される
setenv BASE_URI    /    # / or /pathtositetop
setenv SCRIPT_URL /    # / or /pathtositetop/

RewriteRule "^$" start-django.cgi [L,T=application/x-httpd-cgi]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule "." start-django.cgi [L,T=application/x-httpd-cgi]
</IfModule>

apacheが古くて、環境変数が渡らない場合は
start-django.cgi に以下を追加する
os.environ.setdefault("BASE_URI", "/") # / or /pathtositetop
os.environ.setdefault("SCRIPT_URL", "/") # / or /pathtositetop/
こちらに書き込んでいたほうが確実だろう

表示されない場合
  • start-django.cgi ファイルの実行権限がついているか確認する
  • djangoへのパスが通っているか?
    • インストールする場合
      pip3 install Django
    • 指定フォルダから読み込む場合
      スクリプト内で
      sys.path.append("パス")
  • pytzの確認
    pip3 install pytz
  • No module named '_sqlite3'
    sudo pkg install databases/py35-sqlite3
# https://www.djangoproject.com/download/
# https://pypi.python.org/pypi/pytz#downloads
2018.06.13

python3をインストール : さくらインターネット ライトプラン

さくらインターネットの
Ruby と Python は古すぎて使い物にならない
Ruby /usr/local/bin/ruby 1.8.7
Python /usr/local/bin/python 2.7.6
2018/06

ローカルのcygwinでバージョンを見ると
ruby 2.3.6
Python2  2.7.14
Python3  3.6.4

virtualboxにいれているテスト用のfreebsd9でも Python 2.7.13 が返ってくる(pkg upgradeとうったが最新だよっていわれ、もう更新できない。)

FreeBSD9は tlsv1 なので
最新のものに更新していない古いバイナリを実行すると
'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:833)'),)'
などのエラーが発生する

  さくらインターネットで使われている python 2.7.6はいつごろか追うと 2014Q3 ということがわかった。 2014Q4からは、2.7.8になっているので
4年以上も放置されているということになる
ということで、pythonを使いたい人はさくらインターネットの共有サーバーはやめておいたほうがいいでしょう。
OSのアップグレード待つか、新規契約して新しいサーバーに移るしかないですね。

注意点(リスク)
せっかくインストールしてもサーバーOSがアップグレードされると
.soファイルのリンク切れで
自前Buildアプリはすべてダウンしてしまうので気を付けましょう

さくらインターネットは FreeBSD9(FreeBSD 9.1) で
FreeBSD9のFreeBSD公式サポートはかなり前に終了していて(9.1:2014 年 12 月 31 日, 9シリーズ:最終 2016 年 12 月 31 日)
osのライブラリも古いので 自前buildは あまりお勧めしない

現在のFreeBSDのカレントブランチは 11 で 来年には12がリリースされる

perlの切り替えができるので、pythonでも切り替えは技術的には可能なはずなので
サポートに pythonの切り替え機能の要望を出したほうが無難でしょう

» 続きを読む

2018.06.12

Web Framework 一覧 2018

PHP

Perl
  • Mojolicious
    入手先: CPAN

Python
  • Django
    https://www.djangoproject.com/

Ruby
  • rails

C++
  • TreeFrog Framework
    http://www.treefrogframework.org/ja/

.Net
  • asp.net
2018.03.15

世界的に人気があり収入が多いのは、Python。
PHPは、だれでも容易に書けるので請負単価が安いらしい。

Webプログラミングどれを使うか悩みますね

PHP
ビジネスフレンドリーで有名。マイナーアップデートで恣意的な下位互換性を損なう変更がたびたびある。
使用中のPHPのアップデート(major or minor)には、スクリプトのメンテナンスが必ずと言っていいほど必要になり
せっかく書いたコードが2,3年すると新しいPHPで使えなくなるので
メンテナンスフリー化は非常に難しく、個人使用やオープンソースで使う場合は、他の言語を考慮したほうがいいだろう。
PHPにむかない例
  • 桁数の多い数値計算
  • メンテナンスフリー化を目指す場合
  • メンテナンス費用を抑えたい

Python
version 2と3で仕様が全く違うためアップグレードには大幅な修正を伴う。
Python3のほうが便利だがUnix系のコアがversion2を採用しているためレンタルサーバーはPython2が多い。
Webプログラミングには向かないかもしれない。高額報酬を狙うなら知っておいて損はない。
Web用のツールとして Django がある。
日本では全く人気がないが海外ではトップシェアである。

Perl
安定してはいるが、配列などの言語構造が理解しがたくミスしやすいためお勧めしない。
使う場合はしっかりコメントを書き込んで分かりやすくしておいたほうがいい。
(コメントなしでは次読むときは数年後なのできっと書いた本人ですら何かわからないでしょう)
単純なwebスクリプトならしっかりセキュリティを考慮して書いていれば、メンテナンスフリーで10年以上放置も可能なのでいいかもしれない。
非ビジネス向きの言語。

Ruby
言語仕様が好きになれない+マニュアルが分かりにくいので、何とも言えない。
筆者はテスト用サンプルを2,3個作っただけで使っていない。perlのほうがずっとマシな印象がある。
Rubyブームはかなり昔にさっており需要がないのでいまさら覚える価値はないのでお勧めしない。
バージョン間で下位互換があまりないらしいのでメンテナンスフリー化は無理です。
メンテナンス案件をゲットしたい場合は、知っておいて損はないだろう。

人には向き不向きというものがあるので、簡単なサンプルに目を通して、ストレスなく扱えるものを選ぶのが一番いでしょう。

無料 IDE
Netbeans Eclipse テキストエディタ
PHP
Python
Perl
Ruby


予算が許すのなら他の選択肢として
Microsoftのasp .net がある。GUIで構築できるので非常に直感的で楽に作れる。


カテゴリー: General
2018.03.09

PR

[PR]