java - 我应该保持与谷歌云存储的开放连接吗？

Question

为了与 Google Cloud Storage 通信，我遵循以下示例:https://developers.google.com/storage/docs/json_api/v1/json-api-java-samples

我应该保持与云的开放连接吗？这不会导致内存或资源问题吗？

/** Global instance of the HTTP transport. */
private static HttpTransport httpTransport;

private static Storage client;

否则，我是否应该在每次获取/删除请求后关闭连接？最佳做法是什么？

我正在开发一个将部署在 Linux 上的应用程序。应用程序将收到一个 HTTP POST 请求，其中包含要上传到云的文件。首次加载应用程序时，我将以下内容作为全局变量启动:

// Initialize the transport.
httpTransport = GoogleNetHttpTransport.newTrustedTransport();

// Initialize the data store factory.
dataStoreFactory = new FileDataStoreFactory(DATA_STORE_DIR);

// Authorization.
Credential credential = authorize();

// Set up global Storage instance.
client = new Storage.Builder(httpTransport, JSON_FACTORY, credential)
    .setApplicationName(APPLICATION_NAME).build();

这是最佳做法吗？此实现会导致内存/资源问题吗？

Answer 1

我认为您错过了来自 google 的最佳实践文档。在 https://cloud.google.com/storage/docs/best-practices 查看将数据上传到云存储这将消除您的所有疑虑。

• If you use XMLHttpRequest (XHR) callbacks to get progress updates, do not close and re-open the connection if you detect that progress has stalled. Doing so creates a bad positive feedback loop during times of network congestion. When the network is congested, XHR callbacks can get backlogged behind the acknowledgement (ACK/NACK) activity from the upload stream, and closing and reopening the connection when this happens uses more network capacity at exactly the time when you can least afford it.
• For upload traffic, we recommend setting reasonably long timeouts. For a good end-user experience, you can set a client-side timer that updates the client status window with a message (e.g., "network congestion") when your application hasn't received an XHR callback for a long time. Don't just close the connection and try again when this happens.
• If you use Google Compute Engine instances with processes that POST to Cloud Storage to initiate a resumable upload, then you should use Compute Engine instances in the same locations as your Cloud Storage buckets. You can then use a geo IP service to pick the Compute Engine region to which you route customer requests, which will help keep traffic localized to a geo-region.
• Avoid breaking a transfer into smaller chunks if possible and instead upload the entire content in a single chunk. Avoiding chunking removes fixed latency costs and improves throughput, as well as reducing QPS against Google Cloud Storage.
• Situations where you should consider uploading in chunks include when your source data is being generated dynamically, your clients have request size limitations (which is true for many browsers), or your clients are unable to stream bytes in a single request without first loading the full request into memory. If your clients receive an error, they can query the server for the commit offset and resume uploading remaining bytes from that offset.