drupal planet

Just posted a new blog post to the Server Check.in blog: Moving functionality to Node.js increased per-server capacity by 100x. Here's a snippet from the post:

One feature that we just finished deploying is a small Node.js application that runs in tandem with Drupal to allow for an incredibly large number of servers and websites to be checked in a fraction of the time that we were checking them using only PHP, cron, and Drupal's Queue API.

If you need to do some potentially slow tasks very often, and they're either network or IO-bound, consider moving those tasks away from Drupal/PHP to a Node.js app. Your server and your overloaded queue will thank you!

Read more.

tl;dr Node.js is awesome for running through a large number of network or IO-bound tasks that would otherwise become burdensome at scale using Drupal's Queue API.

Below is a video and some notes from my presentation "Giving Back - Helping with Drupal's Issue Queues", which I gave to the St. Louis Drupal group at the April 17 meetup. Please post any feedback or additional resources/suggestions in the comments below or on YouTube.

• Note: This presentation roughly coincides with the Drupal Ladder lesson, Getting started in the issue queue.

• We’ll look at three different ways you can help contribute to Drupal’s success in the issue queues.

• Cleaning up an issue queue, testing and reviewing a patch, and writing your own patch.

Clean up an issue queue

Reference: Helping maintainers in the issue queue

Edit: There's a module for that™ now: Pingdom RUM. The information below is for historical context only. Use the module instead, since it makes this a heck of a lot simpler.

Pingdom just announced that their Real User Monitoring service is now available for all Pingdom accounts—including monitoring on one site for free accounts!

This is a great opportunity for you to start making page-specific measurements of page load performance on your Drupal site.

To get started, log into your Pingdom account (or create one, if you don't have one already), then click on the "RUM" tab. Add a site for Real User Monitoring, and then Pingdom will give you a <script> tag, which you then need to insert into the markup on your Drupal site's pages.

I registered isthereamoduleforthat.com on 2010-08-19 for fun—but after three years, and little traffic (besides bots and the occasional Drupal user popping over from an old link), I'm shutting down the site, and will let my domain registration expire.

If someone is interested in the domain, let me know how you'd use it in the comments below, and I'll consider transferring it to you instead of letting it expire and a squatter taking over.

DrupalCon Portland is only a couple months away (early bird registration ends soon, so get your tickets if you haven't already!), and I'll be headed out that way. If this will be your first time attending a DrupalCon, be sure to read my First Timer's Guide to DrupalCon from last year.

At this year's DrupalCon, I'm excited to hear about everything going on with Drupal 8, as we're nearing the end of the development cycle, and a release candidate is on the not-too-distant horizon.

After having a baby and shying away from much Drupal contrib/core work, I finally had some time in the past few weeks to get up to speed on many of the Drupal changes that have been committed in the past month or so—and boy are they amazing (CKEditor in core, new node edit form, new responsive layouts, new admin toolbar, config, views, etc.)!

PHP's command line interface doesn't respect the max_execution_time limit within your php.ini settings. This can be both a blessing and a curse (but more often the latter). There are some drush scripts that I run concurrently for batch operations that I want to make sure don't run away from me, because they perform database operations and network calls, and can sometimes slow down and block other operations.

Can you tell when the batch got backlogged? CPU usage spiked to 20, and threads went from 100 to 400.

I found that some large batch operations (where there are hundreds of thousands of items to work on) would hold the server hostage and cause a major slowdown, and when I went to the command line and ran:

...there's a site for that.

I just found out about SimplyTest.me today, and it allows you to, well, simply test any Drupal.org-hosted module, theme, or distribution in seconds.

No longer do you need to spin up (or maintain) a live website locally (which usually takes an extra minute or two—at least) just to check out a module or make sure a theme or distribution fits your needs before using it on a live or development site.

Instead of simply getting a screen shot or trying a theme on a demo site, you get a full Drupal website set up and configured with the module/theme/distro (as well as it's dependencies), so you can play with it to your heart's content (for 30 minutes if you don't have an account on the site, an hour if you do).

Some random bits of news from Midwestern Mac, LLC:

St. Louis-area Drupal Group

After taking a hiatus for the month of December, the St. Louis area Drupal Group will be meeting up (hopefully) on the third Thursday of the month as normal. We're hoping to have more structure to our meetups, and there are already some great ideas for meeting topics in 2013.

If you live in or around St. Louis and use or contribute to Drupal, please make an effort to join us and build up the Drupal community here in St. Louis!

As an aside, we still have a separate website for the St. Louis Drupal group—if anyone has ideas for how we can use that to spread the Drupal love in the center of the U.S., please let us know!

Server Check.in Launched

A couple weeks ago, we (Midwestern Mac, LLC) announced our newest service, Server Check.in, a website and server monitoring service that checks on your sites and servers every 10 minutes, notifying you of any problems. The service runs on Drupal, and integrates with services like Twilio and Stripe to handle SMS messaging and payments, respectively.

I (geerlingguy) wrote up a case study for Server Check.in and posted it to the Community showcase on drupal.org. This is the first application-type service built on by Midwestern Mac on Drupal, and we've already been hard at work improving the service.

If you have any questions about Server Check.in, or how it was built, please ask away; I had a great discussion with some other developers in this thread on Hacker News.

Hosted Apache Solr Search updated to 3.6.x

At the request of many people who wanted to do some neat new things with Solr on their Drupal sites, we've finally followed Acquia's lead and updated some of our Solr search servers to 3.6.x, meaning things like Location-based searching are now possible. And our servers are happier :)

Server Check.in is a simple and inexpensive server and website uptime monitoring service I've recently launched.

If you have a website or online service you need to make sure is running, Server Check.in is a great way to get notified when there's a problem. Unlike most other monitoring solutions, Server Check.in offers free SMS (text) messages and email notifications, and it only costs $15/year (just $1.25/month!).

The Motivation

There are probably thousands of other uptime monitoring services on the web, and it's typically a good idea to use existing tools rather than build your own—if they're practical for your needs!

I had three main requirements for any service I wanted to use:

I was recently browsing a very popular review website, when I noticed the following warnings popping up:

From simply loading their web page and seeing these error messages, I could conclude:

1. The website is using Drupal.
2. The website is using memcached.
3. The website is running on Acquia's managed hosting cloud.
4. The website has error reporting set to print all errors to the screen.

If I were trying to break into this review site, or cause them a bad day, the information presented in this simple error message would help me quickly tailor my attacks to become much more potent than if I started from a blank slate.

Security through obscurity

I will quickly point out that security through obscurity—thinking you're more secure simply because certain information about your website is kept secret—is no security at all. However, that doesn't mean that obscurity is not an important part of your site's security.