[Dutch] Geoserver vraag ..

Vr Dec 14 04:32:20 PST 2012

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/50c4e722/attachment.html>