| Re: calling a value into another php script... [message #182717 is a reply to message #182713] |
Sat, 31 August 2013 00:57   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 8/30/2013 8:33 PM, Jerry Stuckle wrote:
> 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.
>
My apologies - I read back through this thread and realized you don't
have the background of the previous discussions Pointed Head is talking
about.
He has propounded that buffering in the script (generally using the
ob_xxx() calls) is more efficient than outputting the data directly.
It has nothing to do with the PHP buffering, which I agree is handled
well (like I said in my first response to him).
--
==================
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
]