General Question

Vincentt's avatar

Is it unwise to raise PHP's memory limit?

Asked by Vincentt (8074points) June 19th, 2008

A website I’m currently working on is quite heavy which resulted in a memory allocation error. Now, this can be solved by raising the “memory_limit” in PHP’s settings so enough memory is available, but is this a wise thing to do? I don’t really have many ideas on how to improve the performance of my scripts so I don’t know what else to do, but raising the limit doesn’t sound very wise to me.

Observing members: 0 Composing members: 0

7 Answers

paulc's avatar

Without knowing what you’re doing its hard to get specific. What I can say is that raising the memory isn’t necessarily bad but it should be your final option. I think the best general tactic to use here might be to do deferred processing.

Its possible that in your process you are managing multiple hunks of data while you process them into different structures (just an example). In this case, you could try to break the process into smaller parts that run not simultaneously but in order. So, for example, reformatting the data from one source to be compatible with your format could be done in one process, saved to disk (or whatever) and then freeing up the memory from it. Then the next step, etc.

I started writing an example but its really long-winded and had something to do with dinosaurs. Let me know if I need to explain more.

robmandu's avatar

There’s nothing magically good/bad about memsize limits for apps. You can raise PHP’s if you need to. The limit exists to help prevent some poorly written PHP process from starving other apps of the RAM they need.

Assuming your system has plenty of available RAM to accommodate the increase (and with RAM being cheap and copious on most systems these days, it should be), then I expect your system will be just fine.

@paulc’s recommendation, to work on more efficient/scalable processing is always good advice, too.

Vincentt's avatar

@paulc – yep, I am processing multiple chunks of data. So what you mean is loading, say, an RSS feed, have it added to the HTML and then unsetting the variable that holds the class that holds the RSS feed?

@robmandu – thanks, that’s comforting.

chaosrob's avatar

You’re fine raising it as long as you actually have the RAM. If the app is going to be spinning up hundreds and thousands of sessions, memory management can get to be a problem quickly. Best if you actually have lots of physical memory and a nice, big swap partition.

Vincentt's avatar

Thanks chaosrob. If that’s the case I’ll surely try to see how much I can save because I’ve no idea what kind of servers it will be running on and obviously I want to support as many as possible.

timothykinney's avatar

Without knowing much about your specific application, I would say that you should look very carefully at your code before just throwing more hardware resources at the problem. Everytime I have ever come up against a hardware wall, it forced me to think about how I was solving the problem in new ways. Usually, this resulted in better code which I never would have written if I had just added more resources.

If you’re talking about a web-app, adding more resources is a limited solution, at best. For true scalability, you need to look at why you need so much memory and address the root of the problem. Web-app user bases grow much faster than your estimate usually will, so be prepared for fast changes in performance.

Vincentt's avatar

Yeah, depending on how a page is set up, basically, it’s juggling around various RSS feeds, images from different sources, and more. I think I already know how to improve it: currently I’m caching the RSS objects and the like, while I want to move to caching the resulting HTML. Just haven’t gotten around to it yet.

Answer this question

Login

or

Join

to answer.

This question is in the General Section. Responses must be helpful and on-topic.

Your answer will be saved while you login or join.

Have a question? Ask Fluther!

What do you know more about?
or
Knowledge Networking @ Fluther