Posted by freejoe76 on December 12, 2007 at 9:19pm
Hi all,
I was wondering what the experience out there has been with drupal's memory consumption -- has it been an issue with your project?
Also, I'm curious if there were there other "gotchas" during your Drupal app development.
Our team here is working on a smallish city guide-type application (which will have a good amount of detail on the business listings), and we're forked on the soon-to-be-age-old question: Drupal or Django? I'm working on learning as much as possible before our raft takes to the river.
-Joe
Senior Developer
The Denver Post
Comments
Memory consumption: no more
Memory consumption: no more than any other program with the same complexity.
The "gotchas" are the same as with any other open source program: what are your strategies for change management -- local development methodologies and connecting that with upstream code evolution.
Drupal vs. Django: well, Django (or Rails) you build everything from scratch from the ground up. With Drupal, you have both a framework, as well as many initial building blocks (aka modules) to start from and customize as needed.
You will get an initial site prototype up that is actually functional much, much quicker in Drupal (like, 2 weeks). But, total amount of time for smoothing the edges and building custom functionality will likely be about the same. The nice thing about the prototype stage is that it's easy to start seeing where you want to put time and effort and/or try different things.
Hi Boris, Everything you
Hi Boris,
Everything you write makes sense -- I'm also curious about the development "brick walls" and "time holes" the people here have run into. We all have them -- it's the stuff that you just can't get to work, hit your head against it for an hour or two, and then "oh yeah!" break on through ... or not.
Joe Murphy
Senior Developer
The Denver Post
Scoping and module selection
Well, the big thing is wasting time using a contrib module that is perhaps not "as advertised". You should always be doing CVS checkouts -- making it easy to move to different versions of that module -- and you need to track what's happening upstream with the modules you choose to use.
So, you need to do good Gap/Fit initially, choose which modules to re-use and extend/improve, which are going to be custom internal, and which might be custom contributed. Then start describing your requirements and extra feature needs -- ideally as actually issues on drupal.org and/or posts here on g.d.o. Other people are likely to have similar needs or point you to some existing modules that can get you going.
When hitting a brick wall, pinging a local user dev group or some wider community can be invaluable.
Like I said, defining your process for how you're going to interact with the community "upstream" is a place that can suck up a lot of time...but if done right can yield big benefits (and we all get a more robust platform).
Stumbling blocks
Boris is spot on about change management. Keeping up with the Drupal crowd can wear you out! If you're used to commercial software that gets revved once every 16 months, you'll be shocked. But the change generally is a very good thing, with a steady stream of improvements, both in core and contrib.
Biggest stumbling blocks for us, so far, have been:
Failure on our part to grok the Drupal Way before we hack. Some of our early stuff is going to be hard to upgrade as a result.
Profile page theming. OMG. This is at least partially addressed in D6, I think, although I do not yet have my head wrapped around it.
CVS. You can waste more time trying to figure out the tagging system than you did writing the initial version of the module. I wish more newspaper folks would run into this problem ... so far we have hundreds of newspaper companies using Drupal, but hardly any module contributions. (Morris Communications/Ken Rickard is the exception.)
A huge item on the plus side: If you can think of it, and probably if you have not yet thought of it, there's a contrib module. Joe, since you're working on a city guide you should put the Location, Pathauto and Meta Tags modules into your bag of tricks. We're working with Mike Blinder on business profiles and we've been able to nail SEO pretty well. If/when microformats become important, we're all set.
new year resolution
Hi Steve,
You very right about this. It takes an extra effort to abstract our solutions enough to make them work outside our environment, but that's no excuse. So we've made our new years resolution to release at least 3 useful modules within the next 6 months.
thanks
It would be appreciated by a lot, I'm sure.
Starting a news outlet with $0 resources, though, takes a lot out of a man.
If I ever have any 'real' developers, I hope to release back to the community as well.
K. Paul Mallasch - Publisher
kpaul media
mySQL Tuning
You may find problems with the server responsiveness if you don't tune the mySQL server. We have two very busy installs of Drupal running on a single server, and if it gets really busy on one site, man does it get slow. There are the caching and throttle tricks in Drupal, but it is best to also add some server tricks to your bag. Among them: replacing .htaccess with httpd.conf configurations, learning the caching thing on mySQL, and doing everything you can on the apache side rather than using the workarounds on the drupal side (301 redirects in apache is better than making Drupal do it).
And have a plan for what you are going to do when some communist scumbag tries to spam your comments with a spambot from a domain ending in *.cn or *.ru.
Start here to learn a few of these tricks: http://drupal.org/node/2601