How good are your backups?

Do you have backups of your important data? At least once a day? Are they valid and recoverable? Have you tested them? Are they safe against all the common disaster scenarios (including but not limited to failed hardware, programmer mistake, corruption caused by bugs or power outages, malicious attacks)?

Are you sure?

Feeling confident isn't enough. You either know these things with absolute certainty, and you can prove it, or you're going to lose data.

If you aren't sure, and you're the least bit unclear on how to get there, give us a call. We can help you now, before it's too late. As good as our data recovery technicians are, it is easy for you to lose data permanently and beyond any hope of recovery. There are a lot more ways for things to go wrong than you might think. We know. We see it all the time.

Don't Neglect Front End Optimization

We're in Turkey right now for our annual meeting, and I just received a customer request for MySQL optimization.  I almost always do a little background research before responding to such requests.  One of the first things I do is load the customer's website.

In this case I watched Firefox's status bar, and noticed the following behavior on this slow network:

• Resolving DNS and connecting to the customer's site was quite fast, less than a second.
• For about the next 30 seconds, absolutely nothing happened; it was waiting for a response.
• After 30 seconds passed, Firefox's status bar began flickering back and forth between sending requests, waiting for responses, sending more requests, sending requests to different domains, and so on.  During this entire time, the page remained a blank white expanse of pixels.
• After about a minute of this, the entire page suddenly flickered and rendered almost instantly.  All of the images were fully downloaded; the page was just done.

This is a great example of the need for optimizing more than just the backend.  I don't know yet, but I feel pretty sure that the site's backend was indeed very slow to reply, possibly because of a long-running query in MySQL.  But even after that happened, my web browser did a lot of work downloading the site, and I was forced to sit and stare at white pixels.  There was no incremental rendering or anything else to keep me on the site.  This stage of the page load literally took over a minute.

This can be due to many different types of problems.  Most of them are quite basic mistakes and are easy to solve.  However, even though they are simple, they are also very widespread.  This goes right to your bottom line: there's no way an average user, who unlike me is not determined to wait it out, will stay on the site.  If you're making money from online commerce, that's a lost sale.  If you're making money from ads, those are impressions that aren't delivered.

Speaking of ads, sites that put ads (or tracking pixels) inline often impact the site experience very negatively, and this doesn't have to be the case, either.  When done wrong, a simple tracking pixel can bring the entire page load to a halt while there's a DNS resolution, connection to a third party site, downloading, and rendering.  On a slow network, this can effectively freeze the browser for five seconds or more.  And "clever techniques" to avoid it, such as using JavaScript, often just make this worse, not better.

This is exactly why Percona now offers frontend optimization as a formal service.  Many of us have deep expertise in the area; before joining Percona, for example, some of us built award-winning e-commerce websites that are among the top shopping destinations on the Internet.

Don't think your problems begin and end at query optimization or Apache tuning.  Changes on your frontend can dramatically improve the site's performance, too.  The difference between a site that takes a few seconds to render in the user's browser, and one that renders in the blink of an eye, is often not consciously noticed, but research proves that users enjoy themselves more and are much more likely to stay and return when "the site is fast."

Independent and Profitable

One of the important things you should know about us is that we're not venture capital funded and we have no debt.  Of course, if there's no outside funding and no debt, we must be profitable: and we are.

Why does this matter to you?

Simple.  Call us up and see how the lack of pressure to "make the numbers" translates into our approach to you on the phone.  If we're right for you, we'll happily tell you so.  If not, we'll tell you that, too.  There is no hard sell.

It doesn't stop at the "sales" step. (I put it in quotes because we don't really sell; no commision, no quotas). This infuses our entire relationship with our clients.  We're focused on the value we can deliver to you.  We're not focused on lining someone's pockets. And because we're not beholden to someone else, we assure you it'll stay this way.

Is remote DBA support right for you?

There's been a lot of discussion over whether hiring a remote DBA is really a win in the long term. Many people seem to think it's not, but it really depends on how it's done. If you're supplementing your internal team with some expertise that you wouldn't be able to hire or keep on your own staff, it can make a lot of sense. In our experience, a lot of companies can benefit from this type of relationship. Imagine that you're a business who relies upon MySQL but doesn't have huge racks full of servers -- say, a car dealership. You don't need to have a rock star on your staff, and chances are you can't afford or find someone like that anyway -- but it sure helps to have such a person available when needed.

Our pricing structure makes a lot of sense, too. No artificial roadblocks to try to force you to buy a package deal. No lock-in. No pressure to get per-server licensing. (Consider this. If you want your servers to run as efficiently as possible, would you hire someone who gets paid by the server?) Just by-the-hour, a-la-carte consulting, with the option to get onsite or other types of help if you want. This isn't without its tradeoffs -- in particular, you have to be an active participant in scheduling, since per-hour scheduling is less tolerant to slippage than having someone onsite for a whole day. But on the whole it's remarkably efficient.

We also align our compensation with your goals. We set things up so that serving you best is the same as serving ourselves best. You don't have to rely on our nobility or altruism to goad us towards doing the right thing. We love the satisfaction of a job well done, but even without that, the financial incentive is for us to do what's best for you.

Companies like Percona (we're not the only ones) are disrupting the old models, which have a lot of silly lock-in and other things that just don't serve the customers. There are plenty of fish in the sea. Everyone's looking for help, and it's hard to find. Why go the route of the lock-in, with the corresponding disincentive for improvement? Every efficiency we add helps us help more customers more quickly and better. So what if we're "working ourselves out of a job?" It's not as if there's any scarcity of jobs!

We're quite a bit different from other "remote DBA" companies. We are full-stack performance optimization experts -- we work on a lot more than MySQL. You can think of us as performance Ninjas, if you wish. But whether you're hiring a Ninja or a remote DBA, you should look for an approach that values your interests equally with the consulting company's. If you're considering remote DBA support and you want to know whether it's worth it, just ask us. We'd be happy to give you some satisfied customers as references.

Percona enhances MySQL with custom patches

Percona has been adding more and more custom features to the Percona MySQL build, which significantly enhances the manageability and functionality of the MySQL server.  The patches include features such as fine-grained query logging and user, table, and index statistics, as well as many other additions.  Some of the functionality is based on well-known patches from others, such as Google; some is uniquely available from Percona.

Percona makes the modifications available in source code form and as packages for RHEL, CentOS, and others. The Percona development team is also continuing to build an experimental high-performance patchset based on groundbreaking work with the InnoDB storage engine, targeted at reducing internal contention and greatly increasing the engine's ability to take advantage of today's multi-core, large-memory commodity hardware.

"Our patches are designed in response to the needs of our customers' mission-critical systems, and solve real-world problems in some of today's largest and most demanding MySQL installations," says Vadim Tkachenko, Percona's CTO and head of development.  "Some patches are sponsored by customers, and some are pro bono."  Tkachenko adds that MySQL users who need customizations to the MySQL server often turn to Percona, which has a staff of several full-time developers who build MySQL server enhancements and custom features.

The Percona patches and builds are available at http://www.percona.com/percona-lab.html »