人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

PHP5.5での初歩的な質問です。
phpファイルをrequire_onceで読み込み展開する場合、頻繁に(MAX1分毎に)呼び出し時間がかかりそうな関数と、アクセス数が少なくすぐ終わりそうな関数と、同じファイルに書いても問題ないですか?
というのは、時間がかかる関数はバッチメインで処理しますが、ユーザーアクセスからも結構使用します。
バッチが占領している間、ユーザーが待たせられるということは無いのですか?
以前、同じ処理を複数書くのはカッコ悪いと聞いたことがあるので、世の中の人たちはどのようにしているのか?また、何ら問題ないのか?教えていただければ幸いです。

また、マニュアルを読んでもrequireとincludeの違いがイマイチわかりません。
文面上は理解できるのですが、そのあとそれがどういう影響でどういうところに問題が生じるのか?解らずにrequire_onceを使い続けています。
この辺も関係あるならば合わせて教えてください。

よろしくお願いします m(_ _)m

●質問者: wsapp
●カテゴリ:ウェブ制作
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● POGPI
●10ポイント

同じソースを参照しても、どちらかが待たされることはありません。
問題ないですし、同じ処理なら二回書く必要はないのでむしろそうするべきでしょう。


2 ● sasada
●40ポイント

pogpiさんのおっしゃるとおり、重い処理と軽い処理を一つのファイルに書いても、ファイル読込のパフォーマンスにはほとんど影響しませんので、心配は無用です。

あと、require文とinclude文の違いについては、ここがわかりやすいと思います。
http://php.net/manual/ja/function.require.php

require は include とほぼ同じですが、失敗した場合に E_COMPILE_ERROR レベルの致命的なエラーも発生するという点が異なります。 つまり、スクリプトの処理がそこで止まってしまうということです。一方 include の場合は、警告 (E_WARNING) を発するもののスクリプトの処理は続行します。

成功した際の動作は一緒ですが、失敗したときの挙動が異なるわけですね。


wsappさんのコメント
回答ありがとうございます。 重い処理と軽い処理に併記ついては解りました。 > 失敗した場合に E_COMPILE_ERROR レベルの致命的なエラーも発生するという点が異なります。 これは解るのですが、読み込みに失敗した場合、エラーを返そうが処理を止めようが、結局関数を読み込めてないので処理は中断されるのではないですか? それとも、読み込みエラーが発生した場合includeだと、エラー処理を記していればそこへ導けるということでしょうか? では何のためにrequireは存在するのですか?処理が早いとかメリットがないと必要ない気がしますが。 皆さんはどういうタイミングで使い分けるのですか?

sasadaさんのコメント
実際、異常終了させるか否かくらいしか意識してないですね、私は(笑) テクニカルなことを言うと、includeするソースに >|| <?php # (いろんな定義) return TRUE; ?> ||< と書いておいて、読込側で >|| if (!(include "呼び出し.php")) { # 失敗時の処理 } ||< という風に書けるので、便利ではあります。 異常終了でいいならrequireで充分でしょうけど。

3 ● tobeoscontinue
●50ポイント ベストアンサー

同じファイルに何を書くかは作者が決めていいのですが何を基準に考慮するかは人それぞれだと思います。
私の場合は使用損度や機能で分けています。よく使うもの、たまにしか使わないもの、エラー対応、mail送信など。
ある程度自分のポリシーが無いと後になってこの関数はどのファイルに入っていたっけ。ということになりかねません。

時間がかかりそうな関数heavy()と、すぐ終わりそうな関数light()とに関連性がなかったら私なら二つのファイル
foo.php, bar.phpに分けます。

バッチメイン.php
require_once 'foo.php'; // heavy()を使う

ユーザーアクセス.php
require_once 'foo.php'; // heavy()を使う
require_once 'bar.php'; // light()を使う

>マニュアルを読んでもrequireとincludeの違いがイマイチわかりません。
マニュアルによればファイルが無かった場合の対処方法の違いのようなので
私なら想定外の事が起こったのなら被害を拡大させないためにそこで停止してもらったほうがいいのでrequire、require_onceを使います。
自分で対処がしたいのならinclude、include_onceでコントロールをもらい後始末などをすることになるでしょう。

pluginのように前もってファイルの存在が解らないけどファイルがあればそれをincludeすることで新しい機能が使えるようにもできます。
requireにはこのような機転はききませんが要は違いを自分はどう利用するかということかと。

perlではよく
open(DATAFILE, "< data.txt") or die("Error");
というのを見かけます。ファイルをopenしてエラーだったらdie()するというもので、requireに似ています。
die()の付かないopen()がincludeという感じですか。そのためエラーが無かったかの確認が必要なのですが。

includeもrequireと同じように使っているのをよく目にします。つまりincludeのエラーに対して想定していないのです。
そのためincludeの方が危険だとは思います。(ファイルは存在しても検索パスの間違い)

requireでなければならない意外はrequire_onceでいいように思います。

>バッチが占領している間、ユーザーが待たせられるということは無いのですか?
状況がイマイチ飲み込めないorz。


wsappさんのコメント
ご回答ありがとうございます。 requireとincludeの違いについては、とても分かりやすかったです。 heavy()とlight()についても、これまたとても分かりやすい回答で感謝します。 教えていただいたことを意識して選択していこうと思います。 ありがとうございます。 > バッチが占領している間、ユーザーが待たせられるということは無いのですか? 素人の解釈ですが間違っていたら突っ込んでください。 バッチとユーザーが使う関数をheavy()と仮定します。 プログラムをサーバーがロードしたら、コンパイルしメモリーに展開され、実行終了したらメモリーが解放される。 バッチ処理のプログラムが外部通信エラーなどで思いのほか実行が中断した場合、そのメモリー領域は解放されずそのまま占領されたまま?? その間にユーザーがheavy()を使用した場合、バッチアクセスとユーザーアクセスが同じファイルにあったら競合することは無いのかな?と考えました。 しかしメモリーが飽和状態、もしくは、CPUがいっぱいいっぱい以外、他の方もおっしゃっているように、別なメモリー空間を確保し2重に関数を展開するのがコンピューターとして合理的だと思いますので、私が考えているような競合は起きないと考えを改めました。 どこかにこの考えを裏付ける資料があればなお安心しますが、ネット検索してもなかなか見つけられません。

tobeoscontinueさんのコメント
>プログラムをサーバーがロードしたら ロードとはコピーですのでバッチアクセスとユーザーアクセスがプログラムなら同じファイルがコピーされるだけなので競合とはなりません。 バッチアクセスのheavy()と ユーザーアクセスのheavy()はコピーされたものですが違うものです。 そのためバッチアクセスのheavy()が時間がかかっているからといってユーザーアクセスのheavy()が待たされるということはありません。 しかしheavy()が同じファイルに書き込みをするようなら競合を考慮する必要があります。 http://www.programming-magic.com/20080211020413/ つまりheavy()が何をしているかによって競合するのかしないのかは変わってくるというのがより正しいかと。 多くのOSでは並行処理があたりまえなので競合を頭の隅に置いてプログラムすることは大事なことだと思います。 >バッチ処理のプログラムが外部通信エラーなどで思いのほか実行が中断した場合、そのメモリー領域は解放されずそのまま占領されたまま?? 通信エラーがあればその時点でバッチ処理のプログラムが終了させられて解放されると思います。 応答が返ってこない場合でもタイムアウトまで待たされますが終了させられて解放されるでしょう。

wsappさんのコメント
丁寧に教えていただいてありがとうございます。 > 応答が返ってこない場合でもタイムアウトまで待たされますが終了させられて解放されるでしょう。 ユーザーが待たされる場合は、外部通信で応答が返ってこない場合のみで、関数を書くファイルなど教えていただいたことなど自分の法則で書けばいいということですね。 ありがとうございました。
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ