Sahana + SAMBRO - Dlouhé odezvy, obecně nízký výkon #223
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#223
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sahana Docker image nepoužívá uwsgi pro běh pythonovské aplikce a nepoužívá nginx pro obsluhu statických souborů. Místo toho vše žene přes builtin web2py server, který umí v jeden čas zpracovávat pouze jediné vlákno a je výkonnostně suboptimální.
closed via commit
f260971661@Podhorecky: Překopal jsem middleware stack pro Sahanu + SAMBRO. Na své straně registruju znatelné snížení časů potřebných k načítání stránek. Zároveň je také možno nechat zpracovávat více požadavků paralelně bez toho, aniž by ten nejpomalejší brzdil všechny ostatní. Snad to bude trochu poznat i na vašem šlapacím internetu.
skvělá zpráva, díky. Pokusím se ověřit. (Jsem dlouhodobě trenovaný na opravdu mizerný internet, takže pokud spatřím něco rychlejšího, tak mne to zaujme :)
Celkově vnímám lehce živější načítání stran, víc bohužel z netu nevyloudim.
U načítání dat do mapy (Hasiči) je mapa opět přehlcena množstvím mapových bodů a tudíž Sahana snaživě hlásí, že neukáže vůbec nic.
Tohle vnímám jako hlubší problém Sahany, za což asi vy ani webserver nemůžete.
Jen bych hrozně rád dotlačil F+D k přiznání, že to je issue a že by to mělo být řešeno.
changed milestone to %2
zrovna dneska je samotný pohyb po portálu GitLab tak strašný, že načíst stranu trvá třeba 10-15 sekund. Taky jiné servery měly problém s odezvami, já fakt nevim co je za problém a jestli soused začal stahovat porno ve 4K, ale tenhle Internet 2.0 mě občas spouští hysterický smích.
pardon...
U GitLabu bych se opravdu divil, kdyby bylo zpomalení na mé straně, protože ten sedí v Německu na páteřní síti s konektivitou 2,76 Tbps :)
Množství mapových bodů jsme řešili v #89. Ty opravdu fungují tak, že se ze serveru načtou informace o všech těch deseti tisících bodech a do blobů se sloučí až u klienta. Drtivá většina mapových akcí se odehrává až u klienta a server jen poskytuje data pro JavaScript. Řešením by bylo snížit počet zobrazovaných bodů zpět k blízkosti výchozích hodnot, nicméně to by se zase vynořil problém s tím, že by se u některých zoom levelů nenačetly body všechny. Myslím, že dotlačit F+B k přiznání, že to je issue půjde, ale už zdaleka tak snadno nepůjde s tím něco udělat, protože jednak to je opět featura OpenLayers, jejichž úprava vyžaduje rozsáhlé změny a jednak Vám řeknou, že řešíme edge case, protože nikdo normální v mapě deset tisíc bodů nemá.
jasně že F+D vědí o problému víc než kdokoliv jiný, ale připadá mi, že dokud jim to někdo nenapíše, tak OL budou pořád odkládat. Podobně jako to bylo se stránkováním Organizací na Homepage.
Když jela v CR KMČ http://img2.ct24.cz/multimedia/documents/33/3300/329977.pdf tak nasbírali do Ushahidi desetitisíce bodů během pár hodin. Není to sice Sahana, ale já už nevím jak líp doložit, že uživatele příčina problémů vesměs nezajímá :)