Podání #38974
uzavřený
Slabiny Mraku
100%
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 více než 2 roky(ů)
- Stav změněn z Nový na V řešení (diskutuje se)
- Přiřazeno nastaven na Andrej Ramašeuski
- % Hotovo změněn z 0 na 10
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 více než 2 roky(ů)
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 více než 2 roky(ů)
nahodou, v telefonu, v aplikaci, krasne pracuje i onlyoffice
Aktualizováno uživatelem Andrej Ramašeuski před více než 2 roky(ů)
- % 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-agea.js?v=nebo.css?v=v adrese přidali kCache-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 více než 2 roky(ů)
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 více než 2 roky(ů)
Díky, u mě to je rozdíl cca 1s načtení /files/.
Další postřehy:
cron.phpnestí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.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 více než 2 roky(ů)
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 více než 2 roky(ů)
- % 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 více než 2 roky(ů)
- % 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 více než 2 roky(ů)
spravny oidc plugin - https://apps.nextcloud.com/apps/user_oidc
Aktualizováno uživatelem Andrej Ramašeuski před více než 1 rok
- Stav změněn z V řešení (diskutuje se) na Dokončen
- % Hotovo změněn z 50 na 100
Optimalizace dokoncena
Aktualizováno uživatelem Andrej Ramašeuski před více než 1 rok
- Projekt změněn z Technický odbor na Údržba a provoz