TKBE

I got tired of dealing with GoDaddy after they continued to stone-wall me on the speed issue.  Earlier today I was seeing load times in excess of 40 seconds!

Everything is now switched over to bluehost.com, and hopefully things will converge on normality.  It took a little less than 20 minutes of downtime to do the entire switch, and it could probably have gone even faster if I knew what I was doing.  Big thanks to bluehost for their excellent documentation and for answering their phone almost immediately (no more “your expected wait time is 11 minutes”…!).  Big thanks also to the WordPress team for making it so easy to transfer an entire blog!

Load times are now in a sane range from 328 ms to 1830 ms (the larger numbers are all from Europe).

I seem to be having just piles of problems with my GoDaddy hosting lately.  I’ve been a customer since 2006, but suddenly this June (2010) the database holding my blog went *poof*.

Having spent a lot of time on archive.org and in the google cache, I managed to salvage some of the old posts, but it was a tedious manual process.  To speed up some of the mundane work, I wanted to turn on ssh access.  Should have been an easy option to enable from the settings menu in hosting manager, however, it told me my account had to be transferred to “newer” servers.  To do that I had to delete my blog (after exporting it) calling support, having them put in a service order, and waiting several days.

At my day job, I use www.pingdom.com to monitor the uptime on our servers, and naturally I’ve added this blog to the list.  Not long after the upgrade to the ssh-enabled account, I started getting text-messages saying the blog was down.  Turns out it mostly wasn’t down, it just had response times of over 30 seconds(!)

Below is the pretty graph from pingdom.com, with average response times per day, for the last month for access to the https://blog.tkbe.org page:

The only advice from GoDaddy support… turn off all the WordPress plugins (which I’ve done without seeing any improvement whatsoever).

Syntax hiliting is the ability to get code samples in your blog to look like they do in your editor… without having to add steps, or code, that brings you out of the “flow” of your article. Like this:

[sourcecode language=”python”] print "hello world" [/sourcecode]

which was accomplished by simply writing

[sourcecode language=”text”]
[sourcecode language="python"]print "hello world"
[/sourcecode]

Everyone seems to be using Alex Gorbatchev’s JavaScript code (http://alexgorbatchev.com/SyntaxHighlighter/) wrapping it in various ways.  The WordPress team uses (created?) a plugin named SyntaxHighlighter Evolved, which is what I’m using here.

I had the following tables

[sourcecode language=”sql”]
create table customer (
id int identity primary key,
…
)
create table foo_orders (
orderno int identity primary key,
customerid int,
…
)
[/sourcecode]

after various failed attempts at “alter column”, “add constraint”, etc. I finally found the correct incantation

[sourcecode language=”sql”]
alter table foo_orders with nocheck add foreign key(customerid)
references customer(id)
on delete no action
on update no action
[/sourcecode]

In (other) words:

• in the foo_orders table
• create a new foreign key
  • from the customerid field
  • to the id field in the customer table
• don’t check existing data in the table (with nocheck)
• if the customer is deleted, keep the foo_orders record (on delete no action)
• if the id field in the customer table changes, then do nothing (on update no action)

(at least that’s what I’m pretty sure it means 😉

Why the no action clauses? The foo_order table records info we send to external entities, and is part of the historical record.  Any changes should never happen automagically.