0

私はいつも動的コードのためのものを持っていました。多くの作業を行わなくても、クールな新機能を簡単に追加できるコード。そのため、私は多くの動的フレームワークを構築し、それらをプロジェクトで使用しています。小さいものもあれば大きいものもあります。

例として、今日でもほとんどすべてのプロジェクトで使用している小さなカスタムエラーレポートフレームワークを構築しました。

これがどのように機能するかの簡単な例です：

error_reportLibrary.php-これはすべての魔法が起こる場所です。クラスとすべてのメソッドはここにあります。これは、フレームワークが必要なときに含まれるファイルです。

error_reportConfig.php-これは私の構成が行くところです（エラータイプなど）。このファイルの例を次に示します。これにより、小さなフレームワークがどのように機能するかをかなりよく説明できます。

（コード内のコメントは、各要素が設定として何をするかを説明する必要があります）

# ------ Main Settings ---------

$error_handlingSettings['errorStat']=true;//set this to false, and I wont display any errors. I don't care what the other errorTypes have to say.
$error_handlingSettings['default_highlight_color']="red";//this is the default highlight color that will be used if no color is defined for a specific errorType

# ------ Open API -------
$error_handlingSettings['open_api']['status']=true;//set this to true and I'll show errors for the Open API
$error_handlingSettings['open_api']['highlight_color']="#0ff";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['open_api']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['open_api']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['open_api']['remote_addr'][]="127.0.0.1";//and this IP

# ------ SQL Core -------
$error_handlingSettings['sql_core']['status']=true;//set this to true and I'll show errors for the SQL Core
$error_handlingSettings['sql_core']['highlight_color']="orange";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['sql_core']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['sql_core']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['sql_core']['remote_addr'][]="127.0.0.1";//and this IP

したがって、おそらくおわかりのように、各エラータイプは、フレームワークを使用しているプロジェクトの異なる部分にすぎません（たとえば、SQL Coreは、使用しているデータベースフレームワークです。したがって、dbクエリの問題が発生した場合、このerrorTypeは次のようになります。エラーを印刷するときに調べました）。

したがって、印刷エラーの場合、これは構文です。

errorModule::doError("errorType","error messege");

ご覧のとおり、私にできることがいくつかあります。特定のIPアドレスに表示し、エラーテキストを強調表示するように、私は自信を持って言うことができます。フレームワークのスケーラビリティには影響しません。

上記は、プロジェクトで作成/使用する動的フレームワークのほんの一例であることを忘れないでください。

さて、質問に対して（ほぼ）：私の大学のいくつかから、スケーラビリティに関しては、上記のような動的なフレームワークはひどいものだと言われました。それらが非常に保守可能であるという事実に関係なく。したがって、1日に100万以上のリクエストを受け取るWebアプリで上記のフレームワークを使用すると、完全に失敗します...

今、私は彼らの意見に反対していません（実際には....）が、これがなぜであるか知りたいですか？上記のような動的フレームワークがスケーラビリティに悪いと見なされるのはなぜですか？

4

2 に答える 2

2

「動的フレームワーク」を作成するとき、あなたは要点を見逃していると思います。

私の以前のPHPコードの多くは、このように機能していました。一連のメソッドと、配列の構成を追跡するためにグローバルを使用して状態を設定する構築メソッドを備えたクラス。これらはすべて、完全にOOPアプローチと比較して多くのメモリを使用していました。はい、メモリは少なく、「既成の」ソリューションよりも高速です。私が現在フレームワークを設計する方法と比較して何もありません。

インターフェイス、抽象クラス、クラスとインターフェイスの継承の両方などを利用しているようには見えません。これらのタイプのフレームワークは、元のコードベースが非常に小さく、特定のOOP機能（PHP 5.xの魔法のメソッドなど）を利用しているため、拡張性があります。

あまり負担がかからないサーバー上で実行するのに十分高速であると感じたスクリプトに、たとえば100を掛けると、問題が発生します。そして、メモリが不足し、ページが不足しています。そして、サーバーでより多くのリソースを再起動/スローすることを余儀なくされるポイントまで物事がクロールします。

なんで？OOPを実行しようとし、そのように見せようとする、不十分に記述された手続き型コードは、古い習慣を新しいパッケージにまとめているだけです。

于 2012-06-17T01:12:57.387 に答える
0

PHP は一般的に遅くて扱いにくいです。それは高レベルで、各ラインが「荷物」を運ぶことを意味します。1 行の PHP コードが多数の低レベル命令に変換されることはよくあることです。

PHP の基礎となるシステムに大きく依存する「動的な」フレームワークを引き続きスケーリングでき、高レベルの抽象化で多くの時間やメモリを浪費することはありません。

私の意見では、大規模で「便利な」フレームワークは、本番環境で問題が発生すると、解決するよりも多くの問題を引き起こすことがよくあります。私のお気に入りの先生はいつも KISS -- Keep It Simple Stupid を思い出させてくれました。

もちろん、真にスケーラブルなパフォーマンスが必要な場合は、php をHiphopでコンパイルするか、C++ や D などのコンパイル済み言語でアプリケーションを作成することをお勧めします。

于 2012-06-17T01:36:20.963 に答える