Truly global variables

phpnub

Due to boredom and curiosity, I decided to start learning php 2 days ago and I've been annoyed by what seems to be a significant limitation in the way scripts are handled: namely that they are interpreted every time a page is requested and that objects and static variables do not survive after the end of a page. This seems very inefficient since everything needs to be reinitialized and recomputed for each request.

Am I wrong on this? Is there anything inherent in the php environment that is analogous to the application context in the case of ASP and Java Servlet applications? I've seen some "caching" libraries but they seem to only cache compiled pages. I am also aware of a shared memory feature but I can't figure out how to actually use it. Any help of this will be greatly appreciated.

dalecosp

<troll>You think they should sit in server memory just in case someone else happens to want to load that particular page?</bait>😃

Seriously, you certainly raise a question that might prove an interesting one to discuss. I'll be hanging out eager to hear what opines usher forth from the real pros on the forum (if any exist! 😃 )

And again, while we're here, you are aware of Sessions and the GLOBALS superglobal array?

phpnub

Yes, I want objects to be able to survive in server memory. This allows you to cache frequently used objects without having to deserialize from your db for every request. Even with session caching, you still have to rebuild the very same objects for each session. All this redundant work wastes database connections and cpu cycles.

-nub

P.S. I tried using $GLOBALS: variables did not survive across page requests;

dkruythoff

http://www.webopedia.com/TERM/S/stateless.html

ZibingsCoder

Don't really see what's so hard about the shmop functions in PHP. Long as you realize that it can only be a string value stored in the shared memory, you just need to create a simple parser for the string data.

<?php

//create the segment token
$tok = ftok("yourSegmentPathname", "t");

//create the segment array
$sgmt = array (
	'link' => null,
	'size' => -1,
	'data' => null
);

//attempt to open up the segment (fail if already existant)
$sgmt['link'] = @shmop_open($tok, "n", 0644, 1024);

//if it failed, it already exists, so try again
if ( !$sgmt['link'] )
{
	//open the segment with no mode or size identifiers
	$sgmt['link'] = shmop_open($tok, "a", 0, 0);
}

//get the segments size
$sgmt['size'] = shmop_size($sgmt['link']);

//and read the data
$sgmt['data'] = shmop_read($sgmt['link'], 0, $sgmt['size']);

/*
	Now do what you wish with the data...
*/
?>

drawmack

[man]mysqli[/man] - If you use the improved mysql functions (which are the recommended functions) and you use [man]mysql_pconnect[/man] then your database connection is saved and reused.

As far as most of the points that you make.

1) PHP is interpreted. As such is suffers all the drawbacks that any interpreted language suffers. Among these are that it must be parsed and compiled on every page load. However asp and jsp must also be compiled on every page load. You can use dlls in asp but you can't use asp on linux and only a moron uses windows for a web server. Contrary to anything MS might say windows does not make a good web server the OS is too bloated. In JSP you're compiling from byte code but you're still compiling. However in JSP often times a change in the source code doesn't force the byte code to be recompiled so this needs to be forced by deleting the old byte code, whereas in php I just change the source and have utter confidence that my next page load will use the updated source.

2) The web is stateless. Each request is a new animal. Expecting a web script to keep information between requests is kind of like saying, why does word go through it's complete start up cycle every time I open it. It just isn't the way it works. ASP doesn't work that way, PERL doesn't work that way, PHP doesn't work that way and neither does JSP. It's just the nature of the beast.

As far as the on the fly compiling of php being a problem really it's not. Download phpbb (a rather large php app) and run it on your server and watch cpu usage as the pages load. You'll note that it's nothing like the cpu usage reuqired to load a JSP page from byte code.

Weedpacket

Originally posted by ZibingsCoder
Don't really see what's so hard about the shmop functions in PHP. Long as you realize that it can only be a string value stored in the shared memory, you just need to create a simple parser for the string data.

And serialize/deserialize will help you there. As would the auto_include configuration directive so's you don't have to do that yourself either.

MarkR

PHP was designed initially to work with the Apache non-shared memory model. For this reason, shared memory has always been difficult for it.

Compare this to other app servers, like Java Servlets, ASP etc, where it assumes that it's running inside a multithreaded server which will have shared memory.

The shared memory case does seem appealing - it may have a longer startup time, and spend more time locking, but in theory at least, you can get a lot of performance (and of course, programming advantages) by caching bits.

Also you'd save on startup times. PHP must re-parse and recompile its scripts on each hit. On many applications this is extremely wasteful as the execution of the scripts could be much quicker than the parsing. Java would perhaps compile JSP on the first hit, then successively JIT it, gradually changing it into machine code (Something which never happens in PHP).

The advantage of PHP's "shared nothing" approach, is that it has very low overhead when not being used (i.e. doesn't hold heaps of memory - good for non-dedicated servers), has few locking restrictions - making it very scalable, and it's extremely robust against software failure (Even if some of your PHP pages crash, others keep working).

However, of course, one disadvantage is that PHP is extremely inefficient as a programming language compared with, say Java, or even VBscript.

There are some accelerators which improve startup times by pre-compiling and caching compiled scripts in shared memory, things like Zend Accelerator and Turck MMCache.

Some of these also provide an API for cached application data; specifically, they provide a session handler to serialise and unserialise the sessions into shared memory.

It's not clear how much more performant shared memory sessions are than, say, temporary files on a machine with plenty of RAM. Perhaps hardly at all.

In practice other app servers (Java and ASP.NET anyway), now support the serialised sessions-to-shared-DB approach, because for large server farms (which Sun and Microsoft are aiming at), it's more scalable - and more to the point, it actually works (shared memory is no good on systems which don't have any - for instance a cluster).

Mark

phpnub

Thanks for the replies everyone.

To MarkR: I appreciate the info regarding the origins of php's difficulty with shared memory.

Question in response to ZibingsCoder and weedpacket's tips: How do I manage memory using shmop? Do I need to be wary of memory leaks? If

In response to #1 of drawmack's post, I find the comments on windows and java unconstructive and misleading and I cannot help but find it slightly rude that I was called a moron. We run Win2k3 servers and they work for us. I see no point to baselessly claim that it is inferior to apache, et al when I was asking about php. Also, JSP (and the new asp.net) compiles pages on the first hit and remain compiled for the life of the application, so the "loading from bytecode" comment is incorrect. You can also compile JSP pages ahead of time if you choose to do so.

Regarding #2: http, the protocol used for the web is stateless, but web applications are not. This incongruity between the protocol and the applications that run on it is why state management and caching capabilities on the application side are important.

I am not sure about the Word comment. Are you saying it's a bad thing if Word didn't start up from scratch everytime I opened a document? If I used Word very often on my computer, I think I would appreciate the option of keeping Word in memory even after I closed the window. In fact, the Office Startup Assistant does precisely that.

-nub

ZibingsCoder

Hmm...as far as memory leaks go, the only thing I can think of that you might do by accident is specify an incorrect mode for the segment. If you create it as 0, it'll create it just fine, but then you won't be able to access it. Not even sure if that'll be a problem on Windows, but, just keep it in mind.

Also, something I think I might have misread, but Zend Accelerator is a very helpful addittion to PHP builds, especially on Windows. I know very little about it, but if it enhances the speed, etc of PHP as it says it does, it -must- do some sort of pre-compile on the scripts. It costs a bit of money, but...less than anything you could do with ASP 😉

dalecosp

Back from vacation ... good to see some discussion here.

I'm seeing a little light from both sides of this issue ... would it help if we could get a somewhat specific definition of exactly what a "web application" is, or at least an example?

davidjam

And again, while we're here, you are aware of Sessions and the GLOBALS superglobal array? - dalescop

P.S. I tried using $GLOBALS: variables did not survive across page requests; - phpnub

I'm a nub but like dalescop said, why not try the $_SESSION array. It looks to me like it is a "truly global variable" -- survives connection-to-connection and is available in all scopes. Just include session_start() at the top of the script.