Skip to content

Month: November 2011

New AIM Client, now I’m stuck with Message Storage, WTF

Published on November 18, 2011

I updated the AIM client on my iPhone the other day and signed in to check out what the new software was like. As a side effect of this, I have also been upgraded to AOL/AIM’s new “Message Storage” system, where they keep logs of chat messages for 2 months (and hey they’re working on making it longer!) so they can be synced between mobile phones and multiple computers.

While I can see what you’re trying to do, you’ve done it in a intrusive, annoying, and down right shitty way; and it’s just about enough to make me stop using your chat network entirely.

Strike one, it’s not opt-in; it’s fuck-you-you’re-using-it-in.

I’m stuck with it now because I logged in with the new client on my phone. That’s it, no going back, and no warning that upgrading the client was going to permanently change my account to this new service. Nothing more than a note in the feature list that they can store and sync conversations between devices.

Strike two, it’s not opt out.

Don’t want AOL storing your conversations on their servers? Tough shit, you can’t turn it off. Well other than on a per conversation basis, which isn’t what I’d call opt out. However, there’s no where I can find to disable this shit completely and the FAQ does a very good job of indicating that I can’t disable it at all.

Moreover, since I don’t use the AIM client on my desktop, (I use Pidgin), so I can’t enable their “off the record” mode, which is a piss poor way to “opt out” in the first place. Doubly so when you have to enable it on a constant ongoing basis every time a conversation is started.

Strike three, what the fuck kind of dumb-shit programmer did you hire to implement this? The first message you send to someone after being forced into this shitty little service is prefixed with this lovely wall of text!

“%username%” is using a new version of AIM that stores conversation history so they can see their chats wherever they’re signed into AIM (desktop, mobile, aim.com). If you don’t want your messages stored, you can ask netmasteroc3 to take the conversation “off the record” or use the new AIM so you can do so yourself. Visit preview.aim.com/.faq for more information.

Okay, I can see the need to notify people that conversations are being stored. That’s nice, kind of, until you fucking spam someone with this 4 times in a row because they didn’t respond after the first one and don’t provide a way for the person sending the message to TURN THE FUCKING LOGGING OFF COMPLETELY IN THE FIRST PLACE!

Now when I start a conversation with people, and they start asking me what the fuck am I doing, and I have to explain to my non-techy friends that it’s not, in fact, me who’s logging the conversation, but the shit heads at AOL that have decided that every fucking converstation I start should be logged, simply because I upgraded the client on my phone. And guess what, even the techy ones have a hard time grasping that there’s no mechanism to opt out.

Thanks a lot ass-hats. Time to start migrating to GTalk.

Wordpress on Nginx on Dreamhost

Published on November 10, 2011

By the time this is done being written I’ll have been running Wordpress on Nginx on a Dreamhost VPS. Better yet, I’ll be doing it with a smaller more well defined resource foot print, with better response times, and faster page loads than I had with Apache. The tradeoff, some more upfront configuration.

I’ve covered the broad strokes about my motivation here, here, and here. In short, Nginx offers a more consistent dependable level resource usage while still having the capability of scaling to serve may users, reducing the possibility of crashing the VPS while under moment of heavy load.

This is long, and may end up being multiple parts, so if you’re interested follow the jump and keep reading.

Continue readingWordpress on Nginx on Dreamhost

Getting a feel for the Nginx Stack

Published on November 8, 2011

Forgive me, I’m about to ramble here.

For the past several months now I’ve been dealing with trying to get my VPS configured in such a way that it was stable and used as few resources (mostly RAM) as possible. During this process I had considered switching the web server from Apache2 to one of the lighter replacements. More and more I’ve been reading about the preference for Nginx (pronounced engine-x), along with PHP-FPM, as the defacto standard for high performance PHP sites.

Time to investigate.

The Nginx Stack

I swapped Apache 2 and mod_php out on my dev machine with Nginx and php-fpm a couple of days ago. Mostly to make sure everything would go smoothly if I decided to move my VPS over and figure out what rule changes I’d have to make to get Nginx running.

To start with Nginx doesn’t use the 1-process per connection model Apache does, instead it uses async IO. This addresses one of the biggest Apache problems I’ve had to contend with, a sudden spike in traffic spawning off a 10s of new processes, is no longer an issue at all.

Nginx’s memory foot print is comparatively tiny too. I’m seeing about 10MB total for the 2 workers + the master process, instead of 4-8MB or more per process.

Couple that with a fixed number of cgi processes on the back end (either with fastcgi or php-fpm) and you can account for most if not all of resources that will be used under any load conditions.

PHP

With Apache gone, so to goes mod_php and mod_fcgid. Neither are ideal solutions to running PHP sites, but those are the breaks (devsrv was running mod_php because it’s was what Ubuntu setup back when I installed it, and mod_fcgid is what Dreamhost uses).

Nginx does things a bit differently. PHP is run as a stand alone CGI “server” that Nginx proxies requests to. I find there are a couple of really nice advantages to this, especially if you can run php-fpm.

For example, you can pool cgi processes based on actual more broadly defined considerations rather than Apache’s process class. Say you have 3 vhosts, each running Wordpress, they can be served by a single pool of php processes that can share resources like a php-apc cache.

Ultimately, this means you can still control the number of backend processes that used for PHP, but can do so while still sharing resources where it makes the most sense.

Figuring and Managing Resources

With a VPS like Dreamhost’s where there are hard limits on memory usage, and since there’s no swap space you can’t really deal with overages when they occur other than to have the watchdog kill your VPS. In short, you really want to be able to account for resource usage and deal with transient spikes in a way that doesn’t result in spiraling resource usage.

Apache has always made this a fun exercise. Yes it can be done, but like I said, it’s fun trying to tune a fuzzy system optimally when there are hard limits.

With Nginx, I can count on the server’s staying exactly, or very nearly exactly, where they were at initialization. 2 worker processes + a controller process nets me between 8 and 12MB of RAM used, and it’ll be that much regardless of whether I have 1 connection or 100 connections. The CGI upstream servers are likewise manageable. With php-fpm you can let it spawn more processes, but you can just as easily limit it to 1 or 2 if resources are scarce. Simply put, it’s much easier to account for how much resources you actually need.

Performance

The whole point of Nginx is performance, but I’m not use to seeing 2 processes handle a lot of requests and that takes some getting use to.

I ran Apache Bench (ab) against my dev server to see just how it performed against Apache setup similarly to how it is in production and the results were certainly impressive to me.

Serving static content (cached HTML files, images, css, js, etc.) 2 Nginx processes could handle more than 2000 connections per second (over 1000mbit network). This is about 2x more than Apache2 was able to handle in about 1/30th the memory foot print.

Serving dynamic content is of course considerably slower, ~3 connections/second can be handled going though the full Wordpress PHP + MySQL stack with 4 php-fpm workers and xcache running.

It’s real hard to completely quantify all the variables, especially when I’m deliberately trying not to.

Conclusions

Okay I admit this post was sparse on details, I’ll try and rectify that in the near future. For now, let me just say, if you can switch to Nginx with your php application you should see better performance and lower resource usage than the same thing running under Apache. I certainly have.