开发者

PHP Architecture: How do I do that?

开发者 https://www.devze.com 2022-12-21 21:49 出处:网络
I need some help understanding internal workings of PHP. Remember, in old days, we used to write TSR (Terminate and stay resident) routines (Pre-windows era)?Once that program is executed, it will st

I need some help understanding internal workings of PHP.

Remember, in old days, we used to write TSR (Terminate and stay resident) routines (Pre-windows era)? Once that program is executed, it will stay in memory and can be re-executed by some hot-key (alt- or ctrl- key combination).

I want to use similar concept in web server/applications. Say, I have common_functions.php which consists of common functions (like Generate_City_Combo(), or Check_Permission() or Generate_User_Permission_list() or like) to all the web applications running on that apache/php server.

In all the modules or applications php files, I can write:

require_once(common_functions.php) ;

which will include that common file in all the modules and applications and works fine.

My question is: How does php handle this internally?

Say I have: Two applications AppOne and AppTwo.

AppOne has two menu options AppOne_Menu_PQR and AppOne_Menu_XYZ

AppTwo has two menu options AppTwo_Menu_ABC and APPTwo_Menu_DEF

All of these four menu items call functions { like Generate_City_Combo(), or Check_Permission() or Generate_User_Permission_list() } from common_functions.php

Now consider following scenarios: A) User XXX logs in and clicks on AppOne_Menu_PQR from his personalized Dashboard then s/he follows through all the screens and instructions. This is a series of 8-10 page requests (screens) and it is interactive. After this is over, user XXX clicks on AppTwo_Menu_DEF from his personalized Dashboard and again like earlier s/he f开发者_开发知识库ollows through all the screens and instructions (about 8-10 pages/screens). Then User XXX Logs off.

B) User XXX logs in and does whatever mentioned in scenario A. At the same time, user YYY also logs in (from some other client machine) and does similar things mentioned in scenario A.

For scenario A, it is same session. For Scenario B, there are two different sessions.

Assume that all the menu options call Generate_User_Permission_list() and Generate_Footer() or many menu options call Generate_City_Combo().

So how many times will PHP execute/include common_functions.php per page request? per session? or per PHP startup/shutdown? My understanding is common_functions.php will be executed once EVERY page request/cycle/load/screen, right? Basically once for each and every interaction.

Remember functions like Generate_City_Combo() or Generate_Footer() produces same output or does same thing irrespective of who or when is calling.

I would like to restrict this to once per Application startup and shutdown.

These are just examples. My actual problem is much more complex and involved. In my applications, I would like to call Application_Startup() routines just once which will create ideal environment (like all lookup and reference data structures, Read-Only-Data, Security-Matrix, Menu-options, context sensitive business execution logic etc..). After that all the requests coming to server need not spend any time or resources to create environment but can instantly refer "already-created-environment".

Is this something feasible in PHP? How? Could you point me to someplace or some books which explains internal working of PHP?

Thanks in advance.


PHP processes each HTTP request in a completely separate frame of execution - there is no persistent process running to service them all. (Your webserver is running, but each time it loads a PHP page, a separate instance of the PHP interpreter is invoked.)

If the time it takes for your desired persistent areas to be generated is significant, you may wish to consider caching the output from those scripts on disk and loading the cached version first if it is available (and not out of date).


I would say that you are likely prematurely optimizing, but there is hope.

You very frequently want multiple copies of your compiled code in memory since you want stability per request; you don't want separate requests operating in the same memory space and running the risk of race conditions or data corruption!

That said, there are numerous PHP Accelerators out there that will pre-compile PHP code, greatly speeding up include and require calls.


PHP(in almost all cases) is page oriented. There is no Application_Startup() that will maintain a state across HTTP requests.

You can sometimes emulate this by loading/unloading serialized data from a database or $_SESSION, but there is overhead involved. Also, there are other cases where a memcached server can optimize this as well, but you typically can't use those with you typical virtual hosting services like cPanel.

If I had to build an app like you are talking about I would serialize the users choices into the session, and then save whatever needs to persist between sessions in a database.

There are several ORM modules for PHP like Doctrine which simplify object serialization to a database.


I'm necromancing, here, but with the advent of PThread, it seems like there may be the possibility of a stab in the direction of an actual solution for this, rather than just having to say, in effect, "No, you can't do that with PHP."

A person could basically create their own multi-threaded web server in PHP, just with the CLI tools, the socket_* functions and PThreads. Just listen on port 80, add requests to a request queue, and launch some number of worker threads to process the queue.

The number of workers could be managed based on the request queue length and the operating system's run queue length. Every few seconds, the main thread could pass through a function to manage the size of the worker pool. If the web request queue length was greater than some constant times the operating system's run queue length and the number of workers was less than a configured maximum, it could instantiate another worker thread. If the web request queue length was less than some other (lower) constant times the OS's run queue length and the number of workers was greater than a configured minimum, it could tell one of the worker threads to die when it finishes its current request. The constants and configured values could then be tuned to maximize over all throughput for the server. Something like that.

You'd have to do all your own uri parsing, and you'd have to piece together the HTTP response yourself, etc., but the worker threads could instantiate objects that extend Threaded, or reuse previously instantiated Threaded objects.

Voila - PHP TomCat.

0

精彩评论

暂无评论...
验证码 换一张
取 消