PHP and OOP and Website Performance

On my current contract, there is a large Medical Management System that seems like it is a real piece of junk. (I’ve only been on board a little over 2 weeks.)

All of the sorry permanent slobs will be working all night because they are having enormous performance issues. (1,000 concurrent web users are bringing their system to a halt?!) :goof:

This got me to thinking…

PHP is supposed to be a “mean, lean, programming machine” and I think that is often framed with using it Procedurally (versus using it with OOP).

And in the past, PHP and MySQL were often labeled as “Not as pretty as J2EE or Oracle, but very good at what they were designed to do, i.e. offer great performance and scalability on the Internet.”

Object-Oriented Programming often is used for “enterprise-level” systems, yet it also seems to have the bad reputation of being “bloated and clunky”.

So my question is…

Can a person built a well-architected system using PHP and OOP and still get very good performance and scalabilty for a large web application?

I mentioned to my project manager that it is embarassing that the legacy system at work is coming to a grinding halt with only 1,000 concurrent users regardless of how “complicated” the healthcare business logic is.

I mean, think of the tens of thousands of concurrent users - if not a lot more - that hit websites like Google, Yahoo, and SitePoint!! :slight_smile:

They are blaming it on hardware and network throughput, but I’d bet anyone here $20 that the application was poorly coded. (Now whether it is also a function of Procedural Code vs. Object-Oriented Code, I can’t say.)

Any thoughts on this?

Are you defeating PHP’s superior web performance by delving into layers and layers of classes/objects by using OOP?

Thanks,

TomTees

BTW, in case you didn’t understand my original post, SituationSoap, I did mention early in this thread…

Fortunately this isn’t my problem. I just overheard half of the floor talking about this yesterday and it got me to thinking.

Regardless, this thread is dead.

Time to move on.

TomTees

No, I just think a lot of people don’t read carefully enough on SitePoint.

A Business Systems Analyst would come to SituationSoap and say, “I’d like you to build an e-commerce site” and he/she would build a toaster because he/she thought that is what the BSA really meant?! :lol:

You say “No”, but I think you really meant “Yes”!! :wink:

TomTees

So how long have you been a mind reader? :rolleyes:

I said I saw something at work, and that…

This got me to thinking…

Can a person built a well-architected system using PHP and OOP and still get very good performance and scalabilty for a large web application?

Read into it all you want, but it was - and still is - a black and white question.

Everyone in this thread has tried to provide reasons why the problem isn’t OOP

And I disagreed with those opinions where???

but you’ve been unable to provide further details.

Why would I provide more details for a system that was not related to my question about PHP??

I have no clue about the legacy system at work, other than a lot of people said it was written poorly in Java/OOP.

The problem is not that we are not answering your question (because it has been answered, by every single person - myself included - who has said “It’s not OOP”) but rather that you’re asking the wrong question.

You’re not answering my question by insisting I provide more details about a system that may have inspired my OP but has nothing to do with my original question.

Asking me about the specs of some system at work does NOT answer my question about PHP and OOP.

Pretty simple.

For those that said OOP isn’t necessarily slower than Procedural, and that said that PHP handles OOP and enterprise-level systems (e.g. Facebook), then thanks for answering my question.

However, telling me what I think or meant is an even bigger waste of time than inquiring about the system at work.

Whatever.

TomTees

Agree… In these hypothetic questions what is hard to take into account is a projects full life cycle.

From a theoretical project that is perfectly nailed down at the start (some mystical unicorn of a perfect waterfall project plan) with no changing requirements ever and a perfect development team then procedural will likely come out performing faster to some degree. The price for that speed improvement which is not easily measurable beforehand without things like useless speed graphs that show the cost of a method call versus a function call is the smaller room to adapt later on. All software decays in quality if actively worked on and the benefit of OOP( being more refactor friendly etc.) has a good chance of being faster in the long run.

A lot of projects fail completely or die early and the real questions now are things like TDD or not TDD, agile or big up front design, effective coding standards etc so we can keep the thing alive, can change effectively and be nice to work in as long as possible.

Procedural as an effective working pattern for large scale application development is pretty dead. It is either we are all fan boys stomping our feet if we have to go procedural or that speed increase was not worth an even higher rate of failure caused by the higher amount of degenerative complication that procedural programming incurred. It might be some degree faster at the start but if it still births it is worthless.

Normally procedural programming is still regarded with high praise near the metal, the rules are hard and they change much more rigidly. It suits a certain type of personality like application design suits a certain type of personality. It is a very hard science (metal) versus a much softer one (human). Kernel writing and application writing require fairly different mindsets; the process that is good for one is unlikely to be good for the other. Someone who is exceptional at one may equally suck at the other.

A lot of us talk what will be perceived by some as crud that has been biased by our own religions and bad magazine articles. You have to live it first hand, build something while honing your instincts and then argue it first hand. I have enough abstracted human friendly implementation cost explaining in my day job :slight_smile:

We may seem like we are ganging up on you but a very good term for a group of developers is an argument of developers.
We leave the cuddling action to the designers :wink:

Except that’s not really your question. Your line of thinking was “Our application is OOP and slow, so therefore the problem must be OOP”. Everyone in this thread has tried to provide reasons why the problem isn’t OOP, but you’ve been unable to provide further details. The problem is not that we are not answering your question (because it has been answered, by every single person - myself included - who has said “It’s not OOP”) but rather that you’re asking the wrong question.

Oops! I misread that! I thought Mastodont said “JavaBeans”! (My “Head First: Design Patterns” books just had a big section on JavaBeans, so that was still in my head!) :lol:

Yes, I gave up on Eclipse last year when I was looking for an easy-to-use IDE with a debugger for PHP development.

I found NetBeans was much easier to use, had tons of great video tutorials, and proper documentation on installing the debugger.

Let’s hope that Oracle doesn’t kill off the NetBeans project like I am 90% sure they will. :frowning:

TomTees

You can safely and comfortable write PHP in NetBeans. It is one of the top PHP editors.

Good to know, but I’d prefer to stay with PHP.

It sounds like most people think PHP is mature and robust enough to handle OOP and a large web application if properly written.

It also sounds like database issues are often a larger concern with websites coming to a grinding halt.

(I can’t comment on what happened at work. Although I suspect it is because the code looks like it was written by a 5 year old!)

TomTees

My original post was about as straight-forward as can be wriiten.

I asked:

So my question is…

Can a person built a well-architected system using PHP and OOP and still get very good performance and scalabilty for a large web application?

I’m not sure why that is so unanswerable??

And why would I answer my own question?? :rolleyes:

(As is a consistent problem on here, maybe you should re-read what was originally posted.)

You seem to have already decided that OO in PHP is unwieldy and slow, and you’re just looking for people to back up that preconceived notion.

I haven’t decided anything. I asked a basic question. And I responded to people’s replies with what I have heard others say.

That said, don’t use Eclipse as a good measure of what Java is capable of, either. Eclipse is slow because of the fact that it’s an application development platform (go look at all the stuff actually built in Eclipse some time, it’s not just the IDE). As a result, it suffers from the Framework syndrome of trying to be everything to everyone, and the code responsiveness has struggled.

I hear Java is great with backend logic and on devices.

TomTees

Just want to add my +1 for NetBeans - it’s simply brilliant

Two issues: the first is that you’re asking an unanswerable question. You’ve given us a question, but you’re unable to provide all the answers, so the best we can do is give you guesses. You seem to have already decided that OO in PHP is unwieldy and slow, and you’re just looking for people to back up that preconceived notion.

That said, don’t use Eclipse as a good measure of what Java is capable of, either. Eclipse is slow because of the fact that it’s an application development platform (go look at all the stuff actually built in Eclipse some time, it’s not just the IDE). As a result, it suffers from the Framework syndrome of trying to be everything to everyone, and the code responsiveness has struggled. If you’re looking for a good example of what Java applications are capable of, go check out NetBeans, which is built by the guys at Oracle (and Sun before them). It’s free, open source and a better IDE than Eclipse (from the ground up, and I’ll stand by that statement).

Writing responsive GUIs in Java is more difficult than most languages, due to the way that events are dispatched to different threads to perform different actions based on user interaction. It’s difficult to effectively spawn the new thread required to do data processing, for instance, while keeping the UI responsive. As a result, novice programmers (and I count myself among them) will often times either do the threading poorly or not at all, leading to a reputation of slow/unresponsive programs. This stereotype has been very difficult to shed.

Don’t forget about HipHop: http://www.facebook.com/note.php?note_id=280583813919

Cheers,
Alex

I’ve been doing this long enough to know that memcaching alone will not get the job done. If the code base is crap memcache won’t always save you.

Facebook = PHP, OOP + Massive use of memcache(d)

We use more than 800 servers supplying over 28 terabytes of memory to our users.
Scaling memcached at Facebook

That sounds impressive, and I don’t doubt your competence, however, I would be willing to bet there are tons of C-developers who would take you to task on that point!!!

Haha I’m sure there would be. Although they have two disadvantages:

  1. They tend to focus on implementation details rather interface, sacraficing code clarity for optimization (ie: http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html). I’m pretty there is a similar article with Linus touting performance and procedural programming.

  2. C developers are accustomed to tweaking code in esoteric ways to squeeze performance out of every line (I did it myself 10+ years ago). You cannot perform the same optimizations in php.

It’s a practically impossible challenge but would be interesitng none-the-less. :slight_smile:

(So does that mean that an OOP-newbie like me should give up before I start on building an OOP e-commerce site?!)

If you give up, you would never learn, so obviously the answer is no. Your understanding of software design is like a software system itself. Constantly changing, improving hopefully, even though sometimes, software gets worse before it gets better. Absolutely build a eCommerce site, share it if you want, I download and play with every application I encounter. I probably have half of sourceforge on my local HDD :stuck_out_tongue:

So poor database design and/or poor database optimizations (e.g. indexing) is MORE of a factor than “bloated” OOP code? (Assuming the OOP code is indeed “bloated”?!)

Personally, I think thats a myth or simply not true with most applications. Yes SQL accounts for some lag, if your tables have 500K records and your SQL SELECT is something like:

SELECT * FROM
(
SELECT * FROM table1, table2, table3 WHERE t1.id = t2.id AND t3.id = t2.id
) AS t4
WHERE first_name LIKE ‘Test%’

  1. Using JOINs (I believe) is faster/optimized compared to relating the tables in the WHERE clause
  2. If first_name is not indexed or the ID’s then performance will really degrade
  3. Obviously the sub-select is not required and extraneous and will probably affect performance.

That being said, most application developers don’t understand SQL well enough to write overly complicated SQL. Most just stick with CRUD-S operations and perform the rest in PHP logic. Complicated business logic (desperate for refactoring) can also account for a lot of clock cycles, IMO.

I just remember one big dig against Java - and thus maybe OOP - is how clunky Java is when used on the front-end GUI. (I’ve actually seen this in real life with things like IDE’s written in Java (e.g. Eclipse) versus IDE’s written in something like C (e.g. _____).

Funny you mention that, I use Eclipse. :stuck_out_tongue:

It is bloated and slow, not just because of OOP but JVM and cross-platform support. You can look at C/C++ editors which compile differently and use the OS native API instead of it’s own. Qt I think compiles to a native binary, resulting in the same benefits of abstraction (cross platform portability anyways) but still run faster because the middle man is cut out at pre-compilation (preprocessing I think), whereas Java stays.

Eclipse is really slow though and buggy in many ways, but it’s extensibility and incredible feature set is like no other IDE I have ever used, so I put up with it. :stuck_out_tongue:

But isn’t it supposed to be optimized for the web and thus faster, or am I confusing that statement with MySQL?!

I think you confusing developer performance with execution performance. PHP is designed for the web, at least the Apache module version. Embedded HTML and PHP is it’s greatest strength and at times weakness. It lets you hammer out dynamic web pages fast, but without care or inexperience can result in one hell of a maintenance nightmare.

PHP 5 seems to have great strides in the OO world, but there are a lot of people that feel Procedural code is more straight-forward, requires less lines of code to do the same thing, and thus offers better performance (even if it may be harder to maintain).

Some languge features prevent you from shooting yourself in the foot in some situations and make your code worse in others. Access control for instance (private, public, protected). Sometimes, very rarely (IMO) methods of a function should just not be exposed to client developers, using private or protected accordingly just makes sense.

In many of these cases, what would be more effective, is a lambda function, but prior to closures, this often resulted in horribly hard to read code, so a private method often did the trick and sometimes results in more re-usability within that class.

Whether code is straight forward or not, again, has less to do with OOP VS Procedural and more the experience and desire of the original author. Some highly experienced programmers just deal with complexity better than others. I hate details, I don’t want to think about the code I’m writing, I want it to read like natural english, so I strive very hard to write code that reads as good as it runs. I avoid comments like the plague, except to make terse callouts of potential odd behavior, side effects, etc. And I scatter my code with TODO: so I can easily grep them out and print them for daily tasks lists.

was just wondering PHP and OOP could be a bottle neck or a place that leads to what is going on at work (in general terms).

Not a bottleneck, unless it’s done poorly (notice I refrained from bad; cause any code that runs and works can’t be bad). Hire a outside OO architect to consult your team if you are not comfortable enough. You write the code, busines logic, etc, the consultant would just steer you in the right direction, perform daily code analysis, make suggestions, then you decide whether you make those changes, based on the repercussions he/she has provided you.

@TomB - sure OOP is slower - but how much? Seconds, minutes, days?

Well, I cannot say with any great conviction, but if I were to hypothesize:

  1. Maintaining a v-table
  2. Deferencing the this pointer

Comparing the function invocation of a function to a method, the difference is microseconds, probably. But if a function takes 0.0005 seconds to invoke and a method takes 0.0010 seconds to invoke, thats twice the performance. The difference is really only a problem, when you take a single core processor and call the two 100K times side by side. Obviously if the function takes 5 seconds, the method should take around 10 to complete. But how many useful programs consist of a single function called 100K times? None that I know of. :slight_smile:

Applicaitons consist of layers upon layers of code, each layer acting as some kind of abstraction or interface to the layer above it (hopefully).

OOP lends itself to solving this better in the grand scheme of things, than procedural.

I guess my opinion, is simply that, if all developers realize the benefit of abstraction (no PHP program i know of communicates directly with the kernel or hardware, at best you’d go through drivers; and probably some higher level API) and accept the importance of abstract interfaces, layers, etc, then why not try an achieve abstract implementations, which is easier to achieve in OO than it is with procedural programming.

If speed is a concern why are you using PHP in the first place

Bingo. Write PHP and use that facebook PHP compiler. :slight_smile:

Cheers,
Alex

I got the odds thing around the wrong way…

Meant to say put 10 pounds down on OOP, earn a fiver if it sucks. Put 99 down on procedural earn a tenner if it does.

I’m not a bookie person.

That is the thing with databases. PHP will rarely cause large file system I/O issues natively ( OS might use swap file etc. ) but databases are pretty happy to write 12GB of temp table per page load if they deem it required. I spend quite a lot of time going through Oracle explain plans and I have seen that sort of stuff a lot. For a public system that requires speed to be competitive in a pretty cash rich market allowing people who can code but don’t understand databases to build the system originally has caused a lot of damage.

With databases, if they are not handled right a performance cost of a 100 times slower is a very easy thing to achieve. You can tell when you are working on amateur code as there is all sorts of cute optimisations in the PHP specific stuff and then when it gets to the database layer it goes completely against good database practices buggering it all up royally

The whole Java thing is also a side step when it comes to performance due to the JVM and abstraction of the GUI if using swing. C++ is an OOP language and has never really been criticized for being slow. (a point that has been said and is well worth reiterating)

You know what, speed won't matter when your application will be an unmentionable spaghetti mess. It might be lighting fast, but every change will require lots of time, manpower and in the end MONEY. 

This talk of harder to maintain can easily be the difference of a pain in a rear OOP system to maintain and an impossible to maintain procedural one that has to be rewritten due to everyone fears to even look at it due to the large scoped dirtiness within. It is a game of odds, 10-5 the OOP will be pants, 99-10 the procedural will be. The sad thing is a lot of code sucks and is more measured by how little it sucks.

On the issue of small simple things and OOP being overkill, small simple things can be a good way to learn it as it teaches small simple relationships with small responsibilities. God objects are pretty common when people switch to it as they believe it is only for the complicated so must be done in a complicated fashion. Simple is the destination, not the start. OOP is there to help simple, not hinder it.

You know what, speed won’t matter when your application will be an unmaintainable spaghetti mess. It might be lighting fast, but every change will require lots of time,manpower and in the end MONEY. A lesser amount of money will buy a server powerful enough to compensate for the “slowness” of OOP. Think about why most people don’t drive Formula 1 cars. It’s not because they don’t want to and they do love speed…

Frameworks are like linux distros - there are no one size fits all solutions. I also haven’t seen any good frameworks. Zend is bloated at best, Joomla’s internal is rather specialize, and Cake seems bent on transforming PHP into Ruby. We weren’t debating frameworks though, but OOP v. Procedural.

And honestly, Procedural is faster only on small projects. Anything of significant size will quickly outscope it as it becomes more and more difficult to maintain the code.

If speed is a concern why are you using PHP in the first place? And procedural doesn’t have a speed advantage against OO in C++ since the compiler is smart enough to pare things down to the minimum most of the time.

At the end of the day, it’s all a heap of gotos when you hit the assembly level. BUT – getting there without OO is going to take a lot longer.