Posts tagged "Drupal"

Drupal Edu Initiative launched

I mentioned awhile back that one of my coworkers and I were considering putting together a simple resource site for Drupal users in educational contexts; today, http://drupaledu.org is live (many thanks to Acquia for providing the hosting)!

The initiative was born out of discussions at DrupalCamp Austin last fall; many of the folks we spoke with there were frustrated at how infrequently universities share information with one another on web issues. Since we at UNT CWS believe Drupal is a very useful tool in solving a lot of the typical web problems educational institutions face, we figured this kind of site would help tear down the silos and improve things for everyone.

At the moment, the site is very simple—authenticated users can post links to relevant outside sites, participate in forums, and vote on the usefulness of other user-contributed content. We hope the community will really get involved in this; the more people contribute content, the more useful the initiative becomes.

If this sounds interesting to you, please take a moment to check out http://drupaledu.org. And of course, if you have some Drupal-in-education-related content to share, please do; the more the merrier!

DrupalCamp video posted

Last November my coworker Adrian Rollett and I got the opportunity to present a talk at DrupalCamp Austin; I've blogged about the content previously, but now that the video is up, I thought I'd post it here as well.

Read more...

Know thy bottlenecks

One of my projects at work lately has been a searchable index of about 80,000 images, each involving about 20 fields' worth of metadata. It's a Drupal project, so it was pretty easy to set up the appropriate content types, fields, and so forth, but when it came time to set up searching, I made a few regrettable assumptions that cost me a lot of time.

Given the record count, I decided it didn't make much sense to use Drupal's core search functionality; I was under the impression that the core search just grepped through the contents of the node table, and would therefore not perform particularly well. That's regrettable assumption #1. Regrettable assumption #2 is simpler: I didn't think search would ever perform well as long as the index was stored in the database.

As a result, I went on an odyssey of sorts looking for replacement search engines. Some of the contenders:

Apache Solr from Acquia
Apache Solr is a Java-based search indexing platform with a supporting Drupal module, and as it happens, the Drupal support company Acquia provides a hosted Solr service that can be leveraged by subscribers. We do have an Acquia subscription, but unfortunately we also have hundreds of Drupal sites, and the subscription doesn't quite cover that many.
Self-hosted Apache Solr
We've occasionally considered setting up our own Solr instance as a service for our users around campus, but the administrative overhead doesn't really fit our schedules just yet. So again, I moved on.
Search Lucene API
Unlike the two Solr-based options, the Search Lucene API module handles its search indexing via PHP (specifically, via Zend_Search_Lucene). It also has a pretty good selection of helper modules available for things like faceted search, content suggestion, and so forth.

Of the three options, Search Lucene API seemed like the best choice with the least administrative overhead. Over the next couple of weeks I hacked away amid intermittent user support requests, slowly but surely piecing together the necessary components for a killer faceted search system. Once I was ready to try it, I started to import the content. Node by node it arrived, and the search kept on scaling successfully as it went. Pleased as punch, I went home for the evening so that the rest of the records could import.

The next morning my inbox was stuffed to the brim with out-of-memory errors from Drupal cron runs. I checked the search index settings; the system had managed to pull in around 33,000 records, but indexing had ground to a halt. It was so bad that I couldn't even access the index statistics page to tell it to rebuild. And this on a system with 112MB dedicated to PHP.

I was confused. I'd never experienced scaling problems with Zend Framework components before, and I couldn't imagine that Drupal added that much overhead. Not wanting to admit defeat, I posted an issue. Soon, the maintainer politely informed me that Search Lucene API was only intended to scale up to about 10,000 records, and less than that if they were particularly complicated.

It would seem I was hosed. However, I realized that there was one more contender I hadn't quite considered yet:

Drupal core search
Drupal comes with a built-in search module, and it's supported by any number of contributed helper modules providing the functionality it doesn't have on its own (e.g., faceted search).

Despairing of all other hopes, I turned off Search Lucene API and turned on the core search module with the appropriate helpers …and it handled everything without a hiccup!

As it turns out, Drupal's core search is a lot smarter than I'd given it credit for. Yes, it's searching against the database, but not the node table …it has a special search index table that is built up on cron runs, just like the other modules do it. With that in mind, it's no surprise that it's a lot faster than I had expected …plus, it doesn't introduce nearly the same PHP memory overhead as Search Lucene API, because a lot of the heavy lifting is offloaded to the database server (which, in our case, is more than powerful enough).

The moral of the story? Know thy bottlenecks. If I had realized how well Drupal's core search performed I never would have tried to optimize it out of the equation, and I would have saved myself a significant amount of development time. Good to know; lesson learned; hope this helps someone else.

On being a framework guy in a Drupal world

Recently, I've stumbled across a few rather interesting blog posts on how Drupal is perceived in other parts of the PHP development community. Thought I'd post the links and make a few comments here.

Read more...

DrupalCamp Austin in review

Well, all this weekend's adventures seem to have paid off pretty well; I'm back now from DrupalCamp Austin and I thought I'd go ahead and review some of the things I took away from it all.

Read more...

Drupal Features Tips

Here are some of the most helpful things I've learned about the Drupal features module in the last few weeks, written down in preparation for my DrupalCamp Austin deployment presentation this weekend.

Read more...

Co-presenting at DrupalCamp Austin

A couple of weeks back Adrian Rollett (one of my co-workers in the CWS office) and I submitted a talk proposal for this coming weekend's DrupalCamp Austin; we've been doing a lot of Drupal deployment research at work lately, and thought it would be worth sharing what we've found. The schedule was posted this morning, and it turns out we're in!

I'm excited to present; this will be my first time speaking at a professional conference, and I think the subject matter will be of interest to a lot of folks, especially people who deploy a lot of similarly-configured Drupal websites. Adrian will be leading off with a discussion of drush_make and install profiles, and I'll finish it up talking about the features module. Taken together, these three pieces of functionality make it possible to encapsulate your Drupal site's configuration in versionable source code, which in turn makes it one heck of a lot easier to redistribute those configurations as desired.

< Previous | 1 | Next >