问题标签 [large-file-upload]

Is it possible to store large images 1go to 2go medical images by uploading them to a mongobd database online?

the database is consulted by a doctor, who has the right to see the info about his patients.

what needs to be done to make the operation fast?

and how many ressources do I need to make this possible on a private server?

or is the cloud solution the only possibility?

我正在开发一个画布上传脚本来为客户上传巨大的图像。除了一个问题，我的一切都按需要工作。巨大的图像不起作用。目标是能够上传大约 20000x20000 的图像。

大约 15000x15000 的图像可以正常工作，但更大的则不行。结果甚至不一致。大多数情况下它们只是变黑，但有时浏览器会停止并给出它停止工作的页面。

上传的图像大多是质量在 20k 左右的艺术品。

你们知道如何解决黑色图像吗？

我想提供在我的 Web 应用程序中上传大小超过 1 GB 的 zip 文件的功能。我正在使用服务器端的 Multer 节点模块使用 nodejs 版本 8.11.3。在本地测试此功能时，它可以正常工作，但是当我在任何云服务器上托管我的应用程序时（无论云提供商如何），它都无法正常工作，导致浏览器无响应。通过网络上传文件时似乎存在问题。通过提琴手/邮递员请求尝试但没有成功。

已经遵循链接中提到的解决方案：

尝试分块发送文件数据导致许多 http 请求以浏览器崩溃结束 https://hpbn.co/xmlhttprequest/

尝试使用 websockets 发送数据（结果相同） https://github.com/rico345100/socket.io-file-client

尝试过 FTP 方法 http://ftp.apixml.net/

// 服务器端代码

// 客户端代码

预期的结果是即使文件大小超过 1GB，也应该上传文件而没有任何性能瓶颈。

我正在尝试设置一个“外部”web api，它将能够接收大型 http 帖子（+1GB）并将流转发到另一个将请求内容写入文件的“内部”web api。我根据使用自定义 WebHostBufferPolicySelector 和在控制器方法中使用 UseBufferedInputStream 方法的示例对我的实现进行了建模。它在使用 IIS Express 时按预期工作，内存占用量没有显着增加，但是一旦我的代码部署到 IIS，内存占用量就会很大并导致 OOM。

我已经在我的控制器方法和我的 WebHostBufferPolicySelector.UseBufferedInputStream 中放置了跟踪语句，并验证了 UseBufferedInputStream 总是返回 false 并且我的控制器方法受到了打击。我注意到的唯一区别是，当我调试时，UseBufferedInputStream 和我的控制器方法之间的时间戳非常接近。在 IIS 上托管的地方，时间戳相距甚远，这表明调用 UseBufferedInputStream 和调用我的控制器方法之间的某些东西完全缓冲了请求。

我正在寻找一些提示，以找出导致请求被缓冲的原因以及如何不缓冲并一直使用流。

客户端来自外部 Web api，内容类型为 application/octet-stream，传输编码为 Chucked。

用于构建实现

https://forums.asp.net/t/2018289.aspx?Web+API2+WebHostBufferPolicySelector+UseBufferedInputStream+override

https://www.strathweb.com/2012/09/dealing-with-large-files-in-asp-net-web-api/

代理 Web Api 控制器方法

内部 Web API 控制器方法

策略选择器配置

适用于内部和外部 Web API 的 WebApiConfig

当我尝试上传超过 50 MB 的文件大小时，将显示以下错误，因为要求允许的最大文件大小为 50 MB，并且如果附件大小超过 50，则在应用程序中显示用户友好的消息主板>

浏览器错误：（IIS 版本 10.0.14..）

HTTP 错误 413.1 - 请求实体太大

由于请求实体太大，页面未显示。

厌倦了 web.config 中的以下设置，但无法通过在 web.config 中启用自定义错误来工作。

链接 - https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httperrors/

需要在应用程序中显示用户友好的错误或将重定向到自定义错误页面。

传输 5TB 到 10TB 范围的数据时首选哪种 Azure 服务？

我检查了导入/导出、数据湖、存储资源管理器

我试图了解将大文件从前端上传到服务器的最佳方法是什么。对于前端，我使用了一个名为的库react-dropzone，它允许我获取有关我打算上传的文件的信息。我的上传组件看起来像这样：

这使我可以访问文件的内容，例如文件的名称、类型和大小（以字节为单位）。 这个库似乎也适用于更大的文件（100+ MB），但我的问题是当我想上传这个数据时如何调用这些数据？

我的一个想法是使用localStorage，但最大大小似乎在5 到 10 MB左右。然而，我也在Redux前端使用，但我不认为使用它store对于大文件来说是理想的。

这给我带来了一篇我读过的文章，该文章将文件存储在 React 状态中，但是这个示例似乎使用了较小的文件，例如照片。我的问题是使用这种方法是否适用于大约 100 MB 的较大文件？

我计划在上传到服务器时将文件分成更小的部分，Blob但我不熟悉 React 状态的大小限制，那么这是上传更大文件的最佳方法吗？

我正在使用 tornado 6.0.3 创建一个应用程序，并且需要使用 html 表单上传大文件。我如何流式传输文件，例如使用@stream_request_body装饰器来做到这一点？

我创建了一个简单的表单，如下所示：

它重定向到龙卷风处理程序 UploadHandler 并上传（到当前工作目录）选择的文件：

这可行，但我需要能够处理大文件，所以我无法将文件加载到内存中。因此，我尝试使用@stream_request_body装饰器，并且（除其他外）找到了此解决方案，但是一旦添加，@stream_request_body我就会收到以下错误：

然后我发现它说我的龙卷风版本不支持流式多部分上传，所以我（因为我使用龙卷风版本 6.0.3）需要将我的表单方法从POST更改为PUT并传递 XSRF 令牌通过 HTTP 标头。但是，html 表单不支持PUT方法，所以我猜我需要以某种方式使用 JavaScript，但我没有太多使用 JavaScript，也没有找到任何关于如何做到这一点的帮助。

所以我的问题是：

1. 如何使用最新版本的龙卷风，使用PUT和（或任何其他可行的）JavaScript 从表单中流式传输我的文件？
2. 如何通过 HTTP 标头传递 XSRF 令牌？我还没有找到任何关于如何执行此操作的实际代码示例。

先感谢您！

目前，我们在 AWS EC2 实例上的系统（客户端）在尝试将大文件发送到客户远程 sftp 服务器（“160.xxx.xxx.35.bc.googleusercontent.com）时遇到了 sftp 问题。对于小文件，sftp 传输工作正常，但是当文件大小大约或大于 1GB 时，我们发现只有 1068392448 字节传输到服务器 sftp 站点。但是，当我们将具有相同代码和相同环境的相同大文件发送到我们自己的非 googleusercontent 远程 sftp 服务器（只有 URL/用户名/密码不同）时，它是成功的，并且所有数据都正确传输。

这个问题是在客户服务器端通过添加负载均衡器进程进行一些更改后发生的。客户服务器端进行了一些调查，调整了负载均衡器超时，但无助于解决此问题。据说客户端在 1068392448 字节后停止数据传输，服务器端在允许的空闲时间（~50 秒）后等待并断开连接。

我们的调查注意到大源文件是从 AWS S3 读取并正确保存到本地的。当大文件数据写入服务器 sftp 站点达到1068392448 字节（所有测试结果一致）时，在服务器允许空闲时间（约 50 秒）后，TCP 套接字连接状态从 ESTABLISHED 变为 CLOSE_WAIT。该进程永远保持这种状态，直到它被手动停止/杀死。当 TCP 套接字连接处于 CLOSE_WAIT 状态时，dump 中显示的数据传输过程在 awaitSpace() 方法（在 java.io 包的 PipedInputStream 类中）处于等待循环中。缓冲区被指示为已满并等待写入服务器端。下面是等待循环的代码：

下面是转储：

目前，我们正在使用 com.github 的 vfs-s3 版本 2.4.2 和相关的 apache.commons vfs2 版本 2.1。和 com.jcraft 的 jsch 版本 0.1.54 用于 sftp 数据传输。我们的基本代码如下：

我们尝试在本地 Window 环境中测试相同的代码。有时我们会看到与 ec2 实例中相同的问题症状，但大多数时候问题不存在（不一致）。我们在其他 linux 系统上测试，将大文件发送到客户服务器 sftp 站点，没有问题。

我们尝试在 AWS EC2 实例上升级到 com.github.abashev 的 vfs-s3 版本 3.0.0 和 4.0.0 以及相应版本的 vfs2。但是，它为相同的大文件重现了相同的问题结果。尝试使用正确的配置文件值将 loadOpenSSHConfig 设置为 true 以保持连接处于活动状态，但这对这种情况没有帮助。

我们尝试通过 sftp "put" 命令直接测试 sftp，将大文件从 EC2 实例（和其他 Windows/Linux 平台）发送到远程服务器，并且大文件数据传输始终成功。

问题是问题的潜在根本原因在哪里？为什么服务器端在 1068392448 字节后停止接收数据，或者为什么其余数据无法发送到服务器端？我们的 EC2 环境有任何硬性限制阻止了数据传输操作（我们尝试检查一些限制但仍不清楚）？或者服务器站点错误地向客户端站点发送了连接关闭“FIN”请求（如何证明）？感谢您对潜在解决方案的任何建议。

请不要将此作为重复项关闭。我知道这里发布了许多类似的问题，但我已经尝试了所有这些答案，但问题没有改变。我已经研究了一个多星期。我找到的所有答案都在谈论我已经正确设置的以下设置。

我的 MAMP 服务器的 php.ini 包括以下内容：

我的 .htaccess 文件重复这些：

并且还有：

我的 httd.conf 文件包含相同的设置。

当我在运行时使用 进行检查时ini_get()，我看到了上面给出的 php ini 值，但max_execution_time无论这些设置如何，它始终为 0（无限制）。

使用FormDatain a XMLHttpRequest，如果我上传的文件最大约为 1meg，则 Content-length 标头看起来正确并且一切正常。如果我上传一个稍微大一点的文件，我会看到所有相同的值， Content-length 标头看起来正确（并且小于post_max_size），但是$_POST和$_FILES是空的，并且客户端会看到 HTTP status 413 Request Entity Too Large。php 和 apache 日志文件均未显示错误。

更新：

在进一步调查中，我发现Requested content-length of 1829686 is larger than the configured limit of 1024000. apache_ssl_request.log那么这个 1024000 的限制是从哪里来的呢？这是什么境界？find /Applications/MAMP -type f -exec grep -l 1024000 '{}' \;仅找到此错误消息，没有具有此值的配置文件条目。