@no1xsyzy #19 www 那个文件夹是原来用这个配置文件的服务器提供静态资源的，直接复制配置文件的时候忘记删掉了。我试过直接把 Nextcloud 容器的 80 端口暴露在公网上直接访问，同样非常慢。然后我在 compose.yaml 里把 Nextcloud 的镜像换成了 GitLab，反代配置不变，非常流畅，感觉问题出在 Nextcloud 上。

怎么还有一层 nginx，是提供静态资源吗？那估计你的 nginx.conf 也得提供下

目前看了下
services.nginx.volumes.2 = /opt/nginx/www/:/var/www/:ro
这文件夹是空的吧，本来是要和 nextcloud 配到同一个地方去，不然要么需要手动更新，要么 404 然后回落到 apache 上去。

你先不管 nginx，改下 services.nextcloud.ports 把这个的 80 直接放出来看看（而且其实没必要这个地方用 nginx 扣性能，过早优化了），问题出在 client-nginx 还是 nginx-apache
话说也可以 sudo tshark -i br-$(sudo docker network ls | grep nginx_network | cut -d' ' -f1) 跟踪下 nginx-apache 的网络流量

要不用 可道云吗

@no1xsyzy #15
compose 文件：paste.ubuntu.com/p/DWmwB96rgs/
同一个配置文件在 DigitalOcean 的低配机上反应非常快。
Nginx 外还套了一个工作在 TCP 层的 HAProxy，方便 SSH 端口转发提高安全性。已测试容器 HTTP 端口暴露公网直连，确定不是反代的问题。

增加 php-fpm 数量

nextcloud 本来就是为了大堆外围的，虽然未必比得上设一堆专门应用，但胜在一个平台，一人一账号。
（换句话说，只是为了存储的话还是换更好的吧，SAMBA 都更好）

性能问题也不应是在空实例上有问题。

先看下 compose 文件？

@no1xsyzy #10 试过在服务器上直接 curl 了，照样卡 10 秒才有响应。
@treizeor #13 以前试过这个，反代好像有问题，不管怎么配置都经常跳到 localhost:80

可以试下 FileRun

换 seafile

nextCloud 属实拉胯
我自己基于 MongoDb 写一个云盘性能都要比它好

先不走网络，直接在服务器上 time curl --resolve 走一遭

再临时开一台服务器，全程开着 script 尝试复现，复现成功把复现过程展现出来，没复现就用新的这台（

性能糟糕的玩具, 连基础的存储功能都做不好, 建议换了. 你要是用上了, 放一个 几 GB 的文件上去, 服务器都可能假死掉.

??我用 gogs 也很慢，但是 gitea 快的飞起

我用的是官方 docker 镜像外加自己的 mysql，不是很卡，要不你试试换个数据库呢？

这货就是性能垃圾

换 seafile

换了，seafile

@loveyu #2 用的是官方 Docker 镜像，应该默认就是开着的

没开 opcache ？

开 ssh，让我上去看看