What's happened to Split mode?
Jaro Larnos - March 6, 2008 - 15:00
Split mode is what worked for me in the 4.7 branch, where I could work on 8MB PHP memory limit quite nicely using modules like CCK, taxonomy, og, and views without the memory being of any kind of issue. Now when I'm hopelessly trying to upgrade to 5.x, I'm constantly been hit with the white screen of death, although the PHP limit has been raised to 16MB.
So what I would like to know is can I use something like split mode patch on the 5.x (and possibly in future in the 6.x/7.x when we get there). I guess it doesn't work straight 'from the box'.
I'd appreciate any info on how to make this work.
What 4.7 version and what
What 4.7 version and what version of the splitmode patch are you using?
Hiveminds Magazine | FireOrb | Drupal Street | Drupal offline manual
Try a better host ...?
As far as I know there is nothing quite like this for 5.x or 6.x but maybe Hiveminds can correct me on that. In 6.x some memory footprint reduction is achieved by "manual" splitting of module files, however this appears to be more than compensated for by the general increase in codebase size (and functionality of course).
gpk
----
www.alexoria.co.uk
I'd do that..
...if it only was up to me to decide. I'm actually more or less a volunteer worker on a non-profit organization that's very much stuck in bureaucracy. I was the one to hook them up with this service provider in the first place so I am hoping the provider to meet us in the middle, which might or might not happen. I feel I'm being left out of options, although if things get tough I might be able to reroute the traffic to my own dedicated server which would be able to handle the web load, but I couldn't offer them any email services if I did so.
I don't really know what to do, actually. I'll check out the modules on 6.1 if they match mine though. Hopefully it isn't too big a beast.
The split mode type
The split mode type functionality did not make it into Drupal 5 unfortunately. Which makes Drupal 5 more resource intensive than Drupal 4.7. The good news is that a variation on the splitmode patch did make it into Drupal 6. But as mentioned Drupal 6 is bigger and so getting down to 8mb is not a reality.
So you might have to think about taking the complete cycle to Drupal 6 or waiting until you can do so. Not everything is ready for Drupal 6 in the way of contrib modules.
Hiveminds Magazine | FireOrb | Drupal Street | Drupal offline manual
If I was to try Drupal 6
What would I need to know in order to use the split mode type functionality on it?
And I have 16MB for php now. Here's the list of modules I used on 4.7 (and what I'm trying to use in 5.x as a replacement):
(antiproxyhack)
autologout
bad-behavior (/ http:BL)
bbcode
bloginfo
cck
commentcloser
comment_mover
event
flatforum (-)
graphstat
gsitemap (xmlsitemap)
image
img_assist
insert_view
jstools
locales (finnish localization)
og
poormanscron
print
privatemsg
quote
scheduler
search_config
search404
securepages
signature (signature_forum)
smileys
spam
tinymce
views
webform
workspace
xstatistics
I could drop some of these, probably the statistics modules and the scheduler, but most of the stuff I have are in heavy use. We have usergroups, forums, taxonomies, cck and views (courses, meetings, calendar), all in heavy use so I guess it'd be kind of counterproductive to strip the site to bare minimum after it's worked so well before. I'm going to take a look at the different modules Drupal 6 has, if it is possible to make the transition to it straight away. I might even consider the possibility to further slim down the choices. Hopefully it doesn't impact the usability too much though.
I'm just wondering if 16MB is feasible for the project.
major bummer
It seems Organic Groups, Views and CCK are still not done on D6. :(
I'm starting to panic. Maybe I should roll back to 4.7.11 or try to somehow convince our hosting provider to cut us some slack.
That looks quite a lot for
That looks quite a lot for 16MB even if you cut back a bit. Even on 6.x, as and when Views etc. are finished.
Note it's not possible to downgrade a database ...
Suggest you see if you can get some extra PHP RAM allocation from your provider. Maybe suggest you will have to move otherwise and many other providers offer a much more generous allocation (e.g. it essentially seems to be unlimited at our host).
Just by way of comparison, I have a 5.x site on which devel.module reports memory consumption at devel_init() to be 7.63MB (this is mainly bootstrap plus those modules that implement hook_init(), which in my case is I think just devel, globalredirect, logintoboggan, and path_redirect). At devel_shutdown() mem usage is 8.8MB ... active modules are only color, help, menu, path, profile, search, statistics, taxonomy, tracker, upload, devel, devel node access, 3 custom modules (about 80KM PHP source), global redirect, google analytics, logintoboggan, meta tags, path redirect, TAC_lite, TinyMCE, webform, Views and Views UI, plus the 6 required core modules.
Mem usage rises to 9.8MB on the main admin page, or 10MB on admin/by-task.
There is a module or script or patch somewhere that lets you see what each module is using - could be useful if you want to set things up on your own server to work out where savings can be made.
gpk
----
www.alexoria.co.uk
huh, could you believe this?
The provider moved the site recently to a new server with 64 MB of max PHP memory, but now the pages simply crash their new server.
They told me the site consumes literally gigabytes of memory. I wonder. How can it be possible when the previous server didn't crash and neither does my very own server I tested the "broken" site on. I downloaded the exact copy that was causing problems for them including the database and tried it on my own hosted server and it didn't crash down in flames like theirs apparently did. The previous server the site was hosted on only gave a white screen of death, it never crashed on me.
This is weird.
Well yes, Drupal doesn't
Well yes, Drupal doesn't usually crash the servers it runs on - sounds like a major server config. problem. But if Apache/PHP/Zend are wrongly set up or buggy versions then you can get them to crash. I suggest you use devel.module to check out memory used by PHP when running Drupal. Note that activating collection of DB query info. (which you should not need anyway) via devel.module *can* cause Apache to segfault - this is a known problem with some versions of Zend Optimizer (an encryption facility I believe, nothing to do with PHP code caches or whatever), and you have to manually modify a static Drupal variable to fix the problem if it arises.
gpk
----
www.alexoria.co.uk
Well, one of the things I am
Well, one of the things I am working on with FireOrb is to get cross-compatibility with D5 and 56 modules. I am creating a kind of backporting system that allows the core to remain the same but accomodate changes in the modules themselves. This is because many like myself will be stuck with Drupal 4.7 for the forseeable future but need some of the newer module functionality to create new sites.
In an interesting conversation with the company owner yesterday the decision was made to stick with 4.7 no matter the consequences. This creates a problem for me becasue like yourself I would like to move on to D6 so that my Drupal skills don't become stale because I am looking for a new job from this point on.
I am going to take a look at the splitmode patches and see if it will work on Drupal 4.7.11 which is what FireOrb is based on. If you are using any other patches or modules that have increased 4.7 performance then let me know and I will try and get them in. I expect to have an alpha of FireOrb released by the end of March.
Hiveminds Magazine | FireOrb | Drupal Street | Drupal offline manual