| Re: calling a value into another php script... [message #182710 is a reply to message #182705] |
Fri, 30 August 2013 22:19   |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma:
|
Senior Member |
|
|
Jerry Stuckle wrote:
> 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:
^^^^ IMO that's
neither helpful nor funny.
>>>> 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.
What the browser does is completely unrelated to the issue at
hand--we're talking about the server side.
Setting output_buffering=4096 will indeed increase the memory footprint
of the process--by 4 KByte! That seems to be an awful lot these days. ;)
> Yes, the browser buffers the output - but PHP also buffers the output
> before sending it to the web server for efficiency.
That depends on the ini setting of output_buffering--exactly what's the
issue at hand.
> 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.
What you're talking about here seems to be the usage of the ob_*() set
of functions. Indeed, using these might not be the best idea, *generally*.
--
Christoph M. Becker
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]