mattgadient.com

While reading through WHT, I came across a neat little tidbit.

It’s a bit of PHP code that can be used to get an idea as to how fast the processor is on the machine your websites are hosted on – or at least the speed you have available to you. A thanks to “webpan” of the WHT forums for putting up the code he used for his LiquidWeb test.

Basically, you create a php file that looks like this:

<?php
$startTime = microtime(true);
for ($i=0;$i<500;$i++) {
$j++;
for ($k=0;$k<10000;$k++) {
$j++;}
}
$endTime = microtime(true);
$delta = $endTime – $startTime;

echo “total time: $delta seconds.\n”;

//phpinfo();
?>

Call it “test.php” or something, and put it somewhere on your webserver – then browse and run it. You could modify it to do some more stressful math, but don’t go crazy.

I tried it on 3 hosts, and here were my results:

time in seconds - lower is better

Each test was run at 3 different time periods during the day. To make things a Read more…

I recently started up an account at SimpleCDN to help offload a webserver a little bit by putting static images there.  After a couple days, I decided to give Amazon’s CloudFront a try as well.

I’ll start off by saying this was originally going to be primarily about the performance differences. However, after a few hours of testing, I found there’s not enough of a difference to be worth mentioning – neither was consistently better than the other. Performance-wise, for the most part it really boiled down to how close each test location was to the nearest respective edge server. This was relatively small-scale testing with a site that pulled about 12 images per page (and thus pulled 12 items from each CDN), but I concluded that neither’s going to make a lick of difference performance-wise… at least, not for the typical individual who’s looking at these two for solutions.

That said, time to take a look at the merits of each at a basic level: Read more…

Background:

I used to use non-SEF url’s on a Joomla site, and recently turned on Joomla’s built-in SEF. Problem is that the old URL’s still “work”. Of course, this is great for people who visit – not so great when GoogleBot comes along.

GoogleBot comes happily along and for any given article sees the original archaic url with a bunch of parameters that have been there forever. Of course, there’s little incentive for it to use the “cleaner” versions. As far as it’s concerned, the archaic stuff is the original, and the new url’s are duplicate content. It could eventually change it’s mind as to the “preferred” page on it’s own, but there are a few fighting factors here. On one hand, the sitemap points to the “new” one, and it’s predominantly linked to through the current site. On the other hand, anyone who’s linked to the site in the past has linked to the “old” one, and let’s face it – it was there first.

To make the change and get Google looking at the right page, we’ll go over the things I tried that didn’t work, and then the thing I tried that did work: Read more…

Finding it again wasn’t fun :p

In any case, if you’ve got the default

Great Success !
Apache is working on your cPanel^® and WHM™ Server

message, you can simply rename the index.html file and place your own at:

/usr/local/apache/htdocs

I did this using SSH and creating an index.html using nano. I’m not sure if it’s actually possible to browse through the server using WHM, so you’ll probably have to either SSH or FTP into your server (optionally, the Virtuozzo control panel seems to let you browse the hard drive and edit files… if you’re using Virtuozzo anyway).

So… switched a site from one host to another.

Installed Joomla, restored the database, restored the template folder, and then started installing Extensions.

First up was JCE. I downloaded the lastest version, tried uploading/installing it from within Joomla’s Admin Panel, and then got the following message:

JFolder::create: Path not in open_basedir paths

Oh boy! Not so good.

Did a little searching around and came across some fixes, although the fix in my case turned out to be pretty easy.

Read more…

I’ve touched on this a couple of times, but I’ll go into a little more detail here. Assuming youv’e got a VPS (or dedicated server), should you host your own DNS servers, use DNS servers provided by your hosting company, use specific DNS services, or use the DNS provided by your domain name provider?

There are many factors to consider – maintenance, uptime & reliability, costs, speed, ease-of-use, and more.

We’ll start with a few pros and cons of each, looking at it from a typical VPS point of view:
Read more…

I recently attempted a domain transfer from GoDaddy to Namecheap.

I did all the steps – I unlocked the domain from GoDaddy’s control panel, then placed the order through Namecheap. Namecheap needed the EPP code – I used the GoDaddy control panel to email it to myself, and entered it on Namecheap’s site.

All seemed to go well until it got “stuck”. For a few days at that. A little searching around showed that it may take up to 5 days, but the odd thing was checking Namecheap’s Transfer Status page, the status description was “Transfer in Process – Acquiring Current Whois for Transfer Verification“.

Should it take over 2 days for a Whois lookup? I think not.

Although I had searched searched Google with terms similar to this page’s title, I hadn’t come across anything for this situation. I searched for “Transfer in Progress – Acquiring Current Whois for Transfer Verification” this time, and BAM, came across this Namecheap KB article. Basically it states that the status description I’ve been getting happens if the auto-whois that Namecheap does during a transfer doesn’t get anywhere for 8 hours. The transfer is effectively “stuck” at this point. Fortunately, that KB article gives instructions for opening a ticket to get it manually fixed (although it’s unfortunate that someone could be waiting for days before deciding to submit a ticket – would be nice if it was automated).

I opened a ticket at Medium priority and got an email 5 minutes later stating:

This happened because the current registrar is blocking our IP addresses for whois queries and we’ll have to manually insert whois details into the form. We have forwarded these details to our development team to investigate this further and manually update the whois info. Please allow up to 24 hours to receive the authorization email. Please use that time to unlock your domain, take off any whois privacy features and ensure that admin contact’s email is valid and checked frequently.

Thank you for letting us know about this problem.

In any case, a 5 minute response time by Namecheap is pretty impressive. All the steps they mentioned had already been taken, so it’s just a matter of sitting and waiting for the authorization email. I’ll update the post if there are any further issues.

Update: There weren’t any further issues. I got an email from eNom (Namecheap’s provider) with a link that I had to visit to authorize the transfer. GoDaddy sent me a mail at that point letting me know there was a transfer request. To make things speedy, I logged into my GoDaddy account, found the domain, looked at the “Pending Transfers” section, and approved the transfer. Less than an hour later, I got an email from Namecheap stating that the transfer was complete.

PREFACE: Back up your database before removing anything!!!

My Wordpress database was getting pretty big, despite not having all that many posts all things considered.

I figured the biggest issue was drafts wasting space, although it turned out to be “revisions” which make up over half the “post” size of my database. If you make a post and then tweak it 10 times because it doesn’t look right, you’ve just saved that post to your database 11 times. UGH! I’ll get into cleaning those up another day though.

Looking through PhpMyAdmin, the other area I found to be a bit large was the wp_options table. I started looking through all the listings and found a lot of entries that were obviously for plugins I didn’t use anymore. Some I deleted off-the-hop, but others I wasn’t so sure about. Note that a nice fast way of detecting and removing these “possible orphans” is using a Wordpress plugin I came across in my searching called Clean Options. It really helps narrow down what’s not being actively used.

In any case, looking up all these orphans took quite some time, but here’s a list of what I found out about some of them:

ai_ stuff
This appears to be leftovers from the All in One Adsense and YPN plugin
ai_120×240 — ai_120×600 — ai_125×125 — ai_160×600 — ai_180×150 — ai_200×200 — ai_234×60 — ai_250×250 — ai_300×250 — ai_336×280 — ai_468×60 — ai_728×90 — ai_adtype — ai_after — ai_archive — ai_before — ai_cat — ai_channel — ai_channel_ypn — ai_client — ai_client_ypn — ai_color_bg — ai_color_border — ai_color_link — ai_corner_style — ai_dfirst — ai_home — ai_lra — ai_nads — ai_nadspp — ai_network — ai_page — ai_post — ai_space
Yikes, quite a lot.  They hurt my eyes in notepad too. I was able to delete them successfully.

–

channel_id
chitika_id
These appear to be Read more…

My last week’s been comprised of a lot of reading, a lot of brain-storming, and a lot of planning.

Here’s a scenerio:

• Step 1: One of the sites on my VPS gets slashdotted, dugg, or picked up on by a major news site. It has actually happened a few times already although fortunately it’s been a side-story rather than a front-page news item (I say “fortunately” because I was on a shared host the times it happened. Being a side-story, it didn’t kill the server or get me canned).
• Step 2: VPS starts to choke – either Apache swells up and starts swapping / dies when it hits the memory limit, or MySQL starts suffering from the same effect. In any case, the site doesn’t handle the traffic.

If the VPS isn’t responsive enough to log in, the possible rush-to-fix’s become: Read more…

I wrote this up quite a while ago, and it’s been sitting as a draft since. I pulled information on each setting from a few different websites, and while I don’t have any “final results” to show you (and the write-up wasn’t quite completed), hopefully the information’s useful in helping you to better determine what each setting does (and how it will affect encode time and quality), and to come up with your own settings.

I’ve used Handbrake in the past to encode movies and various TV series from DVD source. Recently, I grabbed the latest version (0.9.3), and decided to encode a TV series from DVD.

In short, here’s what I’m looking to get from my encode:
-High quality, even if it takes a while to encode.
-File size of between 250-400mb for each 1-hour episde (about 42-44 mins).

Of course, the best way to see how well you’ve done is to find something to compare it to. Therefore, I grabbed a torrent of the same TV show, and aimed to create a better quality encode at a smaller file size.

Before dumping into the x264 settings, it’s worth noting that I used a 2-pass encode, and mixed the audio down to a 160kbps Dolby Surround encode.

Here’s a list of the x264 settings I chose in Handbrake, and why:

Reference Frames: 6
Normally, I’d go much higher here. However if you go too high, both hardware and *some* software players can choke. Unfortunately, reference frames are subject to diminishing returns. According to a document at mplayerhq.hu , while going from a setting of 1 to 2 would improve the signal-to-noise by 0.15dB, going from 6 to 12 would typically improve the signal-to-noise ratio by only 0.02dB but result in a 15-20% longer encoding time. Really high diminishing returns for something you probably won’t notice, and something that might cause issues if you ever try to play your video in a hardware player. That said, go crazy if you want and try 16. Just make sure your video plays fine afterwards.

Mixed References: Yes
You get some quality at the cost of some speed. I’ve never seen anyone give a good reason to turn it off. Read more…