Hacker Newsnew | past | comments | ask | show | jobs | submit | mschalle's commentslogin

Unfortunately network reliability is also an issue in the SF zone. Apparently they replaced some routers 2 weeks ago, but that hasn't solved the issues entirely. Over the past 2 weeks I've had easily over 30 minutes of downtime. During this downtime no pings / web requests can connect, nor can any SSH connections, so I'm fairly confident it's a loss of connectivity on their end.

Regardless, I'm still happy with the service and the pricing, and will continue to use them in the hopes of the network issues improving.


My one gripe with DigitalOcean is that their customer support leaves a great deal to be desired. For days I've been unable to replicate images across regions (any droplet I try to create gets in a permanent stuck state and can't be killed). I filed a service ticket days ago and was told I'd receive a response shortly but have still heard nothing. I've even sent replies pleading for some recognition that my issue is being worked on, but have received no response and no indication that they are working on my ticket. This does not bode well considering that creating a droplet from an existing image is a major feature of their product, and is not properly working.

While I have liked DO when it works and their prices are great, it comes at a cost. In my case that cost is their product not properly functioning and their team seemingly having no intention of fixing my issue.


As someone who works in (completely unrelated) support, the numerous emails may be a contributing factor to your problem. Most support is done using last contact as the priority. When you send a new email, you're resetting that counter and bumping yourself to the bottom of the queue.

This was a problem we had with a /particular/ support system (Kayako) and we've since resolved it (with ZenDesk) but if they're using something silly like Kayako, that might be the reason.

Also, if they have a phone number, use it.

Not justifying what they do, just trying to help you work them out.


Hmmm, that might explain why Pebble (the smart watch) support had this super passive aggressive sounding "if you keep emailing us about the same issue, we'll put your case to the bottom of the list" instructions.

Not the message you really want to be sending your already disgruntled customers - "Do I mail them and check to see if they even got my email which hasn't had any response in two weeks, or will that just put me _another_ two weeks further down their already abysmally slow response queue?".


Quora, you fucked up.


Hopefully this shuts up people always complaining about EBS...


Well, hopefully this helps to fix the issues with EBS that are cause for complaint....

Looks interesting, looking forward to trying it put to see how it performs.


I am going to be rebuilding our EC2-hosted PostgreSQL cluster soon, and will try out the provisioned IOPS feature (both with and without RAID) - happy to post benchmarks once I have some useful data.


Please submit to HN!


As someone whose team used the beta of this product - No.


As in no, you didn't consistently get within 10% of the IOPS you provisioned at their promised 99.9%? Or were there other problems?

I'd be pretty surprised if they were going live with this without being able to deliver, especially since this is likely to be very popular with people using EBS for databases under fairly consistent loads. It's one thing for I/O to suck when they're not actually promising anything, but it's quite another when you're very specifically paying for a performance guarantee...


I'd be really interested in hearing more details about your experience.


There's not really any mention of latency or what amount of concurrency is needed to hit the guaranteed level of IOPS. Is it an SSD with very low latency or just ten slow big hard disks striped together?


Color me skeptical, I predict those who pay for more IOPs will howl even louder. I think by now EC2 users have learned that EBS doesn't act like a typical disk drive so treat it like one.


This still doesn't compare well to alternatives, pending benchmarks with an actual application if I directly compare it to most other IOPS benchmarks.

So...no? I mean, I don't have to complain about EBS, it's really simple, I just don't use Amazon's stack therefore I have nothing to complain about.

Now if I was somehow stuck on their stack...like from building my product against their proprietary infrastructure...then I'd be stuck on my ass and complaining for an overpriced and underperforming service.

Their recommended solution is to use their proprietary KV store.


Well, shit.


What makes you think this will ruin them?


It looks better and feels snappier, so these tests are surprising...


It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.


Yeah I could never really tell how that even made it to the App Store. Some stupid wrapper around the web page, but the Chrome app is definitely more along the lines of what I'd expect from Google.


The latest update to the GMail app for iOS is vastly improved.


How does it compare to Sparrow?


These tests are only JavaScript benchmarks and don't reflect real-world usage well. Chrome for iOS has a custom network stack and (like someone else said) page prefetching among other things.


It supports SPDY which could make a significant difference at least for Google services.


The snappiness could be because iOS Chrome pre-fetches pages if you're on a wifi network. A lot of the lag of Safari on iOS seems to be in the actual fetching of pages.


I used to really like Coding Horror, but everything Atwood writes now days he sounds like a damn broken record. And his twitter feed is nothing short of immature and childish.


Disgraceful. How does the TSA constantly get away with shit like this?


Easy. Absolute contextual power with virtually no oversight.


Can we change the title to something more serious to reflect how truly groundbreaking this research could be?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: