 |
Sidebar 
|
 Django CGI(1.x 2.x) 2019年度版
執筆：2019.07.08
編集：2019.07.08 django1.x と2.xの両方で動作可能な django.cgiを作ったので速度を比較してみた。 前回とは違うアプローチをしてみたので、１個のファイルに小さく収まりました。 ベンチマークをすると CGI起動だとdjangoは 応答速度的に使えないコと判明しました。 ただし、CGIではなく常駐で運用するとレスポンスはとても速いです。 結論 djangoをCGIで動かすと何もなくても 0.5～0.6秒 レスポンスまでに時間がかかります。
djangoをCGIで運用することはお勧めできません。 mod_wsgiが使えない場合は、mod_phpなら導入されているサーバーは多いので、phpのフレームワークを検討したほうが賢明です。 原因 djangoは多数のファイルに分散されて、起動時にそれを読み込むため、CGIで動作させると とても時間がかかります。
速度比較いろいろdjango1とdjango2の速度差はそれほどなく、若干django2のほうがレスポンスが速い傾向にありました。
※ 応答速度が１秒を超えると閲覧者に遅いとストレスを感じさせてしまいます。 CGI版での速度比較 (調査日 2019年7月7,8日)
※ C言語バイナリが最小時間は一番小さかった。 CGIのサイズ
カテゴリー: レンタルサーバーやcgi
2019.07.08
さくらインターネット ライトプラン で django2.0 + python3.6
執筆：2018.06.15
編集：2018.06.15 設定の仕方 導入方法は関連ページへ
サイト内 関連ページ 応答速度
ブラウザだとdjangoは少し遅く感じますが、機械的な取得だとほぼ同じという結果になりました。 djangoのデフォルトページに描画処理があるせいでブラウザだと遅いのかもしれないですね pythonのほうは、この速度にさらに表示用のなんらかの処理を加えることになるので phpのほうがcgi応答速度は速いということになります。 djangoは脆弱性がわりとあるようなので、ライトプランというcronが動作しない自動更新できない環境ではちょっと勇気がいる djangoの導入は見送りになりそう。 キーワード Django2 CGI handler
Django2 CGI handler さくらインターネット 共有サーバー Django2 python3 さくらインターネット 共有サーバー django 脆弱性 カテゴリー: レンタルサーバーやcgi
2018.06.15
Django2 CGI handler + apache2.4 : メモ
執筆：2018.06.13
編集：2018.06.13 概要 python3.6 + django 2.0.6
基本的に wsgi_over_cgi.py 内の from wsgiref.handlers import CGIHandler
だけで動かないといけないのですが、django内の処理が間違っているために、環境変数名の変更 及びfrom . import wsgi app = wsgi.get_wsgi_application() CGIHandler().run(app) 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/ 表示されない場合
# https://pypi.python.org/pypi/pytz#downloads カテゴリー: レンタルサーバーやcgi
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になっているので ４年以上も放置されているということになる ということで、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の切り替え機能の要望を出したほうが無難でしょう » 続きを読む カテゴリー: レンタルサーバーやcgi
2018.06.12
Web Framework 一覧 2018
PHP
Perl
Python
Ruby
C++
.Net
カテゴリー: ぷろぐらみんぐ／メモ
2018.03.15
世界的に人気があり収入が多いのは、Python。
PHPは、だれでも容易に書けるので請負単価が安いらしい。 Webプログラミングどれを使うか悩みますね PHP ビジネスフレンドリーで有名。マイナーアップデートで恣意的な下位互換性を損なう変更がたびたびある。
使用中のPHPのアップデート(major or minor)には、スクリプトのメンテナンスが必ずと言っていいほど必要になり
せっかく書いたコードが２，３年すると新しいPHPで使えなくなるので
メンテナンスフリー化は非常に難しく、個人使用やオープンソースで使う場合は、他の言語を考慮したほうがいいだろう。
PHPにむかない例
Python version 2と3で仕様が全く違うためアップグレードには大幅な修正を伴う。
Python3のほうが便利だがUnix系のコアがversion2を採用しているためレンタルサーバーはPython2が多い。
Webプログラミングには向かないかもしれない。高額報酬を狙うなら知っておいて損はない。
Web用のツールとして Django がある。 日本では全く人気がないが海外ではトップシェアである。 Perl 安定してはいるが、配列などの言語構造が理解しがたくミスしやすいためお勧めしない。
使う場合はしっかりコメントを書き込んで分かりやすくしておいたほうがいい。 (コメントなしでは次読むときは数年後なのできっと書いた本人ですら何かわからないでしょう) 単純なwebスクリプトならしっかりセキュリティを考慮して書いていれば、メンテナンスフリーで10年以上放置も可能なのでいいかもしれない。
非ビジネス向きの言語。 Ruby 言語仕様が好きになれない+マニュアルが分かりにくいので、何とも言えない。
筆者はテスト用サンプルを２，３個作っただけで使っていない。perlのほうがずっとマシな印象がある。
Rubyブームはかなり昔にさっており需要がないのでいまさら覚える価値はないのでお勧めしない。
バージョン間で下位互換があまりないらしいのでメンテナンスフリー化は無理です。 メンテナンス案件をゲットしたい場合は、知っておいて損はないだろう。 人には向き不向きというものがあるので、簡単なサンプルに目を通して、ストレスなく扱えるものを選ぶのが一番いでしょう。 無料 IDE
予算が許すのなら他の選択肢として Microsoftのasp .net がある。GUIで構築できるので非常に直感的で楽に作れる。 カテゴリー: General
2018.03.09
|
Sidebar |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
無料など
