dmk23

EBS disk performance is unacceptable for high scalability applications.

There I said it!

Actually there is absolutely no need to wait till you are running $10K cloud bill to buy your own hardware. There are plenty of real cheap second-hand boxes you can buy from equipment recycling companies.

The real killer with the cloud is bandwidth and storage. With my colo deal I am paying about 5-10% of what bandwidth would cost at Amazon. Not to mention I can put any kind of storage I like with the actual cost per Gb to buy outright being equal to monthly cost on EC2. Go figure!

Cloud has its place to handle spikes of demand, but it is really not cost effective to scale.

Adding SSD is not linear scaling. SSD has entirely different characteristics from rotational drives which in itself brings 1-3 orders of magnitude I/O performance improvement.

Trying to fit high I/O workloads on spinning disks is a lot like spending your efforts to make your program run on 64K RAM. An interesting challenge, that would surely exercise your coding skills, but would not deliver the optimal performance.

Of course, you'd have to upgrade from vanilla MySQL to Percona to take advantage of this option.

Given that Percona is fully backwards compatible with MySQL, while adding this and many other tuning options, I just cannot see a reason to use vanilla MySQL ever.

There is no point of taking these metaphors too far or too seriously.

The idea of painkillers vs. vitamins is a must have vs. nice to have. Call it painkiller, antidepressant or get-out-of-jail ticket the concept is the same.

My favorite metaphor is whether my product is an offer my target customer cannot refuse. For whatever reason.

The only thing that really matters is overall system performance, which means software / hardware combination.

It is hard to see the benefit of ignoring SSD to get high I/O performance vs. redesigning the software around I/O bottlenecks.

Redesigning software to work on bad hardware is definitely a challenging project, but not always the best use of resources.

Quoting from the article:

=============================

What to do?

I wish I could say you should use Percona Server with XtraDB.

If we were using SSD as storage, then I would recommend it. Vanilla MySQL performs equally bad on SSD and HDD, while for SSD in Percona Server we have “innodb_adaptive_flushing_method = keep_average”.

Unfortunately on spinning disks (as in this case), Percona Server may not show significant improvement. I am going to followup with results on Percona Server.

=============================

SSD is the solution because unlike rotational disks it allows for lots of random accesses. While they are too expensive to use as "archiving" storage, SSD excels as a layer between traditional disks and RAM. Put your high I/O workload on SSD and keep your historic data on spinning disks.

If you want to see some SSD benchmarks, here is your resource: http://www.ssdperformanceblog.com/

As far as cloud storage, yes, Amazon EC2 offers 68GB RAM, however if you need hardware of that size it is not hard to justify setting up your own servers. It would be cheaper too and you'll be able to fully optimize your storage.

Not really, if you are using hardware of this size chances are you are hosting it yourself and can install SSDs.

Solid State Drives is the easiest solution to most problems requiring high I/O throughput and data persistence.

Too bad most cloud hosting vendors are way behind on offering anything like that.

EDIT: Not sure why this comment got down voted, but perhaps whoever did it might comment on why using SSD is not a solution.

This is really a no-brainer. If you are offering API you want to make it as easy as possible to adopt and implement. However, perhaps it is advisable to go even one more step beyond providing "starter projects" and suggest actual use cases. They could be implemented in those starter projects (best case) or simply illustrate the utility / value of the API. Don't just rely on 3rd party developers to figure out what to do with your API - provide guidance of what you might want to see them do with it.

Make money, not drama

I would expand this premise by saying that a launch should be about unveiling the company, not the product.

Once the product trickles out and gets adopted quietly you establish a track record of results. THEN you can tell the world about the wizards behind the curtain, what is next and what is in it for customers, partners and investors. The purpose of the launch should be to accelerate your momentum, not create it where it does not exist.

If you have to rely on any conference to gain traction you are in deep trouble. Make sure you have a solid business that can execute with as little external dependencies as possible. Launch on your results and accomplishments, not just stories and promises. People who attend these conferences are suffering from information overload. Prove something and you'll get a chance to stand out from the crowd. Generally you'll get way better treatment if you make them want to be part of your success, rather than be a supplicant desperate for a lifeline.

The title of the article is not very representative of its contents. It should be: "5 subtle ways you’re using MySQL as a queue, and how it COULD bite you IF you use poor schema design NOT optimized for YOUR workload".

MySQL queues work just fine with the recommendations Barron provides himself "1) avoid polling; 2) avoid locking 3) avoid mixing queue and archive tables".

The best quote from the article:

"This is what boards need to learn: top slot = product person, second slot = operations person. Not the other way around."

You must be slow. I build my services to work in whatever browser my clients are using.

That's exactly why it is a bad idea to use most cloud systems when you need high database performance.

With our own hardware in our own colo we can optimize performance to exactly suit our system needs. The biggest benefit is being able to eliminate I/O bottlenecks with SSD storage for transactional apps and use larger 3TB drives for data archiving.

By definition a "product" is not a "business". A business is a company that has products that bring in revenue.

Businesses that scale tend to have multiple products, so tying product name to company name could restrict your positioning going forward.

Go ahead, demand action. While you are waiting for response to your demands I'll keep building my business.

Because plenty of customers use it and do not want to change.

Seriously, do you think they are going to change their browser just to use whatever application you got?

Think of all the steps that go into setting up complex campaigns with proper split testing.

There is lots of hassle, inefficiency and errors that happen along the way.

I missed the video, but I am surprised why the rise of predictive analytics, creative optimization and advertiser workflow automation is not on this list.

Making and targeting ads effectively is very time-consuming and error prone. There is tremendous room for innovation.

Predictable legal environment that reduces frivolous litigation is really the biggest factor.

Spoke too soon, looks like they have already reached 500 according to the article.

In that case hard to see how much value would be in staying "private" given the same disclosures and the liquidity in the secondary markets.

With all the diffusion of their shares in the secondary markets they are on the way to reach 500 private shareholder limit and be forced by SEC to make the same kind of disclosures as a public company.

If anything the IPO timing is probably affected by their ability to stay under this magic 500 number.

Nice points in the article, but at the end of the day it boils down to one thing.

Is applying predictive analytics can make your business more profitable? This broader rule can allow for lots of exceptions to your guidelines.

Of course to know if predictive analytics can improve your profitability you'd have to test it or at least find examples of how others applied it to similar problems.

The problem with the current daily deals market is over-saturation with companies that "invest to acquire customers". Consumers are getting unsustainable and unprofitable discounts and this will go on until the investment mania in this sector cools down. After the shake-out the remaining players should be able to tune their models to run profitably.

This is not so different from what happened to original e-retailing back in the nineties.