[Dutch] Geoserver vraag ..

Vr Dec 14 05:51:30 PST 2012

Nee, die staat gewoon op 0, want weet niet zeker of dit dus invloed op
heeft.
Maar zal volgende week eens proberen of het invloed heeft.

Grt,

Richard

Op 14 december 2012 13:32 schreef Bart van den Eijnden
<bartvde op osgis.nl>het volgende:

> Hoi Richard,
>
> ik vraag me af of de feature type cache grootte hierop van invloed is. Heb
> je die ook op 1200 staan?
>
> Groeten,
> Bart
>
> --
> Bart van den Eijnden
> OSGIS - http://osgis.nl
>
> On Dec 14, 2012, at 1:29 PM, Richard de Bruin <rr.debruin op gmail.com>
> wrote:
>
> Hoi Milo,
>
> Bedankt voor je antwoord.
>
> Maar bij het opstarten hebben we er geen 'last' van, dit gaat gewoon snel
> en dan controleert hij ook alle lagen.
> Pas bij een WFS request (en dan ook alleen een soort van zoek actie) treed
> het op. Dan gaat Geoserver alle layers op geometry checken
> ook al heb je in de WFS request gewoon de laag staan waar het om draait.
> Alle requesten daarna gaan wel snel en wordt de check niet uitgevoerd tot
> het moment denk ik dat de cahce leeg is, of Tomcat herstart of
> Geoserver reload. Is dus ook alleen maar van toepassing bij Oracle Spatial
> lagen.
> Dus ik hoop dat iemand van deze lijst hier ook al eens mee te maken heeft
> gehad.
>
>
> Bijv dit request:
>
> <wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://www.opengis.net/wfs"
>   xmlns:gml="http://www.opengis.net/gml" xmlns:wfs="
> http://www.opengis.net/wfs"
>   xmlns:ogc="http://www.opengis.net/ogc" service="WFS" version="1.0.0">
>   <wfs:Query typeName="geo:EXT.RO_HIST_IBISBEDRIJVEN2006_V">
>   <wfs:PropertyName>PLANNAAM</wfs:PropertyName>
>     <ogc:Filter>
> <ogc:And>
>  <ogc:BBOX>
>         <ogc:PropertyName>SHAPE</ogc:PropertyName>
>         <gml:Box srsName="EPSG:28992">
>           <gml:coordinates>202000,512000 271000,581300</gml:coordinates>
>         </gml:Box>
>       </ogc:BBOX>
>   <ogc:PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
>  <ogc:PropertyName>
> PLANNAAM
> </ogc:PropertyName>
>  <ogc:Literal>
> *hanekampen*
> </ogc:Literal>
>  </ogc:PropertyIsLike>
>   </ogc:And>
>     </ogc:Filter>
>   </wfs:Query>
> </wfs:GetFeature>
>
>
> Op 14 december 2012 12:29 schreef Milo van der Linden <milo op dogodigi.net>het volgende:
>
>> Bij geoserver 2.1.4 gebeurt het ook bij het opstarten. Bij het opnieuw
>> starten en bij het opnieuw laden van de geoserver configuratie (nadat je
>> wijzigingen hebt doorgevoerd in SLD's, Stores, etc.)
>>
>> Met zoveel lagen is het een feit dat het lang duurt voor geoserver is
>> gestart. In die zin zou ik de momenten om mijn productieserver te
>> herstarten dus goed timen ;-)
>>
>> Deze manier van opstarten is inherent aan geoserver. Het eenmalig checken
>> van de lagen bij opstarten MOET in mijn ogen dan ook worden uitgevoerd
>> zodat geoserver niet in een later stadium onderuit klapt als er iets niet
>> zou kloppen.
>>
>>
>> Checklist:
>>
>> - Je hebt veel lagen. Eventueel zou je kunnen proberen het aantal lagen
>> terug te brengen.
>> - Ik weet niet of je Oracle database op dezelfde server draait, op een
>> SAN, op een server op een andere lokatie; al deze zaken zijn relevant voor
>> de opstarttijd en uiteraard ook gewoon voor de algehele werking van
>> Geoserver. Zorg dat de toegang tot je database (netwerk of schijfsnelheid)
>> zo optimaal mogelijk is
>> - Zorg dat je Oracle database perfect getuned is. Hoe? Weet ik niet, ik
>> houd me op dit vlak alleen bezig met postgresql. Maar ik weet bijvoorbeeld
>> dat het bij Postgresql een enorme boost geeft als je zoveel intern geheugen
>> hebt dat je database bijna compleet uit RAM zou kunnen draaien.
>> - Optimaliseer de "Container" waarbinnen geoserver draait (tomcat/jetty
>> etc.) hier vind je een stuk uitleg en onderaan die pagina een link naar nog
>> meer performance tips:
>> http://docs.geoserver.org/stable/en/user/production/container.html
>>
>> Nogmaals, de opstartcheck is essentieel. En hoort zo. Ook als je in
>> geoserver de configuraties herlaadt worden deze checks (niet altijd
>> volledig) nog een keer uitgevoerd. Al met al is het checken van een laag
>> wanneer je 1200 lagen hebt en zegt dat dit 30 minuten duurt een proces dat
>> bij jou dus ongeveer 40 seconden per laag duurt. En dat valt best mee als
>> je in ogenschouw neemt dat een verbinding met een db moet worden opgebouwd,
>> data moet worden binnengeharkt en geanalyseerd etc.
>>
>> Ook zou ik je aanraden om een ontwikkelserver naast je productieserver te
>> houden. Als je namelijk nieuwe rendering, boundingbox berekeningen, het
>> opnieuw laden van de gegevenstabel etc. op de productieserver uitvoert, dan
>> loop je het risico dat je zo'n checkproces start. En daar worden de
>> gebruikers niet blij van... Dus: Eerst alle styling etc. testen op een
>> ontwikkelmachine, daarna in bulk naar productie zetten.
>>
>> Ik wens je geluk!
>>
>> Milo
>>
>>
>>
>>
>>
>> Op 14 december 2012 08:45 schreef Richard de Bruin <rr.debruin op gmail.com>het volgende:
>>
>>> Hoi allemaal,
>>>
>>> Misschien is dit niet de lijst om deze vraag te stellen, maar ik weet
>>> dat een
>>> aantal van jullie ervaring hebben met Geoserver.
>>>
>>> We zitten met een 'probleem' (of meer een rarigheid).
>>> We maken gebruik van Geoserver 2.1.4 en op het moment dat we vanuit
>>> Flamingo MC
>>> (en waarschijnlijk ook een ander WFS request doen) gaat Geoserver alle
>>> layers checken
>>> op geometrie.
>>> We maken gebruik van Oracle spatial en hier treed dit dan eenmalig op?
>>> (cache??). Dan gaat
>>> het een tijdje goed totdat je bijv. Geoserver reload of Tomcat herstart.
>>> Op zich is het niet zo erg, alleen het duurt ongeveer een half uur tot
>>> drie kwartier (bijna 1200 layers). En dan reageert Geoserver bijna niet
>>> meer.
>>>
>>> Iemand hier ervaring mee gehad? Of weet iemand een oplossing?
>>>
>>> Bij Geoserver 2.2.2 gebeurt dit gelijk al bij het opstarten van
>>> Geoserver. En duurt het dus een half uur voordat Geoserver in de lucht is.
>>>
>>> Wat we zelf al geprobeert hebben is gebruik te maken van een Geometry
>>> metadata table.
>>> Heeft de feature type cache size nog invloed hierop?
>>>
>>> Zie bijlage voor een stukje log.
>>>
>>> Alvast bedankt :)
>>>
>>> Grt,
>>>
>>> Richard
>>>
>>> _______________________________________________
>>> Dutch mailing list
>>> Dutch op lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/dutch
>>>
>>>
>>
> _______________________________________________
> Dutch mailing list
> Dutch op lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dutch
>
>
>
------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://lists.osgeo.org/pipermail/dutch/attachments/20121214/75acdfcd/attachment.html>