Slow /photo/preview performance
Hi all,
Because of the ongoing performance issues, I moved my whole Friendica database of opensocial.at and friendica.me to a dedicated root-server just for mariadb with 128GB RAM.
At first, it seemed like it helped and opensocial.at is faster than before (the performance of friendica.me is still a mess, but I will analyze it later), but the /photo/preview route is now going crazy:
It seems like the RAM I/O issue I had (which is now gone) is now replaced by an Network throughput issue - but at least the network I/O seems fine:
Do you have any idea what I can do now?
One thing would be to add a "StorageClass" for the Photo to load them (directly) from a filedirectory/block storage instead of the database.
Geplante Downtime / Server Migration
!Opensocial.at
-- English below
Liebe opensocial.at BenutzerInnen,
Ich starte nun eine Migration von opensocial.at auf eine stärkere server-hardware. Dadurch entstehen temporäre Downtimes in den kommenden Stunden.
Ich möchte mich für die Unannehmlichkeiten entschuldigen, aber ich denke, dass dadurch die gesamte Performance von opensocial.at wieder besser werden sollte :).
Lg,
Philipp
----
Dear opensocial.at user,
I'm planning to migrate my server infrastructure onto a more powerful environment.
The goal is to increase the performance, as, I think, you all currently experience a downgrading performance.
I hope it will help :)
It will take some hours, where opensocial.at will be temporary unavailable from time to time.
Regards,
Philipp
Leider hat die Migration nicht geklappt und ich musste wieder zurückrollen.
--> Ich probiere es im August noch einmal
---
Unfortunately, the migration didn't work so I had to rollback.
--> I will retry again in august
Norz Tekh 🏳️🌈 likes this.
Planned Downtime / Migration
Dear friendica.me user,
I'm planning to migrate my server infrastructure onto a more powerful environment.
The goal is to increase the performance, as, I think, you all currently experience a downgrading performance.
I hope it will help :)
It will take some hours, where friendica.me will be temporary unavailable from time to time.
Regards,
Philipp
--> I will retry again in august
Slow photo requests / inbox requests
Hi !Friendica Admins ,
I'm currently tracing down performance issues, I' currently suffering from on my nodes opensocial.at and friendica.me .
It seems like the main performance problems are
- delivering photos
- [code]/inbox/code] requests
You can see some peeks and some long runners here:
The long runners (10sec) are the /inbox requests, the peaks are delivering photos after opening conversations, network pane, ...
Do you have any hints how I could improve these two types of requests?
The database is currently using ~50GB RAM, I set them as high as possible.
'avatar_cache' => true,
'avatar_cache_path' => '/path/to/a/folder',
But that one is tricky to set up. Best is to store the photos in a folder outside the web folder and then you can define a rule in your webserver that will redirect requests to the avatar folder to that folder.
Roland Häder likes this.
Roland Häder likes this.
Philipp Holzer likes this.
/photo/contact
route for the avatar cache, don't I?
No, the setup process is completely different. You have to have a path (somewhere) that is both readable and writable by the frontend and backend process
This path needs to be reachable when you call https://your.server.tld/avatar
(you have to redirect /avatar
) or you have to define avatar_cache_url
.
You you setup the file path from above in avatar_cache_path
and set avatar_cache
to true. After you deactivate the caching of the avatars in the admin frontend, it should work.
The URL path is stored in the contact table fields. So once you defined that URL, you mustn't change it again, since all old requests would fail. This mechanism is powerful, but currently too easy to misconfigure, that's why it is only accessible via the config file.
friendica/Avatar.php at develop · friendica/friendica
Friendica Communications Platform. Contribute to friendica/friendica development by creating an account on GitHub.GitHub
like this
https://
? That's never a good idea.
seems to work : https://friendica.philipp.info/avatar/4c/a1/d7c/53/8b/f08b/cd3c2904ac0bfd56-300.png?ts=1682970014
This image is now served by a completely different nginx than the frontend nginx . Because it's stateless, I'm now able to start more nginx for "just" serving stateless static content!
Brilliant!
Philipp Holzer likes this.

Michael Vogel likes this.
xy..
in reply to Philipp Holzer • • •Fatal Error (E_ERROR): gd-webp cannot allocate temporary buffer
all the time.. could this be related to the "/photo/preview route" ?Philipp Holzer
in reply to xy.. • • •xy..
in reply to Philipp Holzer • • •/var/www/localhost/friendica/src/Object/Image.php
line 171
Michael Vogel
in reply to Philipp Holzer • • •Philipp Holzer
in reply to Michael Vogel • • •Roland Häder
in reply to Philipp Holzer • • •/tmp
folder? Here on my server it ran full withmagick-XXXXX
files.Philipp Holzer
in reply to Roland Häder • • •But there are just two zero-byte magick files at
/tmp
:)