| Re: calling a value into another php script... [message #182713 is a reply to message #182710] |
Sat, 31 August 2013 00:33   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 8/30/2013 6:19 PM, Christoph Michael Becker wrote:
> 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.
>
Not my posting. Please learn to reply to the appropriate person when
commenting posts.
BTW - I don't think it was meant to be either helpful or funny - but it
is accurate.
>>>> > 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. ;)
>
Which is completely immaterial because that's not the buffering we are
discussing.
>> 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.
>
No, please read again - and understand what Pointed Head claimed. It
has absolutely nothing to do with the ini setting of output_buffering.
>> 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*.
>
Exactly - which is what Pointed Head was proposing.
Please try to understand what is being said before contradicting it.
--
==================
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
]