Object Persistence in PHP?

persisting data to a filesystem and/or database is not the same thing

I really don’t see the difference. In one case you can store your object (or the data from the object) in a file or you can store the exact same data in memory. I don’t see how storing data in a different medium makes what you are doing conceptually different. Also, a PHP applicatoin that uses file-based Sessions is just as stateful as an app that uses memory based sessions. Both have the same issues when you scale.

What PHP looses in terms of speed when it comes to object persistance it often makes up in other areas. Also, as soon as an application grows a bit the amount of data handled escalades quickly and caching becomes harder and harder.

What other areas? I can only think of one advantage this gives PHP - that it makes it suitable for shared hosting environments. Also, I don’t think data size has much to do with how well caching works. Rather its how the data is being accessed, if on a given day 90% of the queries are for 5% of the data then its very easy to cache. There is also a lot of data that is essentially configuration info that is stored in the database when using PHP, this info is often accessed on every request yet could be easily cached if such a feature was available.

Anyhow, I find justifying these limitations has good for scalability rather funny.
They don’t make your application stateless, any interesting application on the web is stateful. They don’t make your application more scalable, in Java you can just as easily make your application distributable if desired (and likewise for .NET). These “features” are part of PHP because its primarily used to run small web apps using shared hosting (and PHP is great for this context), they make little sense outside of that context.

Yes, http is stateless, but most applications are not. In php, we must concentrate too much on protocol details, while net or java developer can build an application as if environment was stateful, with their framework taking care of protocol details.

I perceive that as a strength of PHP, and a weakness of .net and Java. You can still have stateful applications in PHP applications, but the state must be transferred to the client. This is a good thing.

I see the point (or not really yet ;)) - but wouldn’t it be just benefit if we could share objects (the way we can share primitive data now) between script calls?
Used wisely such feature could be a tremendous boost on performance of our applications.

> Couldn’t have put it better myself.

:agree:

The fact that everything dies at the end justifies the huge benifit that PHP has over a multitude of other languages; It’s not my problem if someone cannot understand the purities of PHPs architecture that, that brings to web development.

Don’t look at it from the script point of view, but look at it from the hardware point of view instead if you want to understand more…

> Used wisely such feature could be a tremendous boost on performance of our
> applications.

I shouldn’t think so; Not at all in fact. Take a look at the resource hog that Java has become in recent years? Java as a language is well smart, but as a technology it’s horse manure, technically speaking of course

This what you are asking of PHP is not what you want, and in fact it proberly would kill PHP right there and then. You, yourself will not see the benifits of PHPs architecture, if you’ve never moved an application with a given user base, from one server to another server…

I’m not talking about shared hosting either PHP as it stands is perfect, even more perfect once PHP6 arrives, and honestly people, other technologies today are jealous of what PHP is, and what it has become, and what it will become in the future.

Databases are quite good at handling concurrency issues. If multiple threads are to share the same memory, you need to make your application thread safe.

That said, I question how much performance boost we’re actually looking into. Databases cache results in memory, so they are effectively a form of shared memory.

The fact that everything dies at the end justifies the huge benifit that PHP has over a multitude of other languages

And these benefits are?

other technologies today are jealous of what PHP

I didn’t know technologies could be jealous… The developers certainly aren’t jealous, other developers mainly just crack jokes about PHP.

Take a look at the resource hog that Java has become in recent years?

I must’ve missed this, I have no trouble running Java apps on old P3 servers. The only resource you could be talking about is memory, but in fact PHP is just as memory hungry when the application is being worked. PHP’s platform only uses less resources for small apps, hence why its so great for shared hosting.

but the state must be transferred to the client.

Eh? How does one transfer a session to a client?

I question how much performance boost we’re actually looking into. Databases cache results in memory, so they are effectively a form of shared memory.

The database knows nothing about your application as a result its cache is far less useful. Also, there is still the overhead of actually connecting to the database in the first place. This overhead is even greater if the app and the database aren’t on the server. Accessing things from a local cache is an many times faster, now whether this is important for your application is a different story.

> other developers mainly just crack jokes about PHP.

They are cracking the jokes because they are envious of the success of PHP; It’s a basic human need to make fun of something or someone they don’t understand, nor have the interest to understand.

At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?

> I have no trouble running Java apps on old P3 servers.

What sort of applications were you running, and could you run one of todays enterprise level applications on one of your Pentium 3s? I sort of know your answer already…

> PHP’s platform only uses less resources for small apps, hence why its so great for
> shared hosting.

Shared hosting has got nothing to do with it; In fact, if anything it just goes to show you just how performance oriented PHP is in regards to the limited resources that shared hosting are, by their nature, in relation to the amount of load on that given server.

PHP from what I can remember on reading something on Zend uses about 40% less memory than typically what is required by the likes of Java; Unfortunately you’ll just have to take my word on that as I don’t recall the URL… But the differences were far from marginal to say the least, between Java and PHP; Again, that of course is dependent on a lot of other variables, etc.

Maybe the results were shewed a bit, I don’t know - I didn’t perform the benchmark, but the feeling I have is that PHP performs better than what Java would perform on reduced technology, hardware wise that is.

> And these benefits are?

Have you not heard of the share nothing phrase?

> This overhead is even greater if the app and the database aren’t on the server.

That isn’t an issue as such to do with PHP though… It’s a problem that is commonly shared with all technology using the Internet. Latency it’s called I think?

At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?

Lets get real here. Nobody denies that PHP has been sucessful in some sense, but PHP success is primarily with small web apps. Also I have no idea what metric you are using for “success”. Sure if we are talking about small web apps PHP has been largely successful, but Perl + cgi was also very sucessful in this same domain. But if you are talking about backends then PHP is rarely used, PHPs “share nothing” architecture makes no sense in these contents.

Have you not heard of the share nothing phrase?

Ugh, sure I’ve heard that marketing buzz word. Now, what are the real advantages of PHP for large applications? How does not sharing data between requests benefit a large application? It doesn’t benefit scabability, the application will be scalable if its distributable (which can easily be done with Java or .NET). On the other hand the advantages for small apps are clear.

That isn’t an issue as such to do with PHP though… It’s a problem that is commonly shared with all technology using the Internet.

Sure, but if you could persistent objects than you can boost performance by caching. And its not just a small boost, accessing a local in-process cache is dramatically faster than accessing a cached query from a database running on a remote server. Almost every language has a way of doing this (Perl with mod_perl, Python with mod_python, java out of the box etc), but not PHP.

You don’t. Session is a method for storing state at the server.

Depending on your application, the database may in fact know quite a bit. If you have indices and foreign keys on your tables, it can cache rather intelligently.

But that argument assumes that you can get away with not connecting at all. Is that realistic in an even moderately complex application? Oh, and I believe that you can use connection pooling if the db is non-local.

You don’t. Session is a method for storing state at the server.

You said “but the state must be transferred to the client”, are you suggesting that one shouldn’t use sessions? Maybe, I misread your initial comment.

But that argument assumes that you can get away with not connecting at all.

Right in PHP that doesn’t happen much because you store so much junk in the DB, but that isn’t necessary with other platforms. So in many cases you can get away with no database calls on cached data.

Oh, and I believe that you can use connection pooling if the db is non-local.

PHP doesn’t allow connection pooling, rather you can only have persistent connections in PHP. This differs in fundamental ways from connection pools, it would work ok in apache 2 with threads…but PHP isn’t thread friendly (or I should say many of the extensions commonly used aren’t)

Anyhow, its not just the issue of creating a connection. Its also the cost to grab the data, grabbing cached data (usually stored in a hash) from local memory is extremely fast where as even if the DB is intelligently caching your data you still have to grab the data over a socket, which in the case of a remote database can be fairly expensive. I’m not suggesting that having the ability to persist objects is always useful, but in many cases it can boost performance significantly. Additionally, having the ability to persist objects does not effect the platforms ability to scale. Personally I find the “in PHP you can scale your app by just adding hardware” view rather naive, most of the PHP apps I have seen would not scale out of a single server as they are currently implemented.

Even though PHP has a stateless architecture, you can cache things in memory, just take a look at Memcached.

I don’t believe though that you can cache a resource, and that is what the discussion is about in part at least? Which… Has lead to this arguement between the architecture of PHP and other technology.

I can’t really express myself in a way that fits words on how PHPs architecture, being stateless so to speak (nothing lives once script execution ends) is better than other technology that retains state, nor can I find facts at the moment either.

But there are blogs out there that describe better than what I could, as to why PHP is scales better in a lot of regards.

Snaily, you’ve quite often bagged PHP to an extent that I get the impression that you wouldn’t actually use it. So I’m prompted to ask why do you spend so much effort participating in this forum?

That’s a little harsh and I don’t mean to be glib. You seem to understand a great deal about web architectures and your arguments may well be valid. What’s frustrating to the uninformed like me is that such arguments tend to concentrate on very abstract explanations rather than concrete examples or use cases. This is a call to everyone: it would be great if you could provide an example that illustrated something like:
With [PHP or Java], if you did this under these conditions, the following would happen…

Er, Dr Livingston, I hesitate to say this … I’d suggest that until you

you might want to think twice about arguing with Snaily.

Having developed applications using both PHP and Java, I personally feel that for a web frontend PHP just works better than any of the Java technologies (JSP, JSF, Wicket, very small amount of Struts) that I’ve used. However, for the actual backends to websites, there are a lot of benefits to java’s statefulness; technologies like Spring just fit that role so nicely.

That said, I think something like Grails is slowly getting to the point of being something I could use instead of PHP on the frontend, with the benefit of being fully spring aware…

Well, basically yes, although it was directed at stereofrogs comment.

I think we may be talking about different things here though. We can distinguish between to types of state; There is the resource state, which is persistent data, such as the contents of an article etc. Then there is application state, which is information about a users previous interaction with the application, that has impact on subsequent requests.

Resource state should naturally be stored at the server side, but because of how HTTP works, application state should as far as possible be managed by the client. Session is basically a mechanism for storing application state at the server. As such, it should be avoided, but some times usability just trumps purity.

Theoretically speaking, a database and in-memory persistent objects could both be used to store either kind of state. If we take a look at how PHP applications are today, the distinction between resource and application state is nicely divided between databases on one side and either session or transferred state on the other.

I think that if PHP had persistent objects, it would blur out the distinction between the two types of state, and they would encourage developers to put more application state at the server. By this, i don’t mean to be condescending about PHP programmers; I believe that the language can promote certain solutions over others, and PHP’s die-with-the-request model promotes stateless applications.

So call me conservative, but I fear that persistent objects would be worse from an architectural viewpoint. Any performance gains would have to make up for that.

I prefer to have my “junk” in a relational database, rather than in-memory objects.

So I’m prompted to ask why do you spend so much effort participating in this forum

I assume you’re talking about PAD and not Sitepoint in general, but really I don’t post much in PAD. Also, I’m not really trying to bash PHP, its a great language for many jobs (and yes I don’t use it that much). The only thing I’m trying to argue is that some of PHP limitations…aren’t “features” and something good as Zend’s marketing would suggest. Rather they are genuine limitations of the platform when its used for largish sites. Also, what sort of concrete examples did you want?

As such, it should be avoided, but some times usability just trumps purity.

“Some times”, I don’t know many interesting sites that don’t require sessions (i.e., application state).

and they would encourage developers to put more application state at the server.

From my experience your typical PHP app uses the local file system all the time for application state, so if these limitations are suppose to encourage developers to write more stateless apps, it doesn’t seem to be working. I think for good reason, most applications require state. So you have two cases: 1.) Your application is stateless, in which case horizontal scaling is trivial due to the statelessness of the application. But the application will remain stateless if it was implement in Java, .Net etc too. 2.) Your application has state, here horizontal scaling is not trivial for any platform. You are going to spend just as much time making your PHP application scale in this case than you are if you wrote it in Java or .NET. But here the “enterprise” platforms actually have an advantage because there are out-of-the-box solutions for session replication etc. So despite Zend’s marketing its unclear what advantage PHP’s architecture has outside of small applications.

Also, this isn’t a limitation of the language itself, rather mod_php. You could create a module that instead works like mod_perl or mod_python (I think there is one…but its not stable).

I prefer to have my “junk” in a relational database, rather than in-memory objects.

Why? Do you just like SQL? Its much easier just to hold it in memory.

I think kyber was talking about sessions as a technique rather then that “you have to use sessions somtimes”.

The Java argument I can take, but it just something that makes me dizzy when someone suggests .NET on Windows as an Enterprise architecture. Other then that, session replication isn’t that hard to set up - and even if php takes a bit longer to setup for scaling the total time spend coding the application is alot less then the equivalent java app. Remember, processor cycles are cheap - programmers are not.

Think you missunderstood kyber again actually.

(If my response looks wierd in any way I just changed my main platform to Mac from *Nix/Win today and trying to get settled in, just found the IM-client, woho!)

Exactly.

I think it could be a lot worse. I can’t even imagine the monstrosity that phpBB2 would be, if they had access to shared memory.

Yes, I like SQL. It’s much easier to find data in a database, and it’s much easier to manage concurrency in a database.

It’s much easier to find data in a database, and it’s much easier to manage concurrency in a database.

Its not easier to find data in a database, you have to query it. If it was in memory you could have a reference to it (the type of “data” I’m talking about here is configuration information that is often stored in the DB when using PHP, that is the “junk”). Also if the data is immutable then there are no concurrency issues, but dealing with concurrency when using Java or .NET is a given.

I can’t even imagine the monstrosity that phpBB2 would be, if they had access to shared memory.

It may be worse, I dont’ know. But I don’t think this is a strong line of reasoning, “Feature X can be abused so the language should not allow it”. You should be making the same argument against persistent connections in PHP, they violate the “share nothing” architecture and can be abused. Giving PHP the ability to persist objects by default would kill the platform, but allowing it in the platform as an option would be nice and would give developers more options when their applications have performance problems. Something interesting is that if you look at threads regarding performance problems with PHP they solutions are always hardware related (what does your my.cnf look like? etc etc), then look at what people say when you have the same performance problems in other platforms. The solutions often start with software relates solutions. I interpret this as slowing that PHP’s platform gives developers much less options when it comes to performance problems.

Other then that, session replication isn’t that hard to set up

How do you do it in PHP? I suppose if you were storing sessions in the DB and were already replicating data there it would work. But this solution can really put strain on your DB. So if the sessions on the local computer, how can you have session replcation in PHP? Maybe there is a way, but I don’t know what it is.

total time spend coding the application is alot less then the equivalent java

I really don’t believe this, do you have a study that shows this? Certainly its true if we are talking about 3 page scripts, but for real applications? I think its just something that gets repeated but without justification. I’ve written applications in Java and PHP and certainly you have to write less code with PHP, but Java has absolutely amazing IDEs that save you tons of time when you re refactoring etc. So at least from my experience initial application development may be a bit faster in PHP, but application maintenance is faster in Java due to the IDEs available. In the end its pretty much a toss-up, did you have a different experience?
app.

Remember, processor cycles are cheap - programmers are not.

This argument only holds water if we are talking about an applicatin on a single server. But as soon as your application can’t live on a single server then its going to cost you in developer time (and more so as your application grows).
So having more tools to solve performance problems can save you a lot of money by not having to add application servers.