Re: Re: optimizing PHP for microseconds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bastien Helders wrote:
> I have a question as a relatively novice PHP developper.
> 
> Let's say you have this Intranet web application, that deals with the
> generation of file bundles that could become quite large (let say in the 800
> MB) after some kind of selection process. It should be available to many
> users on this Intranet, but shouldn't require any installation. Would it be
> a case where optimizing for microseconds would be recommended? Or would PHP
> not be the language of choice?
> 
> I'm not asking to prove that there could be corner case where it could be
> useful, but I am genuinely interested as I am in the development of such a
> project, and increasing the performance of this web application is one of my
> goal.

Hi Bastien,

A good question, and a good use-case.

Firstly, to clarify (generally speaking), "optimising for microseconds"
is a real thing, but not how it's been conveyed previously. There is a
big difference between knowing your language / target of choice (e.g.
creating fast code); and the real "optimising for microseconds" which is
shaving off every microsecond possible once all other routes of
optimisation have been taken (and where it is needed).

There is always a case for creating code that executes quickly, that is
a big part of our job - but worrying about microseconds and completely
disregarding forms of optimisation in the full tech stack that shave of
hours of runtime per day isn't the best course of action :)

On to your specific use-case. It's all relative and without all the
details I can't really give an accurate opinion!

PHP can easily be leveraged to use the file system in order to create
the bundle too, move files over to a temp directory; tar/gzip everything
up and then redirect the user to (or store) the location of said file.
Taking an approach like this will considerably lower the amount of
resources consumed by php / web server and thus keep the system speedy
for all (and is more than likely quicker). And obviously all future hits
to said bundle won't need to touch php.

If you don't want to keep the user waiting then you could save the
instructions needed and have a cron job or daemon pick up on them and
then notify the user(s) when the file has been created.

Many, many approaches - generally speaking this is the best advice I can
give:

1: always look for the tech that has been designed to do the job you
need, and then use it - if possible.

2: test, time & measure. Try different ways of dealing with the
"heaviest" bit, get the numbers and take a note of what processes it
impacts - then compare.

For example if 3 users run the script at the same time with PHP doing
the heavy lifting, will it max out the processor or push the web server
in to using swap memory? If something fails (a known / handled
exception) then does the process take a double hit and need run a second
time?

You are your own best friend with this one, take time out, negate php
for a moment and just think of the fastest way to do what you need (all
things considered) then go try it out - PHP can still be the controller
for any factored out processes :)

Do hope that helps,

Nathan

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux