| Re: calling a value into another php script... [message #182705 is a reply to message #182704] |
Fri, 30 August 2013 15:42   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 8/30/2013 10:30 AM, Denis McMahon wrote:
> On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:
>
>> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:
>
>>> Like actually recommending to *disable* output buffering on a
>>> production site, when having output buffering *enabled* is *the*
>>> *proven*, simple measure to make a PHP-powered site faster, thus more
>>> user-friendly.
>
> The only benefit I've ever seen from PHP output buffering is it allows
> you to output a page and then change the headers at the end if for some
> reason you have a need to ... as long as the buffer was big enough to
> hold the whole page, otherwise you're fucked anyway, which is probably
> why sensible coders always make sure they send all the headers *before*
> sending the output.
>
I've also used it when calling code which outputs directly, so I can
parse that output. For instance, if you want to know the current
configuration, you can buffer the output of phpinfo(INFO_CONFIGURATION),
then parse it. It's easier to do than to figure out all of the
configuration parameters yourself. Of course, if you only want one or
two, then just using ini_get() would be easier.
But you're right - it's always best to just send the correct headers
first, then output your data.
> Anyway, as you say, the browser is probably buffering the page,
> especially if it's using compression, so all that buffering in php will
> do is increase the memory footprint of the process.
>
Yes, the browser buffers the output - but PHP also buffers the output
before sending it to the web server for efficiency. Buffering it
yourself has no gain. And the web server will buffer the output so it
can break it into the appropriate sized packets. Buffering it yourself
just adds an extra layer of overhead - the PHP buffer size doesn't
change, so you will end up with the same number of buffer fills and
sends to the server, and the packet size doesn't change so the same
number of packets will be sent.
> This may in some cases mean that the output is "buffered" in the script,
> by which I mean you build the output as a variable, or possibly a
> collection of variables and an:
>
> echo <<< EOT
>
> ......
>
> EOT;
>
> where you insert those variables into the output, but IME it is better to
> make sure that you get the whole headers before data thing right, rather
> than rely on buffering and the "I wonder if tweaking this parameter will
> reduce my memory footprint" whims of a future site administrator to do it
> for you.
>
> Especially as the future site admin is probably going to be a new hire
> they recruited in a panic when the old unix admin retired, is probably
> fresh out of college, and has no idea about real world IT.
>
Exactly.
Buffering it yourself is OK when you get 100 hits/day. But try a site
that peaks at > 1K hits/second and you'll definitely see a difference
(and not for the better!).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]