I’ve had bad experiences with other hosting providers, both mine and for my clients. With other hosts I’ve often had host-related problems while their reporting services claim that their services are up and their support line doesn’t answer, later to find out they’ve had major problems. At least in the age of Twitter it’s easy to find other clients of the same host and verify the problem is with the hosting company and not with my or my client’s server.

But when I decided to leave my previous ill-behaved host who had my VPS down for 5 days and couldn’t tell me if or when it would be back up—thankfully I keep my own backups—I looked for a VPS hosting provider that had been around for many years, appeared to care about existing customers and offered a good value. I picked JaguarPC partially because of some recommendations and partially because they had a special running where I could get my umanaged VPS with 390 MB of RAM for the price of 256 MB.

Well, the special never ended like I thought it might. In fact, three years later they—on their own initiative—upgraded me to a new plan that had over three times more storage, three times the RAM (four times the RAM of the base plan I had) and ten times the monthly bandwidth at a lower plan cost. They explained in the email that they want to thank and retain their existing customers. The actual upgrade itself caused no issues, outages or reboots on my VPS. (This is possible due to the VPS solution they are using.)

I have not known of any outages or slow server issues since I’ve been with them. I haven’t had to contact them once since I opened the account. However, they proactively notified me of a DDoS issue that they were experiencing and thought might affect me, and they kept an updated status report available. I checked my server and didn’t seem to be affected, but it was very refreshing to hear from the hosting provider and having regular updates. That is vastly superior to any other host I’ve dealt with.

I semi-publicly shared the adventure with some online friends. I posted the following on May 10, 2008 about my leaving my previous host and starting with JaguarPC:

When I suggested he [the VPS reseller] set up a new VPS for me he liked the idea at first but then asked if I wanted to go direct with the company that hosted my old server. That’s the second time he’s tried to pawn me off onto another company, and I suddenly recalled I had been concerned about performance issues, anyway, and now he suggests I go with the company who apparently lost a host server and can’t seem to get it back up? Nope, time to go with someone totally new. JaguarPC apparently has been doing this 10 years, so hopefully after 3 years they’ll still want my business. Plus they were having a sale that’s supposed to give me more RAM at the same price which should help with the concurrent requests I’ve talked about before.

I haven’t closed the old account yet. I don’t really expect for them to bring my VPS back up as it was, but I’d like to see how my backups restore before I totally give up on it. So far I think I’m missing a few emails, a static website I forgot to back up (no biggie) and perhaps some config info that might be handy to look at but isn’t critical.

I posted the following on January 19, 2011:

Well, so far I’m pleased with JaguarPC. There have been no major issues for me overall, and they emailed me an outage notice yesterday and linked to a support thread that was keeping running updates on a DDoS attack that was affecting several of their servers and networks. And as far as I can tell my server didn’t even go down, but I got the updates anyway.

It’s so nice to find out about a problem from the hosting company and be offered a place to find updates before I even know there is a problem.

The last two major host company problems I’ve had (with other host companies) usually involved no public mention of the issue for at least an hour or two after a major outage, and support lines and support system jammed and giving no information or false positive information. Here they have proactively notified me, so if I start having problems I know what’s probably going on and know where to look for updates rather than waste hours trying to troubleshoot something I have no control over.

I posted the following on February 4, 2011:

Wow! JaguarPC just auto-upgraded me to a new plan that is cheaper and has 3-10 times the specs the old plan has! I’ll post a redacted form of the email later when I’m not on my Droid. The jist is they want to treat existing customers as well as new ones.

Hoo boy, now I can increase the concurrency here and give some more cache RAM to the database.

So yeah, apparently JaguarPC does still want my business after nearly 3 years.

This is the (redacted) email they sent me about the February 2011 upgrade:

We are very pleased to inform you of an immediate upgrade of your VPS package. This free automatic update is to express gratitude to our loyal customers like yourself. We are upgrading all our VPS plans in next several weeks and today your VPS was upgraded on the new plan.

No action is required on your end. There is no other change to your hosting, domains, or IP.

“It is common in the web hosting industry to promote plans to attract new customers, but we really wanted to do something that was a way of saying thank you to our existing customers,” says Greg Landis , CEO of JaguarPC. “We could not imagine a better way to do that to give more for less. Our philosophy has always been to treat our customers with utmost respect regardless of their size, and we hope to maintain our strong customer loyalty with this movement.”

The upgrade details are as follows:

[server account name]

Your old VPS plan name: VPS – Freedom Plan
Your old VPS plan cost: $[...] + addons
Your old VPS plan specs: 15GB Disk, 256MB RAM, 300GB Bandwidth + addons

Your new VPS plan name: Linux VPS Pro
Your new VPS plan cost: $[...] + addons
Your new VPS plan specs: 50GB Disk, 1024MB RAM, 3000GB Bandwidth + addons

[VPS management products info]

We just turned 12 years old in last October and getting stronger in 13th year of business! This is a tribute to the loyalty of our clients and reflects our business concepts of good value, integrity, and honesty. It wouldn’t be possible without the ongoing trust and business from clients such as yourself. Thank you all again for your business and referrals. We wish you all the very best.

For a year or two I was successfully running Drupal with lighttpd and fastcgi. Lighttpd is very efficient, and having 4 fastcgi PHP processes let me limit the memory php used while keeping my small sites responsive enough. But redirects and URL rewriting are done differently, and it was tricky at times to get it to work the way I wanted with Drupal. I eventually got tired of wrestling with rewrites and redirects with every new non-Drupal php-based app I wanted to try, so I started thinking about how to make Apache work for a small site.

Now I am running Apache2/mod_php with a Squid front-end cache. If you’re not familiar with Squid, in brief it is a web proxy that caches web requests. It is often used to speed up clients but can be reversed to cache requests on the server end in web accelerator mode. Apache uses more RAM than lighttpd/fastcgi, and Squid uses RAM for itself and the cache, so I had to cut back two 2 Apache processes.

That may sound like too little, but here’s how it works well: the threads aren’t stuck delivering a request to a slow remote client because the local Squid cache accepts the request locally and then delivers it to the client freeing up the Apache process to handle the next request. 2 processes can handle my traffic because they can quickly deliver their payload to the cache and move on, and Squid can handle the delivery over the network to the client.

Of course sometimes the processes get hung up on slow MySQL queries or slow PHP queries, so occasionally I had delays. In particular I got rid of my RSS requests, because the Apache process had to wait while requesting RSS feeds from other sites, and sometimes that got slow or even timed out leaving just one Apache process handling requests, and if it stumbled on something then I’d have client requests waiting in line not getting served. So I got rid of my news feeds. Note that I am talking about my web site pulling feeds from other sites; of course I can offer RSS feeds for my Drupal blog with no such PHP delays. I also strive to keep my MySQL running smoothly, but everyone should do that, anyway.

The downside of using Squid is logging. Since Squid is my front-end web server I have Apache listen on 127.0.0.1:80, and Squid accesses it there. So my Apache log files show all requests coming from 127.0.0.1, and many static page or image requests don’t come through because Squid has them cached. However I configured Squid to log in Apache log format and just use those logs instead.

Of course dynamic content from Drupal has the nocache header, so Squid isn’t caching the dynamic content for future requests, but it still frees up Apache while delivering it to the client. It does cache the static files like images, style sheets and javascript files, so the Apache threads mostly focus on dynamic content only.

Another way I keep memory usage down is with eaccelerator. It caches PHP scripts so they don’t have to recompile every time they’re run. This can save memory in addition to processor time. After changing Drupal or any of my scripts I usually delete the cache and click around my sites to force all the php to run so eaccelerator will cache it. Then I restart my php processes (Apache2 in the case of Apache/mod-php or the fastcgi server if using fastcgi) to lower their memory usage. After that the cached scripts should run and the PHP processes shouldn’t bloat as much. Note that every time PHP is updated eaccelerator must be recompiled. In older PHP versions it would crash if you didn’t, but now it just silently (except for a log entry) fails to cache your scripts if you forget to recompile after a PHP update.

With lighttpd/fastcgi I was able to run 4 PHP processes (memory_limit from 8MB – 16MB), lighttpd, MySQL and Exim (my mail daemon) in a 256mb VPS with good speed. With Apache2/mod_php I am running 2 Apache2/mod_php processes, Squid (8 MB cache memory), MySQL and Exim in a 256mb VPS. Having only two processes forces me to watch for slow requests like a hawk, but Squid takes care of slow clients. I still ran into memory problems occasionally, but now I have a 384mb VPS and haven’t had a privvm failure yet.

You may also be interested in Using Squid To Cache Apt Updates.

I never did upgrade my VPS RAM. Part of it is laziness, but part of it is that I keep thinking my web server doesn’t do enough and isn’t busy enough for 256mb to not be enough.

I’m using mod_php for drupal and CivicSpace on several sites. I’m running Apache 2 with the prefork MLM. The problem with this setup and limited resources is that the running Apache processes bloat to handle the biggest PHP script they’ve run. To counter that I reduced the number of Apache processes. Per earlier blogs, I also deleted unused drupal modules and all my sites work fine under a PHP memory limit of 12mb. Between those two things I’ve kept my memory issues at bay.

However, running only 4 Apache proceses is causing problems, too. If a PHP script is slow to complete due to business or MySQL slowness, then that thread can’t handle any more requests.

Using the Apache worker MLM would relieve both the sustained memory bloat issues (memory can be released upon completing the PHP script) and the concurrent connection issues (no problem to make a new thread to handle a new request), but then you have all that PHP & thread stuff to worry about.

I started looking into another solution that I’m going to try: FastCGI. With FastCGI you take mod_php out of the web server and run a persistent PHP (or other language) interpreter. The web server passes requests to the persistent interpreter. In PHP’s case, the php-cgi program will spawn multiple child processes to handle requests. I got this working on my home server and it works fine. Now the web server (I also switched to lighttp, but Apache can do FastCGI, too) can handle tons of requests with little resource usage and pass off the PHP scripts to the persistent php-cgi group. Sure, I can still overload my php-cgi group, but at least I can keep servicing small requests while PHP is jammed up. And I’m not servicing small requests with fat processes. But the biggie is now I can seperately manage my web server resources and my PHP resources for better fine tuning.

I’ve been hitting the limit of my VPS’s (virtual private server) 256mb RAM limit since installing CivicSpace, and I keep adjusting the php limit to try to avoid having forked processes fail, but then CivicSpace will fail on certain admin pages.

I now understand that when looking at the module activate/deactivate page it loads *every* module installed, even if it’s not activated. (For other pages it only loads activated modules.) Since CivicSpace includes so many modules, this almost guarantees I’m going to run out of php memory if I have the limit set at 20mb or 16mb, and that’s about the same range where I bump my head on the server privvmpages limit given my current configuration.

I don’t think I’ve had this problem with Drupal yet, but I probably will as I keep adding modules.

As a temporary fix I’m going to remove modules that aren’t used and aren’t likely to be used. For a more permanent fix I’m going to pay more to get a higher RAM configuration. Instead of just picking 384mb or 512mb I’d like to look into how I want Apache, MySQL and PHP tuned and figure out how much RAM should be dedicated to each. I might also setup my own test box and run stress tests on Drupal with various configurations. Then I’ll know my RAM target.