Skip to main content


some pages are slow


Hello !Friendica Support ..

I don't know what page load times others have, just experience slow responses on my instance. A nice time woud be < 1 second, maybe.

I have some pages that are significantly slower:

- the statistics in admin (loong time, didn't measure)
- network page: 13s
- my profile page: 39s
- friendica support page: 47s
- admin page: 2s

so simetimes slower, sometimes a bit faster. but it currently frustrates me a bit. it is not a joy to use.

I am the only user on my instance and it is running on the "S" model here: php-friends.de/vserver-ssd

in reply to xy..

That's definitely not normal (except for admin statistics, these are actually slow. I'm also single-user instance and I don't have issues like these.

Tried to check your instance and it takes hell of a time to load, there is something fishy going on on your server.Aren't you "bombarded" by activitypub trolls or something? (check your worker queue)

Edit: I see them on banlist, so that's not the case, I don't have any other ideas what could cause the issue

Friendica Support reshared this.

in reply to xy..

Thanks for your answer. The worker queue is not very full. maybe <100 entries or so.. I thought maybe, because I use categories on my profile.. but why the network is slow then. strange
in reply to xy..

@xy.. I also use categories without any issues. I would check if there aren't any CPU load spikes on some process (I can imagine for example database being slow for some reason)
@xy..

Friendica Support reshared this.

in reply to xy..

what I often see, are these messages:
2023-11-21T02:33:50Z worker [ALERT]: Fatal Error (E_ERROR): Allowed memory size of 536870912 bytes exhausted (tried to allocate 96485376 bytes) {"code":1,"message":"Allowed memory size of 536870912 bytes exhausted (tried to allocate 96485376 bytes)","file":"/var/www/localhost/friendica/src/Database/Database.php","line":568,"trace":null} - {"file":null,"line":null,"function":null,"request-id":"655c16e7cbedf","stack":"ErrorHandler::handleFatalError","uid":"52404b","process_id":29538}

2023-11-21T02:39:21Z worker [ALERT]: Fatal Error (E_ERROR): gd-webp cannot allocate temporary buffer {"code":1,"message":"gd-webp cannot allocate temporary buffer","file":"/var/www/localhost/friendica/src/Object/Image.php","line":171,"trace":null} - {"file":null,"line":null,"function":null,"request-id":"655c185668e5e","stack":"ErrorHandler::handleFatalError","uid":"343130","process_id":29745}

but I have already opened an issue on github: github.com/friendica/friendica…
in reply to xy..

and in mytop there is a point slow: 225.0 . I don't know what exactly it means but its a high number (?) slow queries somehow
in reply to xy..

example for what I believe is a slow query:
9138   amical       localhost    amical  230.6   0.0  Query    Sending data SELECT `id`, `url`, `nurl`, `network`, `poco`, `directory-type` FROM `gserver` WHERE (NOT `blocked` AND NOT `failed` AND `directory-type` != 0 AND `last_p

maybe someone knows what that is
in reply to xy..

I often see "gserver" there in mytop
10198   amical       localhost    amical  225.8   0.0  Query    Sending data SELECT `url`, `nurl` FROM `gserver` WHERE (NOT `blocked` AND `next_contact` < '2023-11-21 17

10302   amical       localhost    amical  156.3   0.0  Query    Sending data SELECT `id`, `url`, `nurl`, `network`, `poco`, `directory-type` FROM `gserver` WHERE (NOT `b
in reply to xy..

currently it's a bit faster, I have done a mysqlcheck and restartet mariadb.
in reply to xy..

I don't see a difference. On my instance profile loads instantly (1-2 sec), on your site it was like 30 sec or so

Friendica Support reshared this.

in reply to xy..

I hope that maybe some developer joins the thread . maybe its something with the database. I don't know
in reply to xy..

Activate the rendertime addon:

Then you will see data like this:

in reply to Michael 🇺🇦

@Michael Vogel I think you missed my answer, because I have again answered false, not directly @ you..
Can you please have a look? below this comment
in reply to xy..

Thanks! This is an example from this page: boerdica.de/profile/noidea
It seems one query takes longer..
Post::select (216), Conversations::content (93), Index::content (250), BaseModule::run (711): 14.44
Do you have an idea what to do next?


Datenbank: 21.32/0, Netzwerk: 0, Darstellung: 0.2, Sitzung: 0, I/O: 0.01, Sonstiges: 0.32, Gesamt: 21.85
Class-Init: 0.076, Boot: 0.022, Init: 0, Inhalt: 21.746, Sonstiges: 0.005, Gesamt: 21.849

Database Read:
DBA::selectFirst (515), User::getOwnerDataByNick (223), Profile::load (89), Conversations::content (93): 0.014
DBA::selectFirst (2135), Contact::getAvatarUrlForId (453), Profile::getVCardHtml (262), Profile::load (89): 0.018
Database::update (126), DatabaseCache::set (464), Widget::postedByYear (150), Conversations::content (93): 0.073
DBA::selectToArray (107), Category::getArray (343), Widget::categories (151), Conversations::content (93): 0.168
Contact::selectToArray (162), ACL::getContactListByUserId (304), ACL::getFullSelectorHTML (160), Conversations::content (93): 0.801
DBA::selectToArray (58), Circle::getByUserId (208), ACL::getCircleListByUserId (306), ACL::getFullSelectorHTML (160): 0.095
Post::select (216), Conversations::content (93), Index::content (250), BaseModule::run (711): 14.44
DBA::p (1073), Conversation::getEmojis (894), Conversation::addChildren (506), Conversation::render (243): 0.731
Post::select (917), Conversation::addChildren (506), Conversation::render (243), Conversations::content (93): 0.323
Post::select (928), Conversation::addChildren (506), Conversation::render (243), Conversations::content (93): 1.339
DBA::selectFirst (274), Contact::getById (742), Conversation::addRowInformation (972), Conversation::addChildren (506): 0.018
Post::select (977), Conversation::addChildren (506), Conversation::render (243), Conversations::content (93): 0.052
DBA::selectFirst (109), ThreadUser::getIgnored (378), Post::getTemplateData (204), Thread::getTemplateData (687): 0.03
DBA::selectToArray (477), Tag::getByURIId (1076), Post::getDefaultText (1128), Post::getCommentBox (438): 0.92
DBA::select (541), Tag::populateFromItem (3223), Item::prepareBody (449), Post::getTemplateData (204): 0.37
DBA::selectToArray (789), Media::getByURIId (3255), Item::prepareBody (449), Post::getTemplateData (204): 0.415
Database::selectToArray (44), PostMedia::_select (61), PostMedia::selectByUriId (123), PostMedia::splitAttachments (3298): 0.021
DBA::select (541), Tag::populateFromItem (480), Post::getTemplateData (204), Thread::getTemplateData (687): 0.043
DBA::selectFirst (398), Item::photoMenu (556), Post::getTemplateData (204), Thread::getTemplateData (687): 0.264
DBA::selectFirst (158), ContactSelector::networkToName (614), Post::getTemplateData (204), Thread::getTemplateData (687): 0.012
DBA::selectFirst (353), Contact::getByURL (1083), Post::getDefaultText (1128), Post::getCommentBox (438): 0.015
DBA::selectFirst (559), Contact::getBasepath (598), Contact::isLocal (375), Contact::getByURL (1083): 0.012
DBA::select (541), Tag::populateFromItem (3223), Item::prepareBody (449), Post::getTemplateData (646): 0.04
DBA::selectToArray (789), Media::getByURIId (3255), Item::prepareBody (449), Post::getTemplateData (646): 0.269
DBA::select (541), Tag::populateFromItem (480), Post::getTemplateData (646), Post::getTemplateData (204): 0.021
DBA::selectFirst (398), Item::photoMenu (556), Post::getTemplateData (646), Post::getTemplateData (204): 0.069
DBA::selectToArray (131), Category::getArrayByURIId (142), Item::determineCategoriesTerms (451), Post::getTemplateData (204): 0.149
DBA::selectToArray (131), Category::getArrayByURIId (163), Item::determineCategoriesTerms (451), Post::getTemplateData (204): 0.015
Post::selectFirst (734), Item::getSharedPost (3246), Item::prepareBody (449), Post::getTemplateData (204): 0.314
Database::selectToArray (44), PostMedia::_select (61), PostMedia::selectByUriId (123), PostMedia::splitAttachments (3291): 0.116
DBA::selectFirst (365), Contact::getByURL (1083), Post::getDefaultText (1128), Post::getCommentBox (438): 0.066

Database Write:

Cache Read:

Cache Write:

Network:

Rendering:
BBCode::convert (1279), BBCode::convertForUriId (446), Profile::getVCardHtml (262), Profile::load (89): 0.038
Conversation::Friendica\Content\{closure}, array_filter (1232), Conversation::smartFlattenConversation (1326), Conversation::convSort (1039): 0.021
Item::photoMenu (556), Post::getTemplateData (204), Thread::getTemplateData (687), Conversation::getThreadList (585): 0.012
BBCode::convertAttachment (3721), Item::addLinkAttachment (3369), Item::prepareBody (449), Post::getTemplateData (204): 0.041
Renderer::replaceMacros (594), Conversation::render (243), Conversations::content (93), Index::content (250): 0.018
in reply to xy..

Okay, so the problem is the database server. You can add these lines to the config to exactly see the slow queries:
		'db_log' => '/path/to/logs/friendica-db.log',
		'db_loglimit' => 2,
		'db_callstack' => true,

You will have to have a look at your database server configuration. Possibly you can assign more memory to the database server. Please have got a look at some guides out there in the internet concerning database performance improvements.
in reply to Michael 🇺🇦

@Michael Vogel .. my mariadb is in fact completely on default values. I haven't changed anything. Now I have started and set innodb_buffer_pool_size to 6G (from the 128M default)
in reply to Michael 🇺🇦

@Michael Vogel .. so, I have done this. it seems these queries appear quite often in the db-log file:

2023-11-24 09:28:18     14.916  Database.php    1569    count   /*DBA::count (53), UpdateGServers::execute, Worker::execFunction (386), Worker::execute (121) */ SELECT COUNT(*) AS `count` FROM `gserver` WHERE (NOT `blocked` AND `next_contact` < '2023-11-24 09:28:03' AND (`nurl` != '' OR `url` != ''))

2023-11-24 09:29:39     80.828  DBA.php 494     select  /*DBA::select (56), UpdateGServers::execute, Worker::execFunction (386), Worker::execute (121) */ SELECT `url`, `nurl` FROM `gserver` WHERE (NOT `blocked` AND `next_contact` < '2023-11-24 09:28:03' AND (`nurl` != '' OR `url` != '')) LIMIT 100

2023-11-24 09:34:02     11.093  Database.php    1569    count   /*DBA::count (51), UpdateGServers::execute, Worker::execFunction (386), Worker::execute (121) */ SELECT COUNT(*) AS `count` FROM `gserver` WHERE (1)

2023-11-24 09:34:15     23.432  DBA.php 494     select  /*DBA::select (2391), GServer::discover (38), UpdateServerDirectories::execute, Worker::execFunction (386) */ SELECT `id`, `url`, `nurl`, `network`, `poco`, `directory-type` FROM `gserver` WHERE (NOT `blocked` AND NOT `failed` AND `directory-type` != 0 AND `last_poco_query` < '2023-11-17T09:33:51+00:00') ORDER BY RAND()

seems to be FROM gserver in each query