PHPパーミッションについて
> PERLと違ってＰＨＰはラフなのでしょうか？ そういう訳ではありませんね(笑)。PHPでもCGI的な使い方の場合は705でないと動かないんじゃないかな。CGIとはCommon Gateway Interfaceの略ですが、ひと言で言えば外部プログラムを呼び出す仕組みの事です。 PHPはApache（WEBサーバ）のモジュールとして動いています。言い換えればWEBサーバ権限で動いている訳です。CGIのように外部のプログラムを動かす訳ではありません。PHPスクリプトをWEBサーバのPHPエンジンが読込み、そこに書いてあるスクリプトを実行しています。WEBサーバから読込む事が出来るかが重要であって（読み取り可能かどうか）、実行権限は関係無いと言う事です。 権限は最低限の方が良いでしょうから、604の方が良いでしょうね。
30. 連想配列でハッシュの使用
常識的なことですが、キーと値が対応した連想配列を使用することはよくあると 思います。何回も使用するマスターの値を配列として保存して、複数回アクセス する場合、switch文やif文を使用している場合は参考にしてみてください。 今回考えるのは「はい」、「いいえ」、「無回答」といった値が yes、no、 no_answer という文字列に対応して保存されているとします。 さらに、はい・いいえを表すために yes、no、no_answer という値がリストに 入っている場合を考えます。 $list = array( array( 'yes_no' => 'yes', '...' => '...', ...... ), array( 'yes_no' => 'no', '...' => '...', ...... ), ...... ); このリストの一覧表示ではい・いいえを出力するために、変数の
PHP5の登場、PHP5とJavaのパフォーマンス比較
以上のとおり、PHP5のデータベース接続処理はJavaと比較して2分の1以下の実行速度しかないという結果となりました。また、PHP5はPHP4と比較してもデータベース接続処理において10%近く実行速度を低下させています。 PHP5はPHP4と比較して10%〜15%実行速度を低下させていますが、この原因として考えられるのは、やはりオブジェクト指向機能の大幅な強化にあると筆者は考えています。 PHP5は、当初「Zend Engine version 2.0: Feature Overview and Design」（PDF：115KB）において目標としていたオブジェクト指向機能の強化と引き換えにパフォーマンスを犠牲にしたわけですが、この選択によってPHP5は再利用性や拡張性、堅牢なアーキテクチャの実現方法を手に入れました。 パフォーマンスの悪化は各種パッケージ製品(※1)、マシンのスペックアッ
大量件数のINSERT or UPDATE を繰り返すバッチでの注意点
１．処理速度 単純にINSERTで済む場合はCOPY文やpsqlによる手続きが便利かも知れません。 UPDATEとINSERTがどちらも含まれる場合、最初にINSERTとUPDATEの二つに分けてしまった方が早いかも知れません。 SELECT primary_column FROM table_name WHERE primary_column IN (プライマリーキーの配列３万前後）; とかで。 PRIMARYキーが40バイトだったとしても、1MB程度のメモリ量で済みそうです。 ２．メモリ使用料について ３万件のデータはファイルに入っていると思うので、単純にfopen+fgetsにしてやればそれほどメモリは使わないんじゃないかと思います。 memory_get_usage()関数を使えれば、実際にメモリ量を見てやると良い気がします。 メモリやPHPの処理よりも、Postgre側やCPU、
75. PHPの便利なコマンドラインオプションを再発見
普段はWebからの利用が多いPHPですが、CLI版のPHPを使うとシェルスクリプトの代替としても簡単に使用することができます。豊富な関数が用意されているので、バッチ処理や文字列処理を行う場合にもぴったりです。 Webサーバーとの通信を想定して作られたCGI版のPHPとは異なり、このCLI版PHPには便利な機能がいっぱいです。 今回は、このCLI版PHPを通じて、主なコマンドラインオプションを再発見しましょう。 ちなみにCLI版の詳細については、PHPをコマンドラインから使用するを参考にしてください。 ○ -v オプション（--version） PHPのバージョンが表示されます。以下のような感じの結果が表示され、cli版かどうかも確認できます。 $ php -v PHP 5.2.0 (cli) (built: Feb 7 2007 04:54:19) Copyright (c) 1997-2
サービス終了のお知らせ
平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
ハタさんのブログ : PHP で並行処理するとして
PHPでスレッドがあったらいいなーと思ったのはここ最近の事なのですが、僕がそうを思ったのはApacheの外へ出てしまったPHPたちがバックグラウンドで仕事をしていることを想定していたんですね。 ブラウザから起動するクエリで非常に重たい処理(S2Daoでも何でもいいんですが)をする場合、いったんブラウザ上からバッチ処理みたいな感覚でプロセスを分離する必要があります。(でないと処理が終わる || タイムアウトまでブラウザが応答待ちになる） で、処理を投げるまではいいんですが、その後処理の経過を知るためにはステータスコードというか終了コードを見る。という方法を教えてもらったんですが、どうもこれってカッコワルイ気がしてます。 んで、どっかにプールしている仕組みがあればいいんじゃね？という誰もが行き着きそうな所に行き着いたワケで。 絵にするとこんな感じ んで、少し調べた程度だと、PHPではWeb
日曜研究室 [技術的な日常:あなたの幸せはここにある] - phpで作成したバッチ処理をwgetを使いcronで自動実行してみた
お恥ずかしい限りなのですが、実は今までcronで何かを自動実行したことがありませんでした。 apacheのログをlogrotate?rotatelog?(どっちだったっけ?)したことはありましたが人の猿真似でしかなく、cronはなんか設定ファイルをゴリゴリ書く必要があるというイメージがなぜかあって、敬遠していました。 この前作った、SEO遊びのためのサイトにもバッチ処理があったのですが、手動で(！)実行していました。もちろん何の考えもなく手動という面倒な方法をとっていたわけではなく、まだ肝となる処理が不安定で、バッチ処理も確実に実行されるという確信がもてなかったので、モニタリングも兼ねて手動にしていました。 しかし今日、妙に複雑だったDB回りから全体的に作り直し、コアとなる処理の安定度が上がった(気がする)ので、バッチ処理も気合をいれてメールでエラーを通知する処理を組み込んだりなんか
サービス終了のお知らせ
平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
PHPからPostgreSQLに大量のデータを登録する
PostgreSQLに大量のデータを登録する際はINSERTを使って一件づつ処理するより、COPYを使って一気に登録した方が実行速度が（かなり）速いです。 そこでPHPでもCOPY文を使ってみましょう。 pg_copy_fromを使う 登録するデータが配列に入っているならpg_copy_fromだけで一気に処理できます。 配列の1要素が1レコードに対応しています。1要素内では各カラムをデリミタ（デフォルトは”\t”）で連結します。 <?php $values = array(); $values[] = "1\tname1"; $values[] = "2\tname2"; $values[] = "3\tname3"; $db = pg_connect("dbname=hogedb"); pg_copy_from($db, 'table',
DBから取得したデータを一度に沢山表示する場合の高速化 - ログ日記
Webサーバが一台の場合はPHPが処理するよりもデータベースで処理した方が早い。 あと絶対的な時間。例えばPHPで計算して一ページ表示するのに1秒かかりDBで計算して0.1秒かかる場合は、Webサーバが複数あってもどっちにロジックを持って行くかは考えもの。PHPで集計処理を行うとしても、結局DBにselect文を発行する回数は増えるわけだし。 まぁ同時アクセスの数だなぁ。新規のネットショップ程度なら一秒間に何十人もアクセスしてくることは無いと思うのでDB側で処理するのがいいかと。 ただAjaxを使ってる場合は、一人が一ページ表示中に何度もリクエストを送ることになるのでそれも考慮しないといけない。 というわけで、うちの場合は同時アクセスが少ないかつ重い処理を行うのでDB側で計算するように修正。 主な変更項目。 アクセラレータを利用する foreach を減らす 圧縮転送を行う 文字コードにE
require_once からの卒業〜（尾崎豊風に） - Devel::Bayside
PHP5 では __autoload というメソッドをオーバーライドすることで、require_once から解放されます。Zend Framework を使うことで、この機能を意識せずに使えるようになります。 ディレクトリ構成 Zend Framework には MVC の仕組みがありますが、今回はそれを使わずにオレオレ MVC に適用してみます。 index.php Test/Container.php Test/Dao.php Test/Dao/User.php Test/Controller/User.php Test/Logic/User.php scripts/user/list.php index.php リクエストを一手に受けるスクリプトです。Zend_Loader::registerAutoload() を呼ぶことで __autoload を意識せずに使えます。requi
Advanced PHP debugger
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 栗飯！ :: 研究室らしいモノ » 2005/10/06 Advanced PHP debugger php 247 5へぇ 犯人はNP_BlackListで、PHPスクリプトの性能が悪い現象を解析するためにPHP用のプロファイラを使ったので忘れないうちにメモを書いておきます。 † APD (Advanced PHP debugger) 今回はプロファイラとしてしか使っていませんが、APDのドキュメントやPECLのサマリにはA full-featured engine-level profiler/debuggerと書いてあるので、デバッガとしての機能もいろいろとあるようです。 † セットアップ ダウンロードはPECLのAPDから可能です。PHP 4.4.0で最新版のAPD 1.0.1を使おうと
PHPをより高速化するプロファイリングツールあれこれ
PHPを高速化するために中間キャッシュを使う各種PHPアクセラレータについては以前に「PHPアクセラレータで一番高速なのはどれか？」で書きましたが、そういう方法以外にどこで時間がかかっているのか（ボトルネック）を見つけ出すことによって、根本的に高速化するという手法もちろんあるわけで。 そういう作業に役立ちそうなツールがいろいろとあるようなので実際の使い方と一緒に見てみましょう。 SitePoint Blogs >> Faster PHP Apps-Profile Your Code with Xdebug 「Xdebug」というのがどうも一般的のようです。Windows用のモジュールもあり、PHP4だけでなく5にも対応。 Xdebug - Debugger and Profiler Tool for PHP http://www.xdebug.org/ Xdebugだけだとプロファイリング
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
[ThinkIT] 第2回：PHP4とJavaのパフォーマンス比較 (1/3)
浮浪プログラマの始末書:バッチ処理並列化
やなしのとさか phpのテクニックやお勉強 | 2.Smartyだけでも
サービス終了のお知らせ
http://tsuttayo.sytes.net/php/dbg/