Podání #38974
uzavřený
Slabiny Mraku
Přidáno uživatelem Mikuláš Ferjenčík před asi 2 roky(ů). Aktualizováno před asi 1 rok.
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 asi 2 roky(ů)
- % 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 asi 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 asi 2 roky(ů)
nahodou, v telefonu, v aplikaci, krasne pracuje i onlyoffice
Aktualizováno uživatelem Andrej Ramašeuski před asi 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 asi 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 asi 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 asi 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 asi 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 asi 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 asi 2 roky(ů)
spravny oidc plugin - https://apps.nextcloud.com/apps/user_oidc
Aktualizováno uživatelem Andrej Ramašeuski před asi 1 rok
- % Hotovo změněn z 50 na 100
- Stav změněn z V řešení (diskutuje se) na Dokončen
Optimalizace dokoncena
Aktualizováno uživatelem Andrej Ramašeuski před asi 1 rok
- Projekt změněn z Technický odbor na Údržba a provoz