Two examples I've seen recently are Road Runner in the US and Virgin Media in the UK. There are many, many more.
341 karma · joined February 4, 2009
If you've got a site you're struggling to scale, we can help. http://bashton.com/
As such, when a failover occurs a site will be unavailable for many viewers for several hours and possibly even days, making the solution anything but highly available.
Earlier this week I set up DKIM, and initially tried and failed to use a 2048-bit key, because of this issue.
I'd love to use Google Apps for my business, all employees already have Android phones so from that point of view it's a great idea. Things like this are what is stopping me from actually doing it.
That and I don't know if I could stand to be parted from mutt.
This thread gives more context:
http://groups.google.com/group/mozilla.dev.security.policy/b...
Agree with you to some extent on stability - I've seen Solaris boxes with a load of 300+ still up and running although unusably slow, where Linux would almost certainly have died from resource starvation. In general use, both Linux and Solaris are pretty damn reliable though.
Interestingly I've never come across any pure Solaris shops that run ZFS, I suppose because if you're conservative enough only to use Solaris, you're too conservative to trust ZFS.
"Since InnoDB stores the table in the primary key, I decided that rather than use an auto_increment column, I'd cover several columns with the primary key to guarantee uniqueness. This had the added advantage that if the same record was inserted more than once, it would not result in duplicates."
The 'correct' way to deal with this in MySQL is using the auto_increment_increment.
http://dev.mysql.com/doc/refman/5.0/en/server-system-variabl...
Of course, the real difficulty with mutli-master setups split across data centres isn't ensuring uniqueness of primary keys, it's ensuring data-integrity under a split-brain scenario, i.e. where one server can't reach the other, but users can reach one or the other. UPDATEs and DELETEs to rows can then become extremely difficult to merge back together. This wasn't a problem for this application, but as others have commented, this use case probably wasn't best suited for an RDBMS anyway.
Wikipedia for once failed to enlighten me.
HSBC give us the option of having the funds deposited into HSBC accounts in those currencies, or converting to GBP (at our expense, not the customer's).
I'm very happy with this arrangement - it stops many customers from being put off by not knowing how much the service is going to cost them month to month, with the minimum of hassle for us.
The plugin architecture looks like it'll make it pretty flexible, but it'll have to be pretty special to beat Varnish in terms of performance.
If you're large enough for the downtime associated with a reboot to be a big issue then you've presumably already got a minimum of two machines performing the same function. That being the case, it's no problem to remove each node from the cluster in turn, upgrade the kernel, reboot, test and add it back in.
That rather makes the service more of a convenience. For example, for active/passive setups where a failover produces an undesirable amount of downtime (say 30 seconds whilst services migrate), or single server setups where uptime isn't critical, but downtime is still a pain.
Cool technology, but perhaps an example of a solution looking for a problem. I think at $4/month the convenience aspect can probably justify the cost in many cases.
http://httpd.apache.org/docs/2.0/programs/ab.html
For more realistic mutli-page tests Selenium works well - spin up a few EC2 or similar machines, run Selenium Grid and you can get a decent idea of how your site will cope.
For a simple Wordpress blog Apachebench should suffice though.
I have a few customers that use this when doing schema changes. Obviously, this relies on cached data being useful for your site, but for many applications a stale cache is massively preferable to an error message.
The API documentation is a bit frustrating, but the service itself is good and gives you the option of recurring payments. We can also accept payments in multiple currencies, which a lot of customers appreciate - if you bill people in GBP but they have a dollar card, how much they actually pay is an unknown.
Used GnuCash for 5 years, and whilst it was OK, Xero is a hell of a lot nicer to deal with.
Many servers have it configured, and if it's available on the destination almost all MTAs will use it to send mail to other servers, even if they don't support receipt of mail in this way.
It sounds to me like your competitor is targeting a different market to you, and picking up some of your target market as a happy accident. If you focus on the needs of your market, it becomes less and less likely that those sort of people will use your competitor's product.
I suspect the competitor is unlikely to care too much about your product - they'll see it as a 'low end' solution that only has the potential to take away customers they don't make much from anyway.