Disclaimer, I'm no Windows Fanboy: I use a Mac at home, and at work deploy code to over a hundred LAMP servers on three continents (using a Windows desktop).

I'm always looking for better ways to get my job done, save my employer money, and expand my skill set. So whenever I get a chance I'm looking at the competition of the tools we're currently using to see if there's tricks to learn, or reasons to switch. I've been keeping an eye on IIS on various Windows servers for a while, more recently I've been looking at SyBase and SQL Anywhere, as well as CouchDB for data storage (but more on those two later).

So: Windows, WIMP, and why I think you should be giving it a serious look if you're currently a Windows shop.

1. Use the expertise you already have in-house

If you're currently running Windows you already know how to: install patches, restart machines, manage security and ACLs, connect and administer, get help, etc. When I say you I mean you as an organization, not an individual.

When I was younger, and slightly more full of stupid than I am now. I made probably the stupidest decision of my professional life (thus far). I was in a Windows shop running Windows servers for everything, with quite a few applications running through Lotus Notes. I was tasked with building a new Intranet. Rather than re-training myself (one person, and an intern at that) to use the monstrosity that was Lotus Notes R5, I somehow managed to convince my boss that we should put a Linux machine in the server room. The project for the most part worked: I built a decent (by my then current standards) Intranet system for the company.

I guarantee the system didn't survive six months after my departure.

Why? Because maintaining it required everyone else (many more than one) in IT to learn what I was good at. They had to re-train themselves to maintain a single system in a network of many. It simply wasn't worth the effort.

2. Avoid duplication of Servers

When you introduce a new stack, you're inevitably introducing a new server. That's an extra server to maintain, backup, power, upgrade, manage, etc. If you're doing a small roll out there's inevitably a machine in the room already that's not seeing a lot of load, just throw it on there. If it's an entirely different stack your current solutions for a lot of the problems aren't going to work (your backup scripts and applications for Windows won't auto-magically migrate over to Linux).

If you read my first story, you can see how many additional problems I caused there. Backing up the machine was going to take extra effort. It was another slot in the rack that couldn't be used for anything else (despite ridiculously low load).

3. Avoid duplication of Staff

When you're running multiple stacks for important or critical applications, you need staff to support them. If you've got Windows servers and Linux servers you've got staff supporting them both. Multiple sys-admins, multiple people on-call, multiple sets of vacations to manage.

At my current employer, this is our current situation, as we have linux servers for the web, and Windows for everything else. This means we have two sets of system administrators, one for the Windows stuff, the other for Linux. We've got multiple pagers so one person from each team can be on call 24x7. I'm not suggesting this is bad per se, but it is an additional cost.

4. Integrate tightly with current technologies

When you're consistently running systems of a similar stack, things just play nicely with each other. Reporting applications, backup, information sharing, etc. It all just works. You don't need a different username password combination for your development server as you do for your machine logon, and another one still to restart a service. If your security policies permit (and it seems wise) you can centralize this.

At work we have passwords, many of them. We mount dev systems over semi-reliable samba shares, with unique logins and directory structures not entirely tied to our general login accounts. This causes both groups of sysadmins to come together for every new hire to create the appropriate directories and entries in various configuration files.

5. There's features out there not available on LAMP

Many of us have become overly complacent in the thought of Microsoft as a follower in the web arena, products like Internet Explorer aren't doing much to shake this. IIS 7 is more than a follower, in a lot of realms I feel it has advantages over the technologies I'm used to using. In particular I might call out their XML based configuration system, and per-directory configuration without the performance hit. In terms of configuration XML has a lot of advantages over .ini, in terms of parsing, grouping of elements, parent child relationships, etc. They're also easy to manipulate programatically with predictable results which allows Microsoft and others to create great user interfaces for their maintenance and upkeep (i've never found a graphical apache configuration tool I didn't hate). For per-directory configuration think .htaccess files, only with more power (like virtual hosts), and without the performance hit. Most production sites turn off .htaccess support (AllowOverride None) because otherwise you've got a slew of needless stat calls on every request, with IIS 7 you leave them on, the server simply subscribes to the files so changes are pushed into the application by the operating system, rather than being pulled on each request. You've essentially got drag and drop-able applications (since the entire app, configuration, data (SQLite), and all can reside on disk, in one folder) with no performance problems. Streaming media is also very easy on IIS servers, throw in the media services plugin and you get a wealth of congfiguration options, a process that's still difficult to set up efficently on Apache.

At work we end up leaving .htaccess support on a lot, mostly for some of our more frequently (daily) changing sites. By changing daily not only do I mean it, I also mean changes beyond simple database updates, drastic changes to code and presentation happen regularly. Rather than lean on our hosting provider for frequent restarts we've ended up leaving .htaccess support enabled. To manage the performance hit these pages are relegated to their own machines, in separate clusters from the rest of our production sites. Managing system configuration with all the various virtual hosts has become so complex that only a few staff members are trusted with the task.


In conclusion, and to be perfectly clear. I'm not suggesting that WIMP is the right solution for you. I'm merely encouraging that you pull your head out of the sand and consider your options. If you're already running a substantial Windows server room, there may be more reasons to stay, than to switch.

I’ve been using memcached to store session data for the past while, but we ran into a few problems at work that led me to dive in a bit deeper and see how PHP, Sessions, and memcached play along.

Short Version

When you start up a session a new entry is created in memcache, the expiry is the same as session.gc_maxlifetime. Session data is retrieved each time a session is started (either with session_start(), or if you have session.auto_start enabled, etc).

Long Version:

When session_start() is called for a new user several things happen very quickly:

1. A session ID is generated for the end user, this is seen in the HTTP response headers. HTTP/1.x 200 OK Date: Fri, 10 Jul 2009 16:07:21 GMT Server: Apache/2.2.11 X-Powered-By: PHP/5.2.6-3ubuntu4.1 Set-Cookie: PHPSESSID=c446fc5309c3b8d3aa6e90343dddab29; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 23 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html
2. PHP Contacts memcached and attempts to retrieve any information in that particular session ID get c446fc5309c3b8d3aa6e90343dddab29
3. Memcached returns no data for that entry, as it doesn’t exist yet.
4. Your page executes, setting data in the session
5. PHP pushes data into memcached: set c446fc5309c3b8d3aa6e90343dddab29 0 1440 32 name |s:6”asdasd;bar|s:3:”foo”;

On every subsequent page where a session is used, a very similar sequence of events is executed. When the session is started PHP contacts memcached and asks for the session data. When the page is complete it pushes the data now in the session to memcached. That last step is kind of critical, because it’s what’s controlling the expiry of the data within memcached. Take a quick look at the data being set once more.

set c446fc5309c3b8d3aa6e90343dddab29 0 1440 32 name |s:6”asdasd;bar|s:3:”foo”;

Data is being set, the key is your session id, 0 is a set of flags that the client can use to mark the data (often used to mark data that’s been compressed). The 1440 represents the expiry time for the data, 1440 seconds from now (24 minutes). That value was taken directly from session.gc_maxlifetime . It’s important to keep in mind that what memcached guarantees is that the data will not be available after that expiry runs out, but it promises nothing about how long it will be available. If your memcached instance crashes, or runs out of memory you’re going to start losing data a lot sooner. Finally we have the data in a somewhat truncated version of PHP’s serialize.

The fact that the data is sent to memcached after every request, even if you haven’t changed what’s stored in the session, is rather important. It’s what makes your session last for session.gc_maxlifetime after the user last did something, rather than simply that amount plus the last time you requested a document.