Projekt

Obecné

Profil

Akce

Podání #38974

otevřený

Slabiny Mraku

Přidáno uživatelem Mikuláš Ferjenčík před 4 měsíc(ů). Aktualizováno před 4 měsíc(ů).

Stav:
V řešení (diskutuje se)
Priorita:
Normální
Přiřazeno:
Kategorie:
-
Začátek:
04.04.2022
Uzavřít do:
% Hotovo:

50%

Odhadovaná doba:

Popis

Proti Google dokumentům se Mrak načítá řádově pomaleji a není optimalizován pro práci v mobilu. Bylo by možné to řešit? Jinak budou lidé se zájmem o sdílení dokumentů s kolegy i nadále používat Google drive.

děkuji

Aktualizováno uživatelem Jan Hamal Dvořák před 4 měsíc(ů)

  • % Hotovo změněn z 0 na 10
  • Přiřazeno nastaven na Andrej Ramašeuski
  • Stav změněn z Nový na V řešení (diskutuje se)

Ano, bylo. Prosím o zajištění odpovídajícího rozpočtu na rozvoj OSS evropského významu poměrný částkám vynakládaným státem na rozvoj MS Office 365 a Google Docs. Pevně věřím, že peníze na to ve státním rozpočtu a fondech soudržnosti EU najdeme poměrně snadno. Jsem si jistý, že pro dosažení významného pokroku bude stačit setina ročních nákladů na alternativy. /s

Andreji, pozoruji to už déle; klient stahuje hrozně moc malých skriptů a CSS souborů. Asi s tím nic neuděláme, protože velká část jsou individuální české překlady různých rozšíření. Při typickém načtení stránky musí prohlížeč stáhnout desítky malých souborů. Mají v URL cache-busting v=XXXX tag a Cache-Control: max-age=TTTT, což ale nezabrání RCWN a revalidaci. Náš server z nějakého důvodu odpovídá po HTTP/1.1, takže ty požadavky nejsou ani moc paralelní.

Co kdybychom nějak po cestě, pro všechny assety, které mají v max-age a .js?v= nebo .css?v= v adrese přidali k Cache-Control: max-age=TTTT, immutable, aby to šlo vždycky z disku? Mělo by to prohlížečům vysvětlit, že se fakt nemusí po každé ptát na tytéž soubory a čekat s jejich spuštěním, než dorazí přes síť.

(Immutable znamená, že po dobu max-age se nemá ptát, opravdu se nezmění.)

Aktualizováno uživatelem Jan Hamal Dvořák před 4 měsíc(ů)

Co se týče práce z telefonu, je k dispozici i mobilní aplikace, která bude určitě lepší než webové rozhraní.
Určitě ale také nebude dokonalá.

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

nahodou, v telefonu, v aplikaci, krasne pracuje i onlyoffice

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

  • % Hotovo změněn z 10 na 30

Jan Hamal Dvořák napsal (#note-1):

Co kdybychom nějak po cestě, pro všechny assety, které mají v max-age a .js?v= nebo .css?v= v adrese přidali k Cache-Control: max-age=TTTT, immutable, aby to šlo vždycky z disku? Mělo by to prohlížečům vysvětlit, že se fakt nemusí po každé ptát na tytéž soubory a čekat s jejich spuštěním, než dorazí přes síť.

http/2 uz je zapnuty. to by mohlo pomoct. a ty assety o kterych pises, JDOU z disku, na ne se nepta

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

Po upgradu v novem .htaccess immutable uz je:

  <FilesMatch "\.(css|js|svg|gif|png|jpg|ico|wasm|tflite)(\?v=.*)?$">
    Header set Cache-Control "max-age=15778463, immutable"
  </FilesMatch>

Aktualizováno uživatelem Jan Hamal Dvořák před 4 měsíc(ů)

Díky, u mě to je rozdíl cca 1s načtení /files/.

Další postřehy:

  1. cron.php nestíhá doběhnout ve vymezeném čase. Běží klidně 45 minut. Dohromady ~2x 33% CPU. Asi bychom měli zjistit co dělá tak dlouho a pokud je to nevyhnutelné, tak nestartovat tolik paralelně, ale dát větší rozestupy.

  2. Těch jader je tam opravdu hodně málo. Rozhodně bych tady nešetřil, na hypervizorech máme zrovna jader dost. Viděl bych to na 8 jader a 16 procesů apache.

Každopádně aktuální latence odpovědi na /files/ je >500ms, což je prostě příliš. Potřebujeme se dostat na desetinu. :-\

Aktualizováno uživatelem Jan Hamal Dvořák před 4 měsíc(ů)

Hmm, našel jsem další problém:

Máme ukrutně malý DB pool. Na pg vidím 5 spojení, ale když rozkliknu /files/, tak se naváže dalších 5 nových. Po načtení se hned zavřou. Je potřeba tam dát aspoň 20 trvalých spojení. Nicméně PHP mi přijde správně nastavené, tak nevím kde se to bere.

Asi bych nasadil pgBouncer na serveru nextcloud:

pool_mode = session
server_reset_query = DISCARD ALL
max_client_conn = 100
max_db_connections = 30
default_pool_size = 20
min_pool_size = 5

Přibližně.

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

  • % Hotovo změněn z 30 na 40
max_connections = 200
shared_buffers = 1536MB
effective_cache_size = 4608MB
maintenance_work_mem = 384MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2621kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 6
max_parallel_workers_per_gather = 3
max_parallel_workers = 6
max_parallel_maintenance_workers = 3

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

  • % Hotovo změněn z 40 na 50

OIDC je teoreticky funkcni. Nicmene, pravdepodobne zpusobuje odhlaseni desktopovych klientu, nekdy se vubec neprihlasuje a jine problemy.

Aktualizováno uživatelem Andrej Ramašeuski před 4 měsíc(ů)

Akce

Také k dispozici: Atom PDF