Most of my PHP apps have an ob_start at the beginning, runs through all the code, and then outputs the content, sometimes with some modifications, after everything is done.
ob_start() //Business Logic, etc header->output(); echo apply_post_filter(ob_get_clean()); footer->output();
This ensures that PHP errors get displayed within the content part of the website, and that errors don’t interfere with header and session_* calls.
My only problem is that with some large pages PHP runs out of memory. How do I stop this from happening?
Some ideas:
- Write all of the buffered content to a temporary file and output that.
- When the buffers reaches a certain size, output it. Although this might interfere with the post filter.
- Raise the memory limit (thanx @troelskn).
Whats the drawbacks on each of these approaches? Especially raising the memory limit?
Can’t you raise the memory limit? Sounds like the best solution to me.
Edit: Obviously, raising the memory limit just because a script tops out should raise some red flags, but it sounds to me like this is a legitimate case – eg. the script is actually producing rather large chunks of output. As such, you have to store the output somewhere, and memory seems to be the best pick, for both performance and convenience reasons.
I should note also that the memory limit setting is just that – a limit. Scripts that don’t consume much memory, won’t consume more just because you raise the limit. The main reason for its existence, is to prevent misbehaving/buggy scripts from taking down the entire server. This is something that is important if you have a lot of amateurs hacking away on a shared host (Something PHP has been used a lot for). So if this is your own server, or at least you generally know what you’re doing, there isn’t really any benefit from having a low memory-limit.