!Friendica Admins

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.

!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

!friendica.me

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

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.

!Friendica Developers

@Hypolite Petovan already fixed a current JSON-LD issue with git.friendi.ca/friendica/php-j…

Do we need a 1.1.2 release to upgrade it in the Friendica composer.lock file as well?

The logs of my instances are flooded with this error, that's why I'm asking *g*

Add support for local files for unsecured document loading

- $http_response_header isn't set in the local file read case Address https://github.com/friendica/friendica/issues/12728#issuecomment-1407623586

^Friendica

!Friendica Developers

I'm currently reducing the whole BaseUrl.php code massively.
Do we really need the ssl_policy, urlpath and hostname separate from the system.url?

I will use for the BaseUrl.php, based on the system.url a "real" UriInterface as $this->url, so we don't need saving the scheme, urlpath and hostname separately anymore. They are just useful for the install process but must not be changed afterwards.

The only thing, which I'm unsure is the ssl_policy, because if someone changes it afterwards in the admin site, all URL in all contacts and photos will get updated. But the question is => is this even allowed? I think this could brick the access over federation because the base-url of each entry isn't right anymore. And it isn't supported when the policy is changed by console.

So I would drop it as well and merge all config entries into the system.url.

Additionally, I will replace the Exception with a "CRITICAL" log entry to avoid a WSOD.

!friendica.me , !Opensocial.at

I do have to restart the Database instances because they are too resource hungry.

There's a short downtime possible.

!Friendica Support

It seems like I do have a problem with my opensocial.at database .

The database ran full about a year ago (what a shame, I know :( ...) and I had to recover some of the data (otherwise I had to import a backup about ~12hours ago, I tried to avoid to loose posts for this period of time for my users ...). So I stopped it, started it with innodb_force_recovery=3, repaired it and checked it with mysqlcheck.

Two days ago, I updated the mariadb from 1.10.3 to 1.10.10 and now the problems occur again.

I stopped the MariaDB 1.10.3 container, updated it to 1.10.10 and started it again .. And MariaDB started a "crash recovery". I really don't know why... The crash recovery wasn't successfully (I tried it ~4 times), so I had to add innodb_force_recovery=3 again.

Now the database went up, but everytime I stopped it and started it again, the crash recovery appears again.

So after the instance was up and running, I dumped the whole database with mysqldump into one single *.sql , started a brand new MariaDB 1.10.10 and imported the dump again.

So far so good ..

But... unfortunately, after a restart, the crash recovery appears again. So I'm totally lost, what's now happening..

I noticed during the import that one batch of rows took about 2 hours to complete with the result query affected 0 rows.

here's my customized.cnf, which I'm using (it's a Hetzner root server with 64 GB RAM and 12 CPUs):

[mysqld]
query_cache_size = 0
query_cache_type = 0
performance_schema = ON
join_buffer_size = 140M
innodb_buffer_pool_size = 12G
innodb_log_buffer_size = 31M
innodb_log_file_size = 3G
table_open_cache = 1000
max_connections = 400
wait_timeout = 200
interactive_timeout = 4000

log-bin = mysqld-bin
transaction-isolation = READ-COMMITTED
binlog-format = ROW
skip-innodb-read-only-compressed = ON
innodb_read_only_compressed = OFF
innodb_use_native_aio = OFF

innodb_fast_shutdown=0
innodb_max_dirty_pages_pct=0
innodb_buffer_pool_dump_at_shutdown=1
innodb_buffer_pool_load_at_startup=1

For the new MariaDB instance, I didn't add any customization to avoid any wrong options.

currently, it makes a recovery again:

db_1     | 2022-12-16 10:41:00 0 [Note] InnoDB: Rolled back recovered transaction 371172                                                                                                                                                                                                    
db_1     | 2022-12-16 10:41:11 0 [Note] InnoDB: To roll back: 1 transactions, 7611737 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:41:26 0 [Note] InnoDB: To roll back: 1 transactions, 7608132 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:41:41 0 [Note] InnoDB: To roll back: 1 transactions, 7603940 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:41:46 0 [Note] DDL_LOG: Crash recovery executed 1 entries                                                                                                                                                                                                          
db_1     | 2022-12-16 10:41:46 0 [Note] Server socket created on IP: '0.0.0.0'.                                                                                                                                                                                                             
db_1     | 2022-12-16 10:41:46 0 [Note] Server socket created on IP: '::'.                                                                                                                                                                                                                  
db_1     | 2022-12-16 10:41:47 0 [Note] mariadbd: ready for connections.                                                                                                                                                                                                                    
db_1     | Version: '10.10.2-MariaDB-1:10.10.2+maria~ubu2204'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution                                                                                                                                               
db_1     | 2022-12-16 10:41:56 0 [Note] InnoDB: To roll back: 1 transactions, 7601453 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:42:11 0 [Note] InnoDB: To roll back: 1 transactions, 7600146 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:42:26 0 [Note] InnoDB: To roll back: 1 transactions, 7598395 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:42:41 0 [Note] InnoDB: To roll back: 1 transactions, 7595967 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:42:56 0 [Note] InnoDB: To roll back: 1 transactions, 7594000 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:43:11 0 [Note] InnoDB: To roll back: 1 transactions, 7590646 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:43:26 0 [Note] InnoDB: To roll back: 1 transactions, 7585618 rows                                                                                                                                                                                                  
db_1     | 2022-12-16 10:43:41 0 [Note] InnoDB: To roll back: 1 transactions, 7579929 rows
db_1     | 2022-12-16 10:43:56 0 [Note] InnoDB: To roll back: 1 transactions, 7574058 rows
db_1     | 2022-12-16 10:44:11 0 [Note] InnoDB: To roll back: 1 transactions, 7568214 rows

!Friendica Developers

@Michael Vogel - I'm currently moving the mod/display.php

As far as I can see, there are two main-routes for this controller:

• /display/{guid}
• /display/feed-item/{uri-id}.atom[/conversation.atom]

and as far as I can say, it would be better if the second route should have an own root, like `dfrn_item/{uri-id}[/conversation.atom`, as it's a DFRN only logic.
Am I right so far?

If so, can I move it to this new path or is this path necessary for the federation usage, means it could be called from other servers too?
I just found calls with prefix DI::baseUrl(), so I guess it's "just" for the server itself, but I'm not sure ...

!Friendica Developers

And another question

Currently, we strictly separate between API calls and the Frontend.
But, Why?

I'm currently moving the events to the Module directory.
And there's already an API for it, but as far as I understand @Michael Vogel , we must not mix API and Frontend.

But as far as I know, in modern environments, there's a backend part (= API), and a frontend part (= view)
The own frontend still uses the same API. So we don't have to implement the same business logic at different places. As I said, I came across at Event, where this issue produces significant double-code.

So at least what I would like (in a final state :

• API ... Create, Update, Delete, Get, GetMultiple for our Data model, or "everything without HTML output"
• Module ... Everything, which produces HTML output

I know, this would be a BIG change

!Friendica Developers

So this are my first thoughs about the Addons:

• Metadata about each add-on should be in an extra file, I would prefer something like addon.json
• I would like to replace the whole Hook class with a proper Registration class, which is loaded when activating the Add-on. So we can remove the whole Hook table.
• All Events in Friendica should be in an events.config.php with a proper description (maybe as constants?)
• for legacy purpose, I would create a wrapper class like the LegacyModule class, which would execute the corresponding php-functions
• I'm thinking about a giving each Event a specific interface (not knowing how tbh currently, maybe the corresponding interface setting as a value for the Event inside the events.config.php?), so each event and each add-on will know exactly what parameters and which result is necessary

This is it so far..

I would like to start with creating the events.config.php and replace all text with constants.. I think this is a non invasive behaviour, but gives some insights about the next steps

!Friendica Developers

Based on the PR github.com/friendica/friendica…

@Hypolite Petovan is right, I should have started this conversation first, but it made fun to restructure our code, so it is what it is *gg*

What's the issue/my pain:

I'm thinking about introducing the PSR-7 Request/Response interfaces and create an Emitter, so there's no way out anymore directly inside the code, everything is done by the emitter. With this pattern, we could add all the authentication stuff inside a "Middleware" and get rid of the different auth-places (App, Security\Authentication, Module\BaseApi)

So, now I tried to think where to start. We would need a Middleware directory for all the auth/base-load things, but we already do have a mix of domain-based directories (TowFactorAuth), functionallity based directories (Model/Object/Factory/Collection/Capabilities) and and core directories (Core, App, Console, Worker)...

And I try to start to "really" encapsulate the domain-based directories inside Friendica\Library, so we get rid of some mixings, having all domain based classes inside one directory.

In the end, I think we should have some core directories at src, directing everyone to the right place.

I hope I didn't loose you at least, I just wrote down my path to this PR :)

PS: there're "just" ~200 code changes, the rest is because of the messages.po recreation don't worry :)

Restructure Friendica Base by nupplaphil · Pull Request #12075 · friendica/friendica

I always struggle with our codebase about where to find what content .. Because we moved from pattern to pattern, we left a lot of leftovers in our codebase. This PR should restructure our codebase...

^GitHub