Why use output buffering in PHP?

前端 未结 11 1011
礼貌的吻别
礼貌的吻别 2020-12-09 02:43

I have read quite a bit of material on Internet where different authors suggest using output buffering. The funny thing is that most authors argument for its use only becaus

相关标签:
11条回答
  • 2020-12-09 02:54

    We used to use it back in the day for pages with enormously long tables filled with data from a database. You'd flush the buffer every x rows so the user knew the page was actually working. Then someone heard about usability and pages like that got paging and search.

    0 讨论(0)
  • 2020-12-09 02:57

    Ok, here is the real reason : the output is not started until everything is done. Imagine an app which opens an SQL connection and doesn't close it before starting the output. What happens is your script gets a connection, starts outputting, waits for the client to get all it needs then, at the end, closes the connection. Woot, a 2s connection where a 0.3s one would be enough.

    Now, if you buffer, your script connects, puts everything in a buffer, disconnects automatically at the end, then starts sending your generated content to the client.

    0 讨论(0)
  • 2020-12-09 02:58

    It's useful if you're trying to display a progress bar during a page that takes some time to process. Since PHP code isn't multi-threaded, you can't do this if the processing is hung up doing 1 function.

    0 讨论(0)
  • 2020-12-09 03:02

    If you want to output a report to the screen but also send it through email, output buffering lets you not have to repeat the processing to output your report twice.

    0 讨论(0)
  • 2020-12-09 03:03

    Yes

    Serious web applications need output buffering in one specific situation:

    Your application wants control over what is output by some 3rd-party code, but there is no API to control what that code emits.

    In that scenario, you can call ob_start() just before handing control to that code, mess around with what is written (ideally with the callback, or by examining the buffer contents if you must), and then calling ob_flush().

    Ultimately, PHPs' ob_functions are a mechanism for capturing what some other bit of code does into a buffer you can mess with.

    If you don't need to inspect or modify what is written to the buffer, there is nothing gained by using ob_start().

    Quite likely, your 'serious application' is in fact a framework of some kind.


    You already have output buffering, anyway

    You don't need ob_start() in order to make use of output buffering. Your web-server already does buffer your output.

    Using ob_start() does not get you better output buffering - it could in fact increase your application's memory usage and latency by 'hoarding' data which the web-server would otherwise have sent to the client already.


    Maybe ob_start() ...

    ... for convenience when flushing

    In some cases, you may want control over when the web-server flushes its buffer, based on some criteria which your application knows best. Most of the time, you know that you just finished writing a logical 'unit' which the client can make use of, and you're telling the web-server to flush now and not wait for the output buffer to fill up. To do this, it is simply necessary to emit your output as normal, and punctuate it with flush().

    More rarely, you will want to withhold data from the web-server until you have enough data to send. No point interrupting the client with half of the news, especially if the rest of the news will take some time to become available. A simple ob_start later concluded by an ob_end_flush() may indeed be the simplest and appropriate thing to do.

    ... if you have responsibility for certain headers

    If your application is taking responsibility for calculating headers which can only be determined after the full response is available, then it may be acceptable.

    However, even here, if you can't do any better than deriving the header by inspecting the complete output buffer, you might as well let the web-server do it (if it will). The web-server's code, is written, tested, and compiled - you are unlikely to improve on it.

    For example, it would only be useful to set the Content-Length header if your application knows the length of the response body after before it computes the response body.


    No panacea for bad practices

    You should not ob_start() to avoid the disciplines of:

    • opening, using and quickly closing resources such as memory, threads and database connections
    • emitting headers first, and the body second
    • doing all the calculations and error handling you can, before beginning the response

    If you do these, they will cause technical debt which will make you cry one day.

    0 讨论(0)
  • 2020-12-09 03:06

    i use output buffering for one reason ... it allows me to send a "location" header after i've begun processing the request.

    0 讨论(0)
提交回复
热议问题