Finally replicated...

Since we got our new database servers up and running, it had been about a month. I had both of the servers in sync, but because it was an emergency type of a changeover I skipped setting up replication at that time. Earlier this past week, I went ahead and started setting that up again. It didn't seem like a big of a deal at the time, but it ended up taking 2 and a half days to get the second server caught up. I guess that means we run a few queries each day, although only one slave SQL thread can run at a time which limits the amount of CPU that can be used by either of these severs for replication to about 25%. Since we have dual dual-core machines, it only uses one of the 4 available threads, making 25% the maximum. That was sort of disappointing from a performance point of view, but understandable to keep things perfectly aligned between the machines.

Once it was caught up, I went ahead and set up replication the other direction as well. We now have 2 servers which can handle any queries and the other will get the same data as well. All I can say is that it's about time. We've needed this for a while now.

This coming week, I'll be moving another switch over and putting the db servers behind the load balancers finally. That'll allow for a fail-safe, not to mention allowing me to reboot the database servers individually without shutting things down or having a short outage. This should also help me get some peaceful sleep since I finally won't have to worry about what happens if a server goes down.

Overall, I think our infrastructure is heading in the right direction to handle a lot more traffic, and it seems that each improvement on the server side seems to increase the output on the sales side. It also gives me options if I want to set up something unconventional, such as the W3C HTML validator that I have running on one machine now. But the biggest thing is that there is very little that happens on a typical day now that affects the performance for our users. That's what our investment has been about.

Everything including the Kitchen Sink

I was reading an article in a magazine about another Nebraska resident that goes by Shoemoney (who I met in San Jose last month - nice guy) and he was talking about diversifying within your niche. This had me scratching my head a bit, then Allan Dick from Vitage Tub and Bath sent me an email. Clawfoot tubs are a niche, so when he gave me an email about diversifying, Jeremy's interview popped into my head and things started clicking for me.

Kitchen Sinks

What Allan and his guys are doing is expanding within their niche. They have supplies for all sorts of bathroom related products already. They have relationships with Kohler, Whitehaus, American Standard and the like already. These manufacturers also make kitchen products. So what they're doing is expanding into a new area without setting up new vendor relationships. They're selling Kitchen Sinks and faucets at a new website - appropriately named buykitchensinks.com. So now expanding within a niche starts to make sense to me... building into another niche with products that are related but not quite the same and through the same vendors - at least initially.

Expansion with Minimal Risk

So as we start looking at some expansion plans, I'm going to use the advice of Shoemoney and use Allan's example to figure out how we can expand into new niche markets with minimal risk and initially using the same vendor relationships we already have. Thanks to Jeremy and Allan for helping to give me some ideas about future direction... and watch out those of you in tangent markets. We're coming.

ToolBarn is well balanced

For the past several months now, we've been using Kemp LM-1500 load balancers to split the load among multiple web servers. These are pretty simple Linux based load balancers which don't have hard drives - everything is on CF cards.

Well, to make our servers even more balanced, we're going to move to load balancing our database servers and our Mini(s). Yes... load balancing replicated database servers isn't unusual. That's actually a lot of the reason that the load balancers have a second network interface. But mini-balancing?

Since Google has been generous enough to offer us some cash off of a second mini, we're going to go ahead and look at buying a second one to put behind the load balancers as well. Load balancing a couple of minis will do several nice things for us.

1) If a mini fails or needs rebooted, we will still have a functional site search.

2) We can use one primarily for searching ToolBarn and one primarily for searching ToolPartsDirect, making for more functionality for our users (we're currently only offering mini search on ToolBarn). That should be a good thing.

3) The newer ones are smaller, so it won't even take all that much space in our increasingly crowded cabinet.

4) By load balancing, we'll be able to handle more qps (queries per second) through inexpensive hardware. Hey... we're sounding more and more like Google every day!

I'm not sure how many people are load balancing minis, but I'm fairly excited about this possibility. The current one is handling things pretty well, but more servers is always MORE FUN - and planning now for future increases in capacity can pay off pretty big. Reactionary planning doesn't keep things running well. Preventative planning is what I get paid for.

Google's note on crawling framesets

It comes up from time to time at the forums I hang around at that many sites use frames, but not too many people know if they can be crawled or not. Taking a look around our Google Mini this morning shed a little light on that topic.

Appendix F: Crawling Framesets and Frames

To crawl framesets and their nested frames, the framesets must be well-formed with the tags occurring within the tag. Anchors (links) must also occur within the frameset. Depending on the particular structure of your site, the search results may point to the frameset page itself or to the individual frame pages. There is currently no way to specify which behavior you prefer.

Sort of says it all... don't rely on the engines to handle frames correctly. Frames = poor SEO due to the unpredictability involved and lack of content on the actual page - the content is in each frame, which makes each one of those more valuable than the overall page but also much less useful to someone landing there.

It's been years since I've used actual frames for a design, but since the question gets asked quite often it seemed worth commenting on, especially since I was able to pull the information straight from the big G.