SE - config - setting #89

Closed
opened 2017-09-29 23:16:58 +02:00 by Podhorecky · 12 comments
Podhorecky commented 2017-09-29 23:16:58 +02:00 (Migrated from git.spotter.cz)

Prosím o průzkum těchto settingů, pokud ještě nebyly označeny jako nepoužitelné

https://git.spotter.cz:8443/Spotter-Cluster/Spotter-Cluster/blob/master/sahana/srv/sahana/applications/eden/models/000_config.py

moje logovací jméno

# GeoNames username
#settings.gis.geonames_username = "trendspotter"

tady asi nastavení pro mapy

# Performance Options
# Maximum number of search results for an Autocomplete Widget
#settings.search.max_results = 200
# Maximum number of features for a Map Layer
#settings.gis.max_features = 1000

tohle mě zajímá jestli s tím jde vylepšit nějaké fulltext hledání (?)

# SOLR server for Full-Text Search
#settings.base.solr_url = "http://127.0.0.1:8983/solr/"

tohle by mohlo řešit to odlogování, ne?

# Memcache server to allow sharing of sessions across instances
#settings.base.session_memcache = '127.0.0.1:11211'

další settingy ještě prozkoumám a dopíšu.

Prosím o průzkum těchto settingů, pokud ještě nebyly označeny jako nepoužitelné https://git.spotter.cz:8443/Spotter-Cluster/Spotter-Cluster/blob/master/sahana/srv/sahana/applications/eden/models/000_config.py moje logovací jméno ``` # GeoNames username #settings.gis.geonames_username = "trendspotter" ``` tady asi nastavení pro mapy ``` # Performance Options # Maximum number of search results for an Autocomplete Widget #settings.search.max_results = 200 # Maximum number of features for a Map Layer #settings.gis.max_features = 1000 ``` tohle mě zajímá jestli s tím jde vylepšit nějaké fulltext hledání (?) ``` # SOLR server for Full-Text Search #settings.base.solr_url = "http://127.0.0.1:8983/solr/" ``` tohle by mohlo řešit to odlogování, ne? ``` # Memcache server to allow sharing of sessions across instances #settings.base.session_memcache = '127.0.0.1:11211' ``` další settingy ještě prozkoumám a dopíšu.
Disassembler commented 2017-09-30 22:09:50 +02:00 (Migrated from git.spotter.cz)

GeoNames - OK, nastavím. Jen pro ujištění - rozumím tedy, že máte vytvořený účet pro webové služby na http://www.geonames.org/export/web-services.html s tímto názvem, ano?

Mapy - Výchozí hodnoty jsou settings.search.max_results = 200 a settings.gis.max_features = 2000, což mi připadá jako celkem použitelné nastavení. Jak byste je chtěl změnit?

SOLR - SOLR je indexovací systém běžící v samostatné serverové službě. Sahana podporuje pouze indexaci dokumentů (modul doc), což bylo implementováno v rámci něčího nadšení a evidentně to nikdo nepoužívá, protože ani nemůže, jelikož k tomu neexistují indexová schemata (obdoba databázových tabulek). Dají se použít výchozí, ale to pak není o moc víc efektivní než slušně optimalizovaný fulltext v databázi.

Memcache - Memcache je in-memory data store, opět běžící v samostatné serverové službě. Můžete si to představit jako jednu velkou tlustou databázovou tabulku, ke které je přistupováno výhradně skrze primární klíč. Používá se, aby se odlehčilo databázi nebo souborovému systému. U session to má smysl pokud bude aplikace používána stovkami uživatelů zároveň (v jeden čas). S tím jak Web2py se session zachází (odlogovávání) to nepomůže.

**GeoNames** - OK, nastavím. Jen pro ujištění - rozumím tedy, že máte vytvořený účet pro webové služby na <http://www.geonames.org/export/web-services.html> s tímto názvem, ano? **Mapy** - Výchozí hodnoty jsou `settings.search.max_results = 200` a `settings.gis.max_features = 2000`, což mi připadá jako celkem použitelné nastavení. Jak byste je chtěl změnit? **SOLR** - SOLR je indexovací systém běžící v samostatné serverové službě. Sahana podporuje pouze indexaci dokumentů (modul `doc`), což bylo implementováno v rámci [něčího nadšení](https://groups.google.com/forum/#!msg/sahana-eden/E0S7Hl_hjWo/kHu-ytGXgOgJ) a evidentně to nikdo nepoužívá, protože ani nemůže, jelikož k tomu neexistují indexová schemata (obdoba databázových tabulek). Dají se použít výchozí, ale to pak není o moc víc efektivní než slušně optimalizovaný fulltext v databázi. **Memcache** - Memcache je *in-memory data store*, opět běžící v samostatné serverové službě. Můžete si to představit jako jednu velkou tlustou databázovou tabulku, ke které je přistupováno výhradně skrze primární klíč. Používá se, aby se odlehčilo databázi nebo souborovému systému. U session to má smysl pokud bude aplikace používána stovkami uživatelů *zároveň* (v jeden čas). S tím jak Web2py se session zachází (odlogovávání) to nepomůže.
Podhorecky commented 2017-09-30 22:40:11 +02:00 (Migrated from git.spotter.cz)

Geonames.. ano, mám vytvořený účet s tímto loginem, heslo L0vegeonames
jsou tam k dispozici nějaké web services (neplacené a placené) a dataset PSČ
Vpodstatě bych rád věděl, zda by k něčemu pomohlo, že mají ke stažení dataset PSČ.. a co by to znamenalo, když by se tyto adresy použily lokálně v Sahana image.
Někde jsem četl, že Sahana umí detekovat adresy a pak jim podle toho přidává Lat Lon
na to je pak služba Geocoder (zapnutelná v konfiguraci mapy)
zdrojový kód tady https://github.com/alexreisner/geocoder

laicky si to představuji, že uživatel po napsání adresy do formuláře nahoře v liště v modulu Map dostane automaticky bod na mapě... (?) Což je celkem pěkná služba, pokud by nebyla závislá na externím serveru. (ještě nemluvím o mapovém podkladu, jen o vrstvě adres)

ostatní nevím..
je tam #settings.gis.max_features = 1000
vy píšete
settings.gis.max_features = 2000
nevim kde se to projeví, tak se na to ptám... asi tedy ok(?)

ad SOLR... mé dřívější nápady o Sahaně se kdysi zabývaly myšlenkou fulltextového hledání napříč celou Sahanou. na wiki sahany tam byl nějaký hrubý blueprint. Poptal jsem k tomu analýzu a návrh řešení, na což jsem dostal odpověď že to je vzhledem ke struktuře modulů a kódů velmi těžké a proto to taky v Sahaně není. Hledá se vždy jen v rámci nějaké tabulky ..ale není to napříč moduly. Pokus vytvořit fulltext hledání byl plný kompromisů, který nakonec vypadal velmi nepoužitelně.

Já jakž-takž pochopil, že to není v Sahaně zrovna atraktivní úkol. Ale vlastně jsem také pojal nedůvěru k tvrzení mr. Skřivánka, protože ve mě převážilo přesvědčení, že jeho analýza Sahany nebyla až tak zkušená, nebo prostě říkal co se hodilo jeho zaměstnavateli.
Teď po vás nechci to používat, bude mi stačit potvrdit, že to teď nemá smysl řešit, protože by to bylo moc energie a málo muziky.

hledal jsem ten úplný soubor 000_config.py ..ten je v našem repozitáři kde?

pokusím se ještě rozklíčovat některé vlastnosti. Některé funkce jsem totiž na velmi krátkou dobu viděl, když jsem vyráběl vlastní pokusy, ale pak zas mi zmizely z dohledu... Na to jsem byl krátký.

Geonames.. ano, mám vytvořený účet s tímto loginem, heslo L0vegeonames jsou tam k dispozici nějaké web services (neplacené a placené) a dataset PSČ Vpodstatě bych rád věděl, zda by k něčemu pomohlo, že mají ke stažení dataset PSČ.. a co by to znamenalo, když by se tyto adresy použily lokálně v Sahana image. Někde jsem četl, že Sahana umí detekovat adresy a pak jim podle toho přidává Lat Lon na to je pak služba Geocoder (zapnutelná v konfiguraci mapy) zdrojový kód tady https://github.com/alexreisner/geocoder laicky si to představuji, že uživatel po napsání adresy do formuláře nahoře v liště v modulu Map dostane automaticky bod na mapě... (?) Což je celkem pěkná služba, pokud by nebyla závislá na externím serveru. (ještě nemluvím o mapovém podkladu, jen o vrstvě adres) ostatní nevím.. je tam `#settings.gis.max_features = 1000` vy píšete settings.gis.max_features = 2000 nevim kde se to projeví, tak se na to ptám... asi tedy ok(?) ad SOLR... mé dřívější nápady o Sahaně se kdysi zabývaly myšlenkou fulltextového hledání napříč celou Sahanou. na wiki sahany tam byl nějaký hrubý blueprint. Poptal jsem k tomu analýzu a návrh řešení, na což jsem dostal odpověď že to je vzhledem ke struktuře modulů a kódů velmi těžké a proto to taky v Sahaně není. Hledá se vždy jen v rámci nějaké tabulky ..ale není to napříč moduly. Pokus vytvořit fulltext hledání byl plný kompromisů, který nakonec vypadal velmi nepoužitelně. Já jakž-takž pochopil, že to není v Sahaně zrovna atraktivní úkol. Ale vlastně jsem také pojal nedůvěru k tvrzení mr. Skřivánka, protože ve mě převážilo přesvědčení, že jeho analýza Sahany nebyla až tak zkušená, nebo prostě říkal co se hodilo jeho zaměstnavateli. Teď po vás nechci to používat, bude mi stačit potvrdit, že to teď nemá smysl řešit, protože by to bylo moc energie a málo muziky. hledal jsem ten úplný soubor 000_config.py ..ten je v našem repozitáři kde? pokusím se ještě rozklíčovat některé vlastnosti. Některé funkce jsem totiž na velmi krátkou dobu viděl, když jsem vyráběl vlastní pokusy, ale pak zas mi zmizely z dohledu... Na to jsem byl krátký.
Disassembler commented 2017-09-30 22:55:01 +02:00 (Migrated from git.spotter.cz)

Mapy - #settings.gis.max_features = 1000 je pouze nějaká vzorová hodnota, která je uvedena jako příklad v config.py (což je ten soubor, na který se ptáte). Výchozí hodnoty jsou v souboru s3cfg.py a tam jsou 2000. Projeví se to tak, že pokud na mapě vyzoomujete tak vysoko, že byste měl vidět více bodů než je tento limit, Sahana Vás zdrbe a ukáže jen počet prvků nastavený limitem.

SOLR - Myslím, že tohle snad ani není problém řešitelný v Sahaně. Sahan v celém tom stacku sedí strašně vysoko a ani databázi si sama nijak neřeší, protože to za ni dělá We2py framework se svou vrstvou abstrakce a objektového zpracování. Sahana tak vlastně ani neví na jaké databázi jede a je jí to úplně jedno. SOLR je svým způsobem databáze, takže taková věc by musela být řešena přímo ve Web2py.

**Mapy** - `#settings.gis.max_features = 1000` je pouze nějaká vzorová hodnota, která je uvedena jako příklad v [`config.py`](https://git.spotter.cz:8443/Spotter-Cluster/Spotter-Cluster/blob/master/sahana/srv/sahana/applications/eden/modules/templates/Spotter/config.py) (což je ten soubor, na který se ptáte). Výchozí hodnoty jsou v souboru [`s3cfg.py`](https://github.com/sahana/eden/blob/master/modules/s3cfg.py#L1312) a tam jsou 2000. Projeví se to tak, že pokud na mapě vyzoomujete tak vysoko, že byste měl vidět více bodů než je tento limit, Sahana Vás zdrbe a ukáže jen počet prvků nastavený limitem. **SOLR** - Myslím, že tohle snad ani není problém řešitelný v Sahaně. Sahan v celém tom stacku sedí strašně vysoko a ani databázi si sama nijak neřeší, protože to za ni dělá We2py framework se svou vrstvou abstrakce a objektového zpracování. Sahana tak vlastně ani neví na jaké databázi jede a je jí to úplně jedno. SOLR je svým způsobem databáze, takže taková věc by musela být řešena přímo ve Web2py.
Disassembler commented 2017-09-30 22:57:23 +02:00 (Migrated from git.spotter.cz)

mentioned in commit 768d8b9680

mentioned in commit 768d8b96808e6e8e58127294ced301c1a0f30c23
Podhorecky commented 2017-10-01 11:33:19 +02:00 (Migrated from git.spotter.cz)

super.. co se teoreticky stane, když bude hodnota #settings.gis.max_features = 8000 ? Zkolabuje to browser, budu čekat půl hodiny na načtení, nebo to zaplní paměť? Spekuluji, že tyhle limity byly nastavovány před pár lety, od té doby se dost změnilo co do výkonu. Teď jsme ve fázi experimentů, kdy potřebuji najít hranice Sahany, abych později nebyl překvapený. Nemusíte vysvětlovat, pokud to je rychlejší ověřit prakticky.

k settingům se vrátím, bude jich víc, děkuji,

super.. co se teoreticky stane, když bude hodnota #settings.gis.max_features = 8000 ? Zkolabuje to browser, budu čekat půl hodiny na načtení, nebo to zaplní paměť? Spekuluji, že tyhle limity byly nastavovány před pár lety, od té doby se dost změnilo co do výkonu. Teď jsme ve fázi experimentů, kdy potřebuji najít hranice Sahany, abych později nebyl překvapený. Nemusíte vysvětlovat, pokud to je rychlejší ověřit prakticky. k settingům se vrátím, bude jich víc, děkuji,
Disassembler commented 2017-10-01 15:02:54 +02:00 (Migrated from git.spotter.cz)

Nastaveno

settings.search.max_results = 1000
settings.gis.max_features = 10000

Očekávám nepatrně pomalejší načítání dat v důsledku zvětšení jejich objemu (na hodně pomalých internetech to bude znát víc) a delší čas potřebný k vykreslení více bodů. To už se děje na straně klienta, takže tam je to omezeno systémovými prostředky a stabilitou prohlížeče na klientské straně. Technické limity omezující množství prvků tu prakticky nejsou (resp. budou tak u milionů položek), takže jediným limitujícím faktorem je, jak dlouho je uživatel schopen čekat, než ho jeho systém opět pustí ke slovu. Případné další úpravy nebo potvrzení hodnot mi prosím dejte vědět, commitnu je.

Nastaveno ``` settings.search.max_results = 1000 settings.gis.max_features = 10000 ``` Očekávám nepatrně pomalejší načítání dat v důsledku zvětšení jejich objemu (na hodně pomalých internetech to bude znát víc) a delší čas potřebný k vykreslení více bodů. To už se děje na straně klienta, takže tam je to omezeno systémovými prostředky a stabilitou prohlížeče na klientské straně. Technické limity omezující množství prvků tu prakticky nejsou (resp. budou tak u milionů položek), takže jediným limitujícím faktorem je, jak dlouho je uživatel schopen čekat, než ho jeho systém opět pustí ke slovu. Případné další úpravy nebo potvrzení hodnot mi prosím dejte vědět, commitnu je.
Podhorecky commented 2017-10-01 17:58:03 +02:00 (Migrated from git.spotter.cz)

Díky, budu to pozorovat, doma to bylo pomalé vždycky. Teď mi příjde, že okno mapy něco načte, ale po změně zoomu už se nic nezmění, Vypadá to jako by byl nějaký timeout, možná na webserveru. Ostatní prvky stránky reagují.

Docela jsem nepochopil proč tohle jejich řešení dělá takové problémy s načítáním většího množství dat. Od toho tam přeci je to shlukování bodu, ne? Ono to čte komplet všechno? LOL, Praktická zkušenost s jinými řešeními (mapy.cz, google a jiné mapy http://spotter.cz/cz/18-mapy.htm nekolabují když mají zobrazit jedno kolečko v kterém je číslo 3194 ...
Tady by se měli chlapci ze Sahany asi zamyslet co s tím :)
(nemusíte vysvětlovat... to by asi bylo na dlouho )

Díky, budu to pozorovat, doma to bylo pomalé vždycky. Teď mi příjde, že okno mapy něco načte, ale po změně zoomu už se nic nezmění, Vypadá to jako by byl nějaký timeout, možná na webserveru. Ostatní prvky stránky reagují. Docela jsem nepochopil proč tohle jejich řešení dělá takové problémy s načítáním většího množství dat. Od toho tam přeci je to shlukování bodu, ne? Ono to čte komplet všechno? LOL, Praktická zkušenost s jinými řešeními (mapy.cz, google a jiné mapy http://spotter.cz/cz/18-mapy.htm nekolabují když mají zobrazit jedno kolečko v kterém je číslo 3194 ... Tady by se měli chlapci ze Sahany asi zamyslet co s tím :) (nemusíte vysvětlovat... to by asi bylo na dlouho )
Disassembler commented 2017-10-02 12:53:09 +02:00 (Migrated from git.spotter.cz)

mentioned in issue #100

mentioned in issue #100
Disassembler commented 2017-10-02 12:55:37 +02:00 (Migrated from git.spotter.cz)

mentioned in issue #75

mentioned in issue #75
Podhorecky commented 2018-03-14 22:45:14 +01:00 (Migrated from git.spotter.cz)

changed milestone to %2

changed milestone to %2
Disassembler commented 2018-03-15 09:08:57 +01:00 (Migrated from git.spotter.cz)

mentioned in issue #223

mentioned in issue #223
Podhorecky commented 2019-04-15 11:58:54 +02:00 (Migrated from git.spotter.cz)

closed

closed
Sign in to join this conversation.
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Disassembler/Spotter-VM#89
No description provided.