Now when I tried it got a bit different.
The first is while its loading and it sits there for 5min.
The second and third screenshot is from when it was finished, this time the browser didn’t time out but over 5 minutes dosen’t seem that great either…
I notice that the first request is to http://, which then redirects to https://. Could that redirect through your proxy be related?
Does it work fast when using https://, but slow when using http://? Is Drupal generating http or https links on the pages it’s building? If it’s configured correctly all links in farmOS should be https.
Not sure if this is related at all… just thinking out loud.
Edit: Sorry scratch that - morning eyes… I misread the first one as http but looking again it is also https. So that’s unrelated. That is just the redirect from /asset/add/land to /asset/35. 
I shouldn’t say to much yet but after uninstalling netdata that it looks like I had installed on all servers where I tried farmOS i have been able to create multiple land assets without a problem, it again is just as responsive as it should be…
Nope got my hopes up to soon, was probably that it is fast after restarting the docker containers that I also did when uninstalling netdata.
Some Loggs that may or may not be related that I saw now is in the db container
2023-06-30 13:14:29.760 UTC [45] ERROR: duplicate key value violates unique constraint "semaphore____pkey"
2023-06-30 13:14:29.760 UTC [45] DETAIL: Key (name)=(locale:sv:workflow state:authenticated:farm_manager:Drupal\Core\Cache\CacheCollector) already exists.
2023-06-30 13:14:29.760 UTC [45] STATEMENT: INSERT INTO "semaphore" ("name", "value", "expire") VALUES ('locale:sv:workflow state:authenticated:farm_manager:Drupal\Core\Cache\CacheCollector', '96497664649ed535b8ce93.64138476', '1688130899.76')
Sometimes they have showed up after the loading has been finished other times it dosen’t show up at all…
I don’t think that’s related. I opened an upstream Drupal issue about that error a while back: https://www.drupal.org/project/drupal/issues/3318915
AFAICT it’s harmless, and I definitely see it in my own logs as well, without experiencing the issue you’re facing.
Another thing that is really weird even thou I don’t know if it is related to farmos or my servers is that sometimes it has worked great for a little time and then when I look at how the server uses resources it look like this. Where the bumps in CPU and memory usage is when it is working great and after the drop it is not working so good anymore.
Hmm - well farmOS itself doesn’t do anything in the background generally speaking. It is just Apache running in the Docker container (and PostgreSQL depending on how you set that up). The only exception to that is Drupal cron can be configured to run automatically - have you done this? If not, then maybe it’s something else running on your server causing those CPU spikes?
I do have Drupal cron scheduled to run every day, so it might be something else but the really interesting thing is that during those spikes farmOS is the most responsive. Its almost as if my server is to strict to allocate resources otherwise but during those spikes it gets what it needs for that task and for farmOS to be responsive. I will continue to look into what it can be with my server that is causing this but other than trying to figure out where that load comes from I don’t have much of an idea right now…
Oh very strange. I misunderstood and thought you meant it didn’t work when the CPU spiked. That would have made more sense. Now I’m even more confused. 
Yep same here when I saw it the first time I thought I must look at it wrong somehow but when it has happened multiple times it feels like there is something really strange with my server…
Edit: After testing stress-ng filling up half the cores that server uses it the first add of land asset was decently fast but the second stuck as it has always done so don’t seem to be because the container uses more resources but that there is some other reason that it coincides…
After looking closer on how much cpu and memory the containers are using I can see that i get a small spike in RAM use when farmOS hangs until its coming on again. The CPU however don’t seem to do anything until it gets out of the hang but will look a few more times to see if it is always like that.
One thing that it actually is stopping me from editing in farmos UI is quantities but for now my plan to work around that is building asset link plugins to do what i need to do with quantities.
It seems to be something with how Drupal and my Docker setup under Proxmox works or rather don’t work together because I set up a plain Drupal 10 for another project and that has the same problem so will see if I can find something more to help with my problems…
Oh interesting. Good idea to try that. I wonder what’s causing it. 
I did found something about maybe it has something about the docker binding when there is a lot of files like drupal has but then it should be a problem for more people but I might try to create a drupal docker container without a volume bind to see if that helps anything even though that wouldn’t work to good in the long run. Otherwise I might make a new try without docker.
Are you bind-mounting the whole codebase into the container? Or just the web/sites directory? For a production instance, the only persistence you generally need is web/sites. Mounting the whole codebase is useful for development, but it involves a LOT more files being mounted, so that might be worth testing if you suspect this is the cause.
Just sites and I added vendor to get persistency of modules added by composer, there are probably better ways to accomplish that. But the vendor bind mount I added later after I started having problems… On the other Drupal system it was the whole html because that one I made it easy for myself and just used portainers default Drupal template.
I just found my old test install of farmos that was made without docker and since that has the same problem it seems more to be something with my proxmox install or something like that…
Just to update if anyone is having simliar problem in the future. I added some more swap and some more RAM to the VM hosting farmOS and then the problem seems to be fixed so even if it didn’t look like it took to much RAM something there was the problem it seems like.
