Topic: The end of PHP opcode caching? The end of PHP? (Read 3525 times)

Bonk · « **on:** July 14, 2009, 05:50:27 pm »

Development of ALL PHP opcode caching applications ceased almost exactly one year ago. Zend, as usual, threw some wrenches into the works to complicate the development of opcode caching applications other than their own. Only this time it is much worse than usual, enough to cause development of all opcode caching applications to stop completely. (Mission accomplished?)

Then there is the story of the alternative php cache (APC). It never measured up to eAccelerator or Xcache. It was supposed to be moved to the php core with version six. There has not been a single sign of it in any of the work on 6 so far.

That leaves the Zend Optimiser only. (coincidence? I think not...) The problem is that they will not distribute it outside of an installsheild installer that contains Zend's own spin on how Apache and PHP should be configured. Result: Zend Optimiser is unusable. (and neither 7-zip, i5comp or i6comp can decompress their encrypted installer data - that alone is enough to make me avoid it...)

This could be the end of PHP for major websites. Many sites will go down as they will not be able to afford the additional costs of the much increased cpu load. We'll be OK as we have a small but steady load of users. The site will just get slower.

Ultimately the upshot of this may be that PHP 5.2.x is the last version that will be used on popular websites. When support (security updates) for the 5.2.x branch is dropped, many websites may be forced to go to ASP instead. (Perl would be a step back, no matter what the slashdotters say.)

There is no way the PHP developers do not see this. I think Zend is shooting themselves in the foot here. Forced customers are not happy customers. I, for one, will not be a customer at all.

Watch for ASP ports of phpbb, SMF, Drupal, Wordpress, Joomla and Mambo coming soon.

Sigh, perhaps I'll just reboot to XP, fire up VC6 and start hacking out a version of eAccelerator that will work with php 5.3/6 - my brain already hurts just entertaining the idea...

FPF-Paladin · « **Reply #1 on:** July 14, 2009, 06:02:33 pm »

Bah... Do Not Like

Bonk · « **Reply #2 on:** July 14, 2009, 06:31:07 pm »

Bear in mind I have a conspiratorial mindset and must continually tell myself: "Never ascribe to malice that which can be attributed to incompetence".

It could be incompetence in this case, but it just does not seem like it and it seems too much to be coincidence that APC, XCache and eAccelerator all stopped development in July of 2008.

toasty0 · « **Reply #3 on:** July 15, 2009, 01:42:48 pm »

I believe ASP would be a step back too...but then again, what do I know. I've never been a fan boy of scipting web sites with anything less than rebust javascript.

Long live code behind!!!

_{*exit, stage right!*}

MagicTom · « **Reply #4 on:** July 15, 2009, 02:56:03 pm »

Found this forum by this thread on google ;-)

XCache is in active development for a php 5.3 support build. In fact, there's a pseudo-beta out now, with a few errors being reported that the developer is trying to reproduce so he can address them. All in all, it seems that we're very close to having a compatible cache.

Related XCache forum thread: http://forum.lighttpd.net/topic/99879#new

Things are looking up! As much as Zend can be bashed for the changes that caused this mess, the changes to the language itself are things we've needed for a LONG time. I can't wait to switch.

Sirgod · « **Reply #5 on:** July 16, 2009, 09:34:44 am »

Welcome to the Boards MagicTom and thanks for the heads up.

Stephen

Bonk · « **Reply #6 on:** July 16, 2009, 02:56:23 pm »

Quote from: MagicTom on July 15, 2009, 02:56:03 pm

Found this forum by this thread on google ;-)

XCache is in active development for a php 5.3 support build. In fact, there's a pseudo-beta out now, with a few errors being reported that the developer is trying to reproduce so he can address them. All in all, it seems that we're very close to having a compatible cache.

Related XCache forum thread: http://forum.lighttpd.net/topic/99879#new

Things are looking up! As much as Zend can be bashed for the changes that caused this mess, the changes to the language itself are things we've needed for a LONG time. I can't wait to switch.

#1 - Wow, somebody outside Dynaverse.net actually read one of my rants!

#2 - The situation is not as bad as I thought!

Thanks very much for the information MagicTom. I admit I was going by posted snapshots and did not dig too deep into any of the forums. It looks like XCache is the only one under active development at this point though.

I shall check out a copy and get testing soon! I would not have bothered had you not pointed out that thread. Thanks again and welcome to Dynaverse.net.

Quote from: toasty0 on July 15, 2009, 01:42:48 pm

I believe ASP would be a step back too...but then again, what do I know. I've never been a fan boy of scipting web sites with anything less than rebust javascript.

Long live code behind!!!

_{*exit, stage right!*}

Oh you evil, evil man!

Rule number one: never trust the client.

I have had a strong aversion to javascript since early development of the OP PHP-MySQL webmap. A member I think of as your complimentary color, Lepton, who was using Netscape or something at the time always complained the features with javascript never worked in his browser (or it was disabled altogether); he was not the only one.

This experience strongly reinforced rule number one in me.

Flash ahead (dear Lord has it really been...) nine years, and cross browser compatibility of javascript functionality is still a major issue. (Not forgetting to mention rule number one again). That said, I am currently working on a JSON/AJAX/SVG/VML version of the webmap. The horror, I am violating rule number one... and I used all those buzzword acronyms in one sentence!) but the frameworks available today simplify cross browser issues somewhat (but introduce their own obsolescence or abandonment). I am looking at going this way because of the improved functionality available, but I will still only trust the client to do so much correctly and continue to rely on serverside scripting for the guts of the data, but use the client to do all the presentation calculations.

Upshot - the features available with HTML5 and new javascript interpreters performance look too good to resist. Good enough to make a CIV clone on a hexmap!

It occurred to me yesterday that it would be very interesting to test an early civ clone using hexes instead of squares... but first an updated webmap!

MagicTom · « **Reply #7 on:** July 16, 2009, 05:54:57 pm »

Quote from: Bonk on July 16, 2009, 02:56:23 pm

#1 - Wow, somebody outside Dynaverse.net actually read one of my rants!

#2 - The situation is not as bad as I thought!

Thanks very much for the information MagicTom. I admit I was going by posted snapshots and did not dig too deep into any of the forums. It looks like XCache is the only one under active development at this point though.

I shall check out a copy and get testing soon! I would not have bothered had you not pointed out that thread. Thanks again and welcome to Dynaverse.net.

Thanks! And trust me, I was freaking out too. The whole reason I found your rant is because I was desperately trying to find something other than the not-quite-finished XCache so I could get rolling with my new code

But as long as the issues get resolved with it, I can't complain.

toasty0 · « **Reply #8 on:** July 16, 2009, 09:18:06 pm »

Quote from: Bonk on July 16, 2009, 02:56:23 pm

Oh you evil, evil man!

Rule number one: never trust the client.

*snip of an excellent post.*

I wish I could join you in that development but I just accepted a job that gives me the pompus title of Operations Manager and IT Support for Educational Services that is keeping me *explective* busy. Not really complaining though cause I get to work with all kinds of stuff both Microsoft and non-Microsoft (ie, Cisco, Linux, VMware...). I get to be the company testing chimp for Se7en and Office 2010 to get ready for internal rollout and managed services for our clients. Not sure I like the banana feeder though...too NASA for my taste.

The really exciting part of this new role is I get the opportunity to design the database app for our educational services and the company is paying for me to attend DevConnections. It's been a tough 3 years since I left the Casino business to persue a career in IT/Development (with my first year earnings being less than 30k) but it looks like I have finally arrived at the first station with this position.

For those of you who gave me words of encouragement during the tough times I thank you. For those who expressed the opinion that I couldn't do it (and you know who you are)...I say, Ha Ha!

This IT/Dev stuff is a blast-and-a-half. Wish I had started it earlier in my life.

So much for getting off track here. Here's the microphone back.

Good luck with the map Bonk.

Bonk · « **Reply #9 on:** July 26, 2009, 10:29:02 am »

Chicken Little here... Happy to report the sky is not falling!

I'm currently testing XCache 1.3.0-dev on PHP 5.3 on Canada East and so far it seems fine, SMF has not got upset at me yet. The performance is as good or better than eAccelerator.

I had code in the flatfile webmap to use eAcclerator, I guess I'll need to modify that soon, as once this is released as stable I will most likely move Dynaverse.net to XCache.

Bonk · « **Reply #10 on:** July 27, 2009, 09:23:08 pm »

Further observations (now running XCache 1.3.0-rc1): It seems a little hit and miss, seems like it only hits the cache about 50% of the time. Also, it will not load as a thread safe zend extension. Otherwise seems stable and SMF and the OCI seem to be working fine.

Bonk · « **Reply #11 on:** August 08, 2009, 04:42:13 am »

eAccelerator svn snapshot posted July 14th! Shows work towards php 5.3 (disabling the optimiser as XCache has done). Still will not not compile with VC9, and currently does not compile under VC6 either, but it looks like it's not too far from done.

Bonk · « **Reply #12 on:** August 13, 2009, 05:56:26 am »

That eAccelerator SVN snapshot got promoted to a release candidate. I got it to build under both vc6 and vc9 with a few tweaks, but neither binary will run (Windows, Apache VC9, php vc9 nts).

Bonk · « **Reply #13 on:** August 22, 2009, 11:28:43 am »

Being unsatisfied with XCache's (1.3.0) performance and unable to get eAcclelerator 0.9.6-rc1 to run, I downloaded the Turck MMCache 2.4.6 source and have been working this week on building it against the php 5.3.0 source. I've gotten it down from about 80 compile errors down to five, what's got me stumped now is the changes in garbage collection from php4 to php5.3, but in the process I think I have discovered why eAcclererator will not currently run with php running as a fastcgi...

Both XCache and eAcclererator have dropped the optimiser, content/keys and session caches in their latest revisions in order to acheive php5.3/Zend2.3 compatibility. These were the most difficult sections to update in Truck MMCache source. It appears that the SAPI headers are not used in MMCache unless built with the content cache, I assume the same in eAccelerator. Question is how has XCache done it? (I have not looked for it yet)

I'm hoping ultimately to update MMCache to work with the optimiser and content cache enabled. I have no idea if I will actually get there but I'm at least getting close to getting it to build, and in the process I may learn what is missing from the new eAccelerator and XCache code. The lost functionality appears for the most part related to the late static binding and garbage collection changes introduced with the zend engine 2.3.

Bonk · « **Reply #14 on:** August 22, 2009, 04:04:45 pm »

Oh ho, look who has resumed development:

http://pecl.php.net/package/APC

I will check it out tonight.

Bonk · « **Reply #15 on:** August 23, 2009, 11:12:52 am »

I got Turck MMCache to build but like eAccelerator it will not load. The posted source for APC is thread safe php4 only. I found an APC binary for php 5.3 (vc9,nts) that does run, but it upsets SMF (or the converse). I think my dissatisfaction with XCache is actually SMF.., it seems it only reliably uses the cache for logged in users...

Bigger picture view emerging however - when running php as a non-thread-safe fastcgi (multiprocess), it does not make sense to cache stuff locally to each process, it is redundant and wasteful of cpu and memory.

Memcached. Investigating now.

Bonk · « **Reply #16 on:** August 23, 2009, 04:34:24 pm »

I set Memcached up and gave it a try. It is an object cache only, it or the php apis to it offer no opcode caching functionality. I can see where it would be useful in high load or demanding application situations.

Currently XCache still shows the best result for my setup. Perhaps I can get SMF to use it more effectively.

Bonk · « **Reply #17 on:** August 24, 2009, 01:06:35 am »

Aha, got it! I've got consistent performance out of XCache now whether logged in to SMF or not. The difference was in the hostname lookups settings in SMF. I've got consistently screamingly fast page generation times on canada-east now.

Apache 2.2.13 (apachelounge VC9 build)
php 5.3 non-thread-safe(nts) VC9
XCache 1.3.0 nts VC9

Expect updates to Dynaverse.net soon. Though we'll lose the spell checker for now. (most browsers have it built in now)

Ahhh... my server performance OCD is placated for now. Time to take a look at the database, can I get MySQL to do better?

Bonk · « **Reply #18 on:** August 24, 2009, 05:03:30 pm »

Dynaverse.net is now running XCache 1.3.0! Mooo!

It is appropriate, what with the XC battlecow and all... Thanks mOo!

News: