2 ms·
So how many times a month do you have to implement this to be reasonable compared to the cost of the storage?
by simplyinfinity 6y ago
So how many times a month do you have to implement this to be reasonable compared to the cost of the storage?
- hartator 6y agoThis is not an implementation cost issue. It was just super hard to make the code perform well. Like you have to manage client sessions on your side and chose optimizations on your side. Like you have to spread things manually. Which is hard to do. Whereas S3 is maximising your bandwidth with no custom code required. It's not really S3 compatibility that was needed but B2 API wasn't good.
- prirun 6y agoHashBackup (author here) was one of the 1st if not the first B2 integration. I didn't find the B2 API any more difficult to use than the S3 API. It has the same functionality with similar kinds of API requests. The only significant difference is that you have to request an upload URL and download URL, and requests can sometimes return a code to get a new URL when a vault is full or overloaded. There is a price/performance trade-off: B2 has higher request latency than S3, no matter where you are (my experience), but they also are 5x cheaper on storage costs, 10x cheaper on download bandwidth, and have no price gimmicks like minimum object sizes or minimum object lifetimes like many other services (S3 IA for example). To make up for B2's request latency it is more important to issue requests from multiple threads, especially for short-running requests like removing files. Another key difference is that B2 always uses SSL whereas S3 can be accessed without SSL with little security impact because each S3 request is individually signed with a secret key. Setting up an SSL connection is more overhead, so another key to performance is to reuse connections. Both of these suggestions apply to S3 as well, just more to B2 because of the latency difference.