PHP Optimization

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

gaddimanish
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 3:44 am

PHP Optimization

Post by gaddimanish »

hi

The downloading time of my page is very slow.
I am using various require_once statements in the page
How can I increase the speed of my page.

Please let me know How actually PHP compiler compiles and parse these statements. and how it affects performance

Regards
Manish
User avatar
CoderGoblin
DevNet Resident
Posts: 1425
Joined: Tue Mar 16, 2004 10:03 am
Location: Aachen, Germany

Post by CoderGoblin »

User avatar
m3mn0n
PHP Evangelist
Posts: 3548
Joined: Tue Aug 13, 2002 3:35 pm
Location: Calgary, Canada

Post by m3mn0n »

1. Reduce the number of MySQL statements.
2. Reduce the number of file openings
3. Reduce the number of socket openings
4. Reduce the number of pages being included (and/or the above 3 within problems in those pages)
5. Get Zend Optimizer installed

http://www.zend.com/store/products/zend-optimizer.php
gaddimanish
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 3:44 am

Post by gaddimanish »

thanks for ur valuable help
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

And check it also a couple of times on localhost (to find out you don't have network problems..)
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Speed issues are probably down to the server rather than your scripts. Php is pretty fast.

Why don't you set up a test and let us know the results? Time your script with require_once and then replaced with include/require.

About the only time I ever find a significant slowdown is with mysql. That's not to say mysql is slow - it isn't. As an example, with about a dozen 8 table JOIN queries I'd expect an extra half a second or more on script execution time ie you really have to push the boat out to come up with a slow script.

Of course if you didn't index table columns...

Bottom line is optimising php is usually wasted time. Improve the hardware instead.
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

McGruff wrote:Bottom line is optimising php is usually wasted time. Improve the hardware instead.
Just ran a little test, very unscientific. I took a typical page with four included template files. I reloaded the page six times. Got the following render times:

Code: Select all

0.1359
          0.1450
          0.1015
          0.1134
          0.1267
          0.1074

TOTAL 0.7299
AVG    0.1216
Now I took the included templates and cut and pasted them in place of the includes. Closed down my editor and folder window (don't forget to do that) and reloaded six times. This is what I got:

Code: Select all

0.1176
          0.1068
          0.1025
          0.1016
          0.1010
          0.0992

TOTAL 0.6287
AVG    0.1047
Now just look at those last number you should get the idea optimization isn't a waste of time.

But for those that don't get it, that's a 13.8% increase in performance on one page. Of course I could be wrong, but there's the numbers - check.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Trust me, it is.

Those test results aren't entirely reliable with just six iterations.

Even if you had achieved a speed increase of less than 2 hundredths of a second what impact will that have on your site? How much time did you spend to figure that out, and how much time would you subsequently spend to update all the scripts in the site according to your findings?

And, how easy would it have been to get a faster CPU?

This kind of cheese-paring is a dead end.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

McGruff wrote:Trust me, it is.
I'm having trouble with that.
McGruff wrote:Those test results aren't entirely reliable with just six iterations.
True, and I said they were very unscientific.
McGruff wrote:Even if you had achieved a speed increase of less than 2 hundredths of a second what impact will that have on your site? How much time did you spend to figure that out, and how much time would you subsequently spend to update all the scripts in the site according to your findings?
Here we disagree greatly. You, correct me if I'm wrong, you think of optimization as something you do after all the coding is done. Where as I see as being part of the entire design and development process. Not an after thought.
McGruff wrote:And, how easy would it have been to get a faster CPU?
If that was an option, it would be that easy. However, not all PHP scripts run on server dedicated to them alone. I'll even go out on a limb and say most PHP scripts are running on shared servers. Usually the host will find it easier to suspend your account than "get a faster CPU."
McGruff wrote:This kind of cheese-paring is a dead end.
Call it what you want but I think we're have a very productive discussion. :D
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

As someone who re-coded over 30,000 lines of code in one project, and has begun a new project from scratch that will likely be 1/3rd that size - I'll offer my "real-world" findings.

*generally* speaking, there is a point to optimization. Both of the projects are intended for OTHER people to install on THEIR machines - and by doing so, enable them to do things, and increase the number of 'testers' for a given codebase.

In that scenario, "Upgrade the hardware" literally isnt a choice I have to make - its up to the admins and coders that run the code.

As a professional, I want tight, fast, impressive code - that means taking steps to optimize things.

There are simple steps you can take - use echo instead of print. Its faster. Use less arrays (takes time (and memory) to create and destroy them).

Those are *minor* things. In my new project, with my deep understanding of minor optimization techniques, I'm generally avoiding the slower functions, and embracing tight coding.

However, in my old project, with its huge existing codebase, I did not, and would not, go through and systematically change EVERY instance of slightly slower functions with their faster counter-parts. It just doesn't make much sense to do so. I have better things to do with my time!

There are things I *did* do to optimize the old code however. I reduced un-needed code (the trendy term is 're-factoring'). I eliminated key bottlenecks, and recoded old crufty kludges into elegent classes or functions.

The key slowdown wasn't in the general application - it was almost entirely on the backends like the database, or the business logic.

So - what is the lesson to be learned?

Don't ignore the value of optimizing, but definitely give it a realistic assessment. six benchmarks, taken out of context, for specific pages might or might not be of value.

If your users spend 80% of their time on page3.php, then clearly, thats really the main page you should focus on optimizing. However, if users spend only 10% of their time on page2.php, but it uses 100% of cpu load PER USER, then guess what? Its page2 thats a problem!

It's all about context. Switching print with echo makes sense when you are doing things from the ground up - its a minor change, its easy to do (generally), and it will help reduce the overhead. But retrofitting code to use it? Total insanity.

Context matters. Optimization isnt a waste of time - but poor decision making always is.
gaddimanish
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 3:44 am

Post by gaddimanish »

Following URL

http://phplens.com/lens/php-book/optimi ... ng-php.php

is very helpful.

Can I get any more link related to code optimized issues


Thanks
gaddimanish
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 3:44 am

One more suggestion

Post by gaddimanish »

One more suggestion

I am using one common file function.inc which includes all the functions that I am using in my whole project for better management.
Its already crosses 3000 lines .I m including this file in all pages

I just want to know how much it affects the speed issue.
Should i sepearte it into various files or it is ok to include the same file in all pages.

Thanks
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

gaddimanish wrote: Can I get any more link related to code optimized issues
Optimizing PHP Scripts

Optimizing MySQL: Queries and Indexes

A Few Tips for Speeding Up PHP Code

Optimizing MySQL

MySQL Optimization

MySQL Manual - 7 MySQL Optimization

Optimizing MySQL and PHP (Don't use IE to view this one.)

Optimization should starts before you write a single line of code. Consider your design and figure out where the bottlenecks are in your design. Figure out how to fix those problems then you can start coding.

Bad designs can't be fixed in maintenance cycle.

Just one heretic's opinion.
Last edited by Buddha443556 on Sat Mar 27, 2004 10:12 am, edited 1 time in total.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Buddha443556 wrote:Optimization should starts before you write a single line of code. Consider your design and figure out where the bottlenecks are in your design. Figure out how to fix those problems then you can start coding.

Bad designs can't be fixed in maintenance cycle.

Just one heretic's opinion.
Sorry, I have to contradict you: that is not how it's done. Write, test, THEN optimise. I bet nine times out of ten you won't even need to do the latter. Maybe I take for granted a lot of things I've learned and just do instinctively but it's actually quite hard to write slow code.

I think someone mentioned using print in preference to echo. Given that there are commonly about a dozen vars to echo/print on a page, we'd need an instrument more accurate than the Hubble telescope to detect the difference.

Some other ideas about the development cycle:
http://www.phpbuilder.com/columns/baker ... hp3?page=1
http://www.extremeprogramming.org/.

It's interesting you mentioned bad design since this, I think, is often a product of optimisation obsession.

The main aim of good design is flexible, modular code. Modularisation means OOP. OOP means lots of code that defines layers and structure in an app but doesn't "do" anything. New programmers often see this as inefficient, failing to understand its purpose. So, they write global spaghetti instead (everything mixed up together in the global scope) thinking that's good, efficient code - often without even doing any tests to compare alternatives.

Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored into lean & mean classes by Mr Oop. Both work, and Mr Spaghetti constantly annoys Mr Oop (who has better things to do) with the latest sightings on the edge of reality from his Hubble telescope.

One day the client wants to make a big change to the site. The update is carried out, both sites are still using the "same" underlying code, and both have slowed right down. Mr Oop starts examining the system to find the bottleneck. Within an afternoon, with his nice modular design, he has identified the problem and swapped out the problem code. Mr Spaghetti spends all day just trying to figure out his own script - he's long forgotten how it works and the mess on the page doesn't explain itself. He spends all week looking for bottlenecks: because his script is so tangled, it's a huge effort to compare alternative ideas.

Php isn't a language exactly, more of a vocabulary. To speak eloquently in php, you need to abandon "premature optimisation" and learn the language of design.

At least 2/3 of the effort of programming goes into writing code that is easy to assimilate and easy to work with. The other side of that - making a computer "do stuff" - is a relatively trivial task.
Post Reply