Moving "Memory Limit" to Config.php

[Dmitry A.]

Hi guys,

I strongly believe that we should move Memory Limit setting out to config.php so it can changed on per project basis.

It should be easy to do makes more sense. Default value can be 50M, but I came across the case when need to ramp it up to 128M (of course server config should allow it)

DA

[Alexander Obuhovich]

I agree.

Of course in some cases fact, that project eats above 50MB memory may indicate poor coding, that can be optimized to be more memory efficient. But yes, in some cases where nothing else can be done only thing is to increase memory limit.

Also maybe increasing memory limit on some pages only would be a better solution.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

I thought of your idea/suggestion for ability to increase the Memory Limit on some selected pages.

To be honest - I see no reason why we need to check and limit it on some pages if limit needs to be increased anyway. Basically I look at as:

a. I don't need to change Memory Limit - everything is working great!

b. I do need to increase my Memory Limit since some of the pages really require it.

As you can see it's one or another so additional check and management where Limits Should apply or not might overkill unless we do a New Tag which usually will be placed by developed in the Top (or anywhere) of the template to set a NEW value.

Then I guess we need to do both - config.php setting (so it's website wide) + New Tag so you can overwrite this on Page/Section level if needed.

What do you think?

DA 

[Phil]

From my own experience, when memory limit exhaust, it's mainly because of too many languages make main menu build too big, and thus it's happen on all pages... I don't see point for creating a new tag, which would let coder, as Alex said, hiding his crappy code and continue without worrying about it.

Envoyé avec Sparrow

[Alexander Obuhovich]

Interesting. Dmitry, why you needed to increase memory?

Right now we increment memory limit when generating XML documents, since they can be large and without increasing memory we can't store them before dumping to file. And all code is ok.

Then no need for memory change any longer?

[Phil]

may overriding default memory limit when using XML tag would be enough?

Envoyé avec Sparrow

[Alexander Obuhovich]

That's what I'm telling. In all In-Portal projects I've done I seen none of them, that needs to have 50MB memory limit increased for all pages.

[Dmitry A.]

Guys,

We are not trying to cover up anyone's bad code. For the same reason PHP has such functionality when you can change the Memory Limit from the PHP on any page (if server config allows). I see nothing wrong with having such functionality. If programmer what's to cover up his bad code but extending the link - they can do so anyway (we can't stop them), but it would be more convenient to have this when you can:

1. set your own limit globally in config.php

2. set page specific limit via In-Portal Tag

DA

[Phil]

I'm for 1. and 2. could be used for special pages such as XML... Alex what's your opinion?

Envoyé avec Sparrow

[Alexander Obuhovich]

What I'm saying is that we don't need that flexibility of memory changing at all.

As I've told before there is no need to do a site-wide memory limit change since local memory increase (where calculations, that are requesting this happens) is more then enough.

Dmitry, could provide real-life example where increasing memory limit site-wide is the only option?

[Dmitry A.]

No, I can't from top of my head, but I think we can have this option possible if needed because there might come such situation.

Note that PHP is NOT eating up that memory right away, but on demand.

Here is how Drupal is dealing with this setting:

in settings.php

If Drupal is already installed, you can edit sites/default/settings.php. This method will affect only the site using this file.

Locate the PHP settings section and add the following line at the end of that section:

ini_set('memory_limit', '64M');

I am proposing:

1. Default value in startup.php stays 50M

2. If there is setting in config.php (ie. called MemoryLimit) specific - it's value will be used in startup.php instead of default one. This will allow to adjust (not just increase) memory limit without committing the code, plus on per sever basis (if website is running off multiple Web servers)

3. Add new Tag which will allow to set this value on per Page/template basis

Keep in mind that we are not just talking about Increasing Memory Limit - these options are for controlling it so it can be changed UP or DOWN!

I have this makes more sense.

DA

[Dmitry A.]

Hi Alex,

Yesterday I came across situation when we have ~3-4K of categories in the project (eGov) and I wanted to use CachedMenu instead of Categories PrintList for the main list of categories (on the left). I was out of memory on Menu Rebuild (50MB is not enough there) and there is no point of putting page specific Memory Limit since left menu is included everywhere.

Yes, CacheRebuild happens rarely, but still I need to include limits and global increase looks like the only option here. I feel like we still might benefit from both options even I have no intention to abuse this for no need.

DA

[Alexander Obuhovich]

Menu problem is interesting one.

We actually store ALL 4K categories in cache (and not only these 20, which are usually in menu) to solve problem when you call st_CachedMenu tag with category_id parameter, which isn't in menu, but all it's child categories are.

That's why we cache ALL categories and then only display ones, that have IsMenu mark.

There might be more elegant solution, like this:

1. get all categories, that have IsMenu (usually no much)
2. get ParentPath of all categories, that were selected on previous set
3. create multi-dimensional array where we'll have all IsMenu categories to be displayed grouped by their parent categories
4. some categories will only have 1 child category because one of it's children have IsMenu categories, but category on it's own isn't displayed in menu.

Sounds pretty interesting optimization. Would speed up menu cache building (if you have many categories) very much.

[Alexander Obuhovich]

I've created a separate https://groups.google.com/d/topic/in-portal-bugs/03AJylZfXa8/discussion discussion for it since it's not directly related to memory problem.

If we see some places in In-Portal that eats a lot of memory when lots of data come into database then increasing memory limit is last thing that we can do. We should optimize first.

I know that if we increase memory we solve a problem and since it's only on 1 project and is working now, then nobody would come back later and fix it in In-Portal for all projects.

[Dmitry A.]

Agreed to wait on this and possibly comeback on the future (if needed)

DA