GeoServer in Production: we do it, here is how!
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 69 | |
| Anzahl der Teile | 193 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/20401 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSS4G Bonn 201669 / 193
8
20
21
27
28
34
39
51
53
56
61
64
66
68
72
75
78
79
80
84
104
108
112
120
123
126
130
131
134
135
140
142
143
145
146
153
154
157
160
165
182
183
188
190
00:00
ElementargeometrieServerVierAppletJava EnterpriseBildverarbeitungDatenfusionVisualisierungFunktion <Mathematik>KontrollstrukturBitmap-GraphikVektorraumInhalt <Mathematik>FünfModelltheorieBeobachtungsstudieProgrammierumgebungSoftwarewartungInformationMetropolitan area networkBinärdatenVarianzSoftwarewartungInformationVerzweigendes ProgrammProgrammfehlerRechenwerkSystemprogrammierungMAPLastStabilitätstheorie <Logik>Globale OptimierungWechselsprungProgrammierumgebungLoginFormation <Mathematik>KomponententestVersionsverwaltungSoftwareentwicklerMultiplikationsoperatorBitCoxeter-GruppeDifferenteSoftwaretestTabelleTesselationMapping <Computergraphik>SoundverarbeitungFreiheitsgradProdukt <Mathematik>ClientKartesische KoordinatenInhalt <Mathematik>KontrollstrukturKonfigurationsraumKomponente <Software>URLModelltheorieResultanteGebäude <Mathematik>Zentrische StreckungBildgebendes VerfahrenMittelwertAggregatzustandObjekt <Kategorie>SchlussregelMailing-ListeQuaderOrientierung <Mathematik>SkalierbarkeitZahlenbereichInteraktives FernsehenRechter WinkelProzess <Informatik>MereologiePunktRandwertServerSpider <Programm>EinflussgrößeComputersicherheitFamilie <Mathematik>
06:19
Bitmap-GraphikEin-AusgabeAuflösung <Mathematik>Offene MengeElektronische PublikationZahlenbereichSyntaktische AnalyseKomplex <Algebra>DatenstrukturBefehlsprozessorMini-DiscHalbleiterspeicherModelltheorieDatenkompressionFormale GrammatikKonfigurationsraumElementargeometrieServerTeilmengeChecklisteNeunzehnSolitärspielASCIIROM <Informatik>Konfiguration <Informatik>DateiformatDedekind-SchnittTopologieDimensionsanalyseTesselationNotepad-ComputerSystemprogrammierungInnerer PunktWarpingBitStellenringURNManufacturing Execution SystemMosaicing <Bildverarbeitung>Einfache GenauigkeitDreiSimulated annealingSystem-on-ChipSummengleichungLASER <Mikrocomputer>Lesen <Datenverarbeitung>SchlüsselverwaltungMultiplikationsoperatorPräprozessorBitmap-GraphikPunktInverser LimesProgrammierumgebungCASE <Informatik>ModelltheorieMereologieDimensionsanalyseTermEinfache GenauigkeitMosaicing <Bildverarbeitung>ExploitDateiformatMailing-ListeDifferenteTemporale LogikInformationEin-AusgabeOrdnung <Mathematik>Globale OptimierungDatenkompressionCoxeter-GruppeBildschirmfensterFrequenzEuler-WinkelGüte der AnpassungFitnessfunktionBitrateMathematische LogikUmsetzung <Informatik>VektorraumBeobachtungsstudieGradientBildgebendes Verfahrent-TestErweiterte Realität <Informatik>
09:33
VektorraumAttributierte GrammatikBinärdatenKomplex <Algebra>Syntaktische AnalyseDatenstrukturTeilmengeChecklisteDateiformatShape <Informatik>Elektronische PublikationDatenbankServerOrakel <Informatik>VerzeichnisdienstDreiAutomatische IndexierungAbfrageEigentliche AbbildungTabelleParametersystemQuaderRechenwerkAliasingRechnernetzDedekind-SchnittDatenparallelitätZahlenbereichKonfigurationsraumTextur-MappingROM <Informatik>RenderingSchlussregelMAPSchlüsselverwaltungThumbnailLokales MinimumMaßstabAttributierte GrammatikClientMapping <Computergraphik>SoftwareEinfach zusammenhängender RaumMomentenproblemGlobale OptimierungDatenbankTouchscreenFlächeninhaltFilter <Stochastik>TermHalbleiterspeicherSkalierbarkeitProgrammierumgebungVektorraumZahlenbereichEin-AusgabeDateiformatMAPUnternehmensarchitekturBitDatensatzThreadMultiplikationsoperatorServerMereologieAutomatische IndexierungMixed RealityGamecontrollerGanze FunktionRenderingLastSchaltnetzAbfrageFormale SemantikFrequenzProxy ServerAbstandEinsCASE <Informatik>ParametersystemDatenverwaltungPunktBenutzerfreundlichkeitBasis <Mathematik>BeobachtungsstudieWhiteboardOntologie <Wissensverarbeitung>WasserdampftafelTabelleDatenstrukturElektronische PublikationShape <Informatik>Folge <Mathematik>EreignishorizontA-posteriori-WahrscheinlichkeitKartesische KoordinatenMessage-PassingComputeranimation
16:15
ServerElementargeometrieMinkowski-MetrikBetriebsmittelverwaltungVarianzVersionsverwaltungRenderingFlächentheorieROM <Informatik>Objekt <Kategorie>Gesetz <Physik>DatentypQuellcodeAutomatische IndexierungAdressierungOrdnung <Mathematik>GoogolProtokoll <Datenverarbeitungssystem>MultiplikationsoperatorZoomMAPKonfiguration <Informatik>DateiformatParametersystemGasströmungPASS <Programm>AbfrageCachingDreiMeta-TagMini-DiscSchnittmengeCOMLie-GruppeRohdatenZählenBrowserATMClientCAN-BusWeb logRechter WinkelVektorraumSpezialrechnerSolitärspielBitmap-GraphikBimodulTotal <Mathematik>TeilbarkeitCodierung <Programmierung>Elektronische PublikationTemplateGruppoidProgrammierumgebungKonfigurationsraumOperations ResearchStellenringRechnernetzSystemprogrammierungStochastische AbhängigkeitExogene VariableLastARM <Computerarchitektur>Metropolitan area networkMathematikKontrollstrukturCachingSystemprogrammierungThreadVektorraumVersionsverwaltungAuflösung <Mathematik>Minkowski-MetrikMini-DiscKurvenanpassungMultiplikationsoperatorBetriebsmittelverwaltungGlobale OptimierungTesselationTermResultanteQuaderMAPClientOrtsoperatorAutomatische HandlungsplanungProdukt <Mathematik>Speicher <Informatik>TypentheorieFestplatteObjekt <Kategorie>Lokales MinimumFlächentheorieZoomExogene VariableBitmap-GraphikOverlay-NetzDateiverwaltungDateiformatBitQuick-SortHalbleiterspeicherResponse-ZeitKonfiguration <Informatik>BimodulDifferenteMapping <Computergraphik>MathematikServerInformationGruppenoperationBefehlsprozessorSpezifisches VolumenErschütterungMultiplikationVolumenvisualisierungSystemaufrufGüte der AnpassungKontextbezogenes SystemÄußere Algebra eines ModulsFlächeninhaltModelltheorieFigurierte ZahlWasserdampftafelÄhnlichkeitsgeometriePunktSoftwareRechter WinkelEinfach zusammenhängender RaumProxy Server
22:57
ProgrammierumgebungInverser LimesFehlermeldungVerhandlungs-InformationssystemServerCAMARM <Computerarchitektur>Parallele SchnittstelleKontrollstrukturWarteschlangeInformationROM <Informatik>KontrollflussMetropolitan area networkSummierbarkeitKonfigurationsraumVollständiger VerbandOrakel <Informatik>LastVererbungshierarchieMaßstabNeuronales NetzSystemaufrufElementargeometrieServerMultiplikationsoperatorSchnittmengeEinsGeradeKontrollstrukturProzess <Informatik>Reelle ZahlCodeLastZweiMereologieHalbleiterspeicherDatensatzDienstgüteKartesische KoordinatenWarteschlangePlug inZahlenbereichParametersystemThreadp-BlockProdukt <Mathematik>SoundverarbeitungCASE <Informatik>GrundraumFormation <Mathematik>System FModelltheoriePunktEinflussgrößeSummierbarkeitWort <Informatik>Coxeter-GruppeVerschlingungStandardabweichung
26:20
ElementargeometrieDreiEinfügungsdämpfungStabilitätstheorie <Logik>ComputeranimationVorlesung/Konferenz
26:49
Web SiteMittelwertVerzweigendes ProgrammSoftwarewartungMultiplikationsoperatorStabilitätstheorie <Logik>SoftwareentwicklerReelle ZahlDatenflussTrennschärfe <Statistik>Vorlesung/Konferenz
27:10
ARM <Computerarchitektur>SoftwareentwicklerSoftwarewartungVorlesung/KonferenzComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:09
My name is Simone Jannikini, and I'm one of the founders of GeoSolutions. You already know Andrea. We're going to talk a little bit about how we, let's say,
00:20
put GeoServer in production. I'll be honest, the presentation is a summary of an eight-hour workshop, which I did in four hours already. So two times. If you were at a workshop and you thought it was going too quick, it's going to be quicker. OK. The information is available online. So this is actually, let's say, the table
00:42
of content for the workshop. And you can look at the workshop for more information. I'm hoping you know who we are. Otherwise, you can check it so I won't spend time on this. And I go directly to the content. Basic information. This is the boring information, but it's
01:00
the information you need to understand. Because how can you put GeoServer in production if you don't know and you don't understand the release model of GeoServer? Because basically, you don't know which is the right version to use in production. So first thing is to understand what is, to understand the release model for GeoServer. It's time boxed. That means we more or less know when
01:22
next release will be made. There are always three branches at any time. Development. That might tell you something, the name. You might not want to use development in production unless you really know what you're doing. Or you actually, you have no idea what you're doing if you use it. It's one way or the other.
01:40
Stable. The name is actually, again, pretty obvious. And maintenance. What is the difference? Every branch leaves for six months. You start as development. Then you become stable. Then you become maintenance. And then someone has to pay if he wants a release. Because we are not going to release that anymore.
02:00
So let's put it this way. If you start now, you might want to look at development for doing testing. So you see the new features. You wait for development to become stable. You test it a little bit. And in production, you always want to have stable or maintenance. If you follow what I said, if you don't need new features, you can upgrade once a month and keep using maintenance.
02:22
GeoServer will upgrade the configuration for you. We usually guarantee that if the jump is not too long, GeoServer will automatically upgrade the configuration. If you jump from, let's say, 2.2 to 2.8, maintenance right now is 2.8. You might have issues, because we cannot guarantee that such another version will upgrade automatically.
02:43
But if you follow the rules, you won't be asked to update too quickly. As I usually say, since I don't do development, but I talk to clients and talk to the DevOps team, a release every release often is extremely nice if you are a developer. If you are someone who want to maintain GeoServer or another application in production,
03:01
you don't want to upgrade and update often. Actually, you want to do it only when it's needed. So what I'm telling you, on average, if you don't have any problems, you can do it once a year. That's fine. Don't be scared by native releases. In GeoServer, we do test GeoServer quite a lot. Automatically, with unit testing plus some URL
03:22
testing every night for the releases, should be the compliance interoperability testing. It actually tests the compliance with OGC, but also tests that things are still working, if you know what I mean, by sending requests. Doing unit testing is not enough. I mean, you can test the DevOps component. They work together. You put them together. Everything stops working.
03:41
That's why you need also URL testing. URL testing means you stand up GeoServer and you start sending requests, and you check the results. That's something we do every night when we produce a native release. So you shouldn't be scared about using native release if they come from the right branch. If you are on maintenance, I'm using 2.85 right now. That is a bug fix that I need tomorrow.
04:00
Next release, it will be in two months. I can use the native release. That's what we do, at least. Before you start, let's say, talking about tweaks and everything, the first thing you need to understand is actually your data, a little bit about your users and how they will use your services, and the deployment environment.
04:21
Because you can test everything in an environment, you put it in a different environment. And I know there is Docker, but you will not be able ever to replicate entirely an environment. It might be even the host operating system. It might be the security system. It's different. It's 1,000 different degrees of freedom. The first optimization is to use your brain
04:40
and understand what you're going to do, not just look for documentation or look at the logs. The objectives, it's probably too small. You can actually check the song if you know house music. We want to make yourself harder, better, faster, stronger. So it's about scalability, performance, and robustness.
05:03
It's both pure performance and perceived performance. The difference is that perceived performance, it's in the eye of the users. Performance, it's something you can measure. Perceived performance is not the same thing. To give you an example about what the difference is, think about tile maps and untile maps.
05:22
Leave question aside. If you take a map and you make it tiled, it will take more time to fill the map with respect to the untiled map. But the perceived performance, it's better. Why? Because the user sees something right away. You remember the effect of the spider? So you need to care about that as well.
05:41
Scalability, let's say, being able to cope. We could results at increasing loads. Performance is simply being fast. The two things are orthogonal. You can be extremely fast, not scalable at all. How do you do that? You give all the available resources to a single request,
06:01
and you process the request at the time. So you are fast, but you won't scale. You can be extremely scalable and extremely small. You try to use as less resources as possible and put together as many requests as possible. Of course, you want to be fast and scalable. Robustness, well, you don't break under load.
06:22
Now there is a long list of different things you can do. I will not go into details about all of them. For example, I will not explain a lot about how you can prepare your raster input data, because we have been talking about this for ages. There is a ton of documentation. Basically, the information is, you remember what I said. You need to understand your use case.
06:42
You need to understand what your user wants and the environment. Many people, most part of the time, they start right away, experiment with format conversions, compression, whatever, without having clear in mind what they are doing. I'll give an example. If you want to optimize access to NetCDF and Grid, if you don't know anything and you
07:02
want to optimize blindly, the best thing to do is to not do anything. Why? Because usually these formats, they're used in environments where the data is relatively small in terms of spatial grids. So they're usually pretty fast. You don't want to spend a lot of time in pre-processing. The one key point to remember when you pre-process data
07:20
is that it takes time, especially for large raster data. So doing sophisticated pre-processing might give you best performance. But in certain cases, it might make your data old, which means useless. Think about atmospheric model, meteorological model, models, oceanographic models.
07:42
The key is to actually get the data out as quickly as possible. So we've been talking about this in some other presentation, for example, yesterday. In G7, we've done many tweaks in order to allow you to do sophisticated things, like wind arrows, contouring, et cetera, et cetera,
08:00
on the fly without doing pre-processing, because the key was to get the data out as quick as possible. Assuming you want to do performance, be careful with the formats that you use. Some of them might not be a good fit for performance. If your format is an ASCII format,
08:22
that might be problematic. I'll go quickly here, but the one thing I can tell you, we tend to use, when we do sophisticated pre-processing, we tend to always use GeoTIFF. GeoTIFF is like a Swiss knife. It can support many different optimization. You can use BigTIFF to break the limit of four gigabytes.
08:43
When you have extensive raster data, you might want to use things like mosaics or pyramids. We could talk for hours about what to use when, and there is no single magic recipe, I'm telling up front. If you saw what Andrea talked about,
09:00
we're actually moving towards making it easier to update large pyramids. The excess granular removal helps you to add data on top of existing data without having to exactly remove the older data, if you know what I'm talking about. You can leave some older data there, GeoServer will not read it. So there can be overlaps. You can exploit time dimensions
09:22
and create special temporal pyramids, so it's easier to do updates and add the new data. Vector data, similar things. You don't really want to use JML, JML or GeoJSON as an input format for serving.
09:43
If we need to explain why you might need to use a little bit of time to study special databases, usually you want to use a format which is for vector data, easy, sorry, fast, when you're going to extract a small portion of the data.
10:00
Most part of the time, although it might not seem like that, vector data is structured at least logically in records. And what you want to do usually is extract quickly a portion of these records using filters. Filters can be alphanumeric or can be spatial or a combination of the two. Quickly, Shadefile is good as long as you don't need
10:23
complex, if you don't need to run sophisticated or complex queries using alphanumeric attributes, at least in GeoServer there is no support for in Shadefiles on indexing alphanumeric attributes. If you have a four gigabyte Shadefile that you want to use as background layer and you have a complex style that actually
10:42
style things differently, filtering them depending on alphanumeric attributes, and it's slow, that may ring a bell. You would want to put this data inside the database because otherwise GeoServer, every time, will load the entire dataset and filter in memory. For Shadefiles, we only have spatial indexing.
11:05
I know it might seem an obvious thing, but it happens like every two months with a client because the people have the tendency to put everything on the screen and to render everything at all scale. And of course, that is not the best thing to do. So, Shadefile is good if you actually know
11:22
you're going to render everything and you're only going to filter, taking into account the area of interest, doing spatial filtering. At that point, Shadefiles are usually more scalable and faster than spatial databases because the number one problem about spatial database in terms of scalability, not performance,
11:41
you remember what I said, is that you are limited in the number of connections that you can use. So, you can make your queries as fast as you want, but on average, you won't have 20,000 connections available. So, let's say, we're leaving caching aside for a moment. Think about, for example, a simple map rendered from PostGIS or Oracle.
12:02
Let's say we render these maps in 50 milliseconds, okay? So, we can do how many requests per second? 20, 200, 20, 20? Okay, so that means if you want to do 20 requests per second, you need at least 20 connections.
12:23
In most use cases, in enterprise applications, you don't have that many connections because database are shared, you don't have control over them, so you will need to take this into account. Scalability will be an issue. You might be fast, but scalability will be an issue. So, you will have to use your connection wisely.
12:42
In Giuseppe, correct me if I'm wrong, we try to use two threads for the rendering, one for reading data, one for rendering. Why? We could load everything in memory and throw the connection away, but that would give us speed, but not scalability. Remember what I said before, because we will put all the resources on a request.
13:02
So, we tend to do this thing. We load data in chunk, so we are relatively fast, but we are scalable. The downside is that we use the connection for a longer time. We don't use the connection for the entire time of the request, but let's say 60%, 70%. It depends a little bit, but that's more or less the idea.
13:21
So, that gives you an idea if you know how fast you are, how many connections you need for a certain throughput that you want to reach. Of course, you need to index your data. If you don't know how, again, you might want to read a little bit how special databases works, but if you need help,
13:43
I never remember if it's raising or lowering the debug level. You want to go to Verbo's log, something like that. GeoSapphe will spit out the SQL queries that it's actually sending to the database. So, you can get them, put them in your database tool, and analyze them.
14:03
There is a lot of material on how to properly handle connection pooling in an enterprise environment. It might seem simple. It is not that simple depending on how your environment is structured.
14:20
There is DPAs in the mix that are actually killing connections, and you don't know when. There might be software and other appliances that are killing TCP connections when they are idle. We learned it the hard way. So, you really want to understand how to configure connections in detail.
14:41
It's not only about validating them. You always want to validate them, but there are also ways to actually, in background, make sure that they are valid, and they are still usable, et cetera, et cetera. Because if they're not, at the very least, you will get errors. In a very bad case, you will have to restart your server
15:01
because the connection pool will get exhausted. A quick suggestion that it's worth for both shapefile and special databases. When you have many, many attributes in your tables, and you're not going to use them in your styles, in your server, et cetera,
15:21
you might want to leave them aside. That will make the shapefiles bolder, but it will also make a geo-server use less memory for the special database connection because when we fetch the data, we will fetch less data. Geo-server should be smart enough for databases to not load attributes that it doesn't need.
15:43
But I mean, as I said, the first optimization is to use your brain, so this is an easy optimization. Wait a minute, I think you're doing styling. Okay, can you hear me? So styling-wise, well, geo-server has many styling capabilities.
16:00
You want to make maps that are readable by the user, so never try to show too much data. Like if you have a detailed road network of a nation, you don't want to show it completely when you are at one to one million, or something like that, because it would be a black blob. It's wasting CPU,
16:20
and it's also wasting the time of your users because they won't be able to read the map. Pay attention to labeling. Labeling is also expensive because there is a conflict resolution engine going, and it's gonna do some attempts to place the labels around. We have a new optimization in terms of quality, in geo-server 2.9,
16:41
which makes for better space allocation because we allocate space for charters as opposed to the bounding box of labels. But it's adding some overhead, so there is a system variable to turn it off if you find that it's slowing down your map production too much. Avoid using too many feature type styles because geo-server will allocate
17:01
multiple rendering surfaces to answer your request, which means it's gonna use more memory. And if you are using Z-ordering, which is a new ability that we have in geo-server 2.9, to make sure that underpasses and overpasses and stuff like that are in the right position in the map,
17:22
also be careful about not doing that at all zoom levels because we have to keep a certain amount of data in memory to go back and forth and do the Z-ordering correctly. Tiling and caching with GWC. Tiling is always a very important thing
17:42
to consider when doing maps because everything that's not changing can be tie-cached and provide a very significant speedup. So plan out what layers you want to tie-cache and which you don't because why don't you want to tie-cache? Well, because tie-caches take a lot of disk space
18:02
so you might not have enough for everything. GWC is embedded in geo-server so that gives a speed boost compared to an external tie-cache. Disk space considerations. So take into account that going up to level 20
18:22
might require gigabytes if not terabytes of storage so depending on your area, of course. So take that into account. Take into account the client-side caching. Sometimes you can tell the client not to request the same tile over and over for a certain amount of time and that's sort of the ultimate optimization
18:43
because the client won't bother the server at all. It's not just not producing the tile. It's not even transferring it, which is great. Choose the right format for your tiles. So normally it's PNG for vector data and JPEG for raster data. We have the new JPEG or PNG
19:01
if your raster overlays have transparency so consider using that. There's also vector tiles. It's a community module but it's very nice in that the vector tiles are more compact and they can be over-zoomed. So instead of building your tile cache up to level 20, you can just stop at, I don't know, 16, 17
19:22
and then over-zoom on the client-side because this information is a vector. In GeoServer 2.9, we have embedded support which is very nice to move around tile caches between servers so you can actually prepare a tile cache on one server offline and then put it on a production server
19:41
which is, again, nice for giving your user a good experience. Consider choosing between when you have a cluster. When you have a cluster, you might want to choose between having a single shared cache which is probably the best option if you are preceding everything
20:02
versus smaller independent caches local to the hard drive when you are using disk quota and just caching on demand. The trigger here is not having to write all that much on a shared file system because most shared file systems suffer a lot when you keep on writing and creating new tiles
20:23
and deleting tiles continuously. Simone? Yeah, quickly, one thing about this, you can actually mix and match independent caches and shared caches because different layers can use different storage. So you might want to use shared caches for layers that don't change at all, like background layers.
20:41
Smaller caches that changes more frequently, the leads will take forever if you put them on a shared file system. So you might want to consider having them independent which means duplicating them. So you pay a penalty doing that. But if you compare the time it takes to delete them and create them,
21:02
you are actually much faster. Assuming you have optimized everything, you want to measure what you have done. All right, this is Andrea explained me a while ago. It's your friend where you're actually looking at the results. It's two curves. I'm an engineer, I'm not a scientist, so I tend to simplify.
21:20
If you are not happy with the curves, I know things are a little bit more complex but I never liked math, okay? It's the throughput, it's the green curve, the one that it's, let's see, almost look at it and then it goes down, and the response time. And then the red one is the resource optimization systems.
21:42
Again, it's a simplification. After they have warmed up, okay, they tend to behave this way. When you have to warm them up, there might be fluctuations, and there will always be some fluctuations, but I mean, we are simplifying. What you want to do when you optimize, it's actually having the throughput curve grow.
22:02
It's in load, usually it's measured by increasing users or threads. So you want the throughput to grow, more requests per second, okay? And you want the response curve to stay down as much as possible. At a certain point, you will need a bottleneck. It can be the CPU, it can be the disk,
22:21
it can be the network, it can be the memory, it can be GeoServer, because I mean, there are bottlenecks in the software as well, okay? And there is one that we talked about before. And there is some mentioning. So the objective is actually when you measure, it's to improve these curves. We'll see, once you have optimized everything,
22:41
you want to make sure that the throughput will not fall down, okay, as you reach the maximum utilization, but you will ensure fairness. So if you get more requests than the request that you can cope with, it will start queuing them and rejecting them, instead of trying to serve in all of them and not being able to serve any, because you're trashing your resources. If the load keeps increasing after a certain point,
23:03
things will not get better, we get worse. So we need to make sure we don't reach that situation. There is two ways to put a server in a crazy situation. One is to send requests that are too big, and we have the resource limits, paired services, to actually make sure that won't happen.
23:22
The other way is to send legal requests, but sending too many at the same time, like an IO service attack. Each service has parameters and settings to actually make sure you can limit how much memory we use, how many rows we read, how much data we generate, and for how long a service can run,
23:42
and this depends on the service. There is settings for WMS, WFS, WCS, and WPS. Andrea showed some announcement to the WPS ones. You can make sure the WPS process don't stay in the queue for too much or don't execute too much. It's not as simple as that, by the way. The process has to cooperate, because you cannot kill a thread in Java
24:01
unless you want to kill the entire application. There is a control flow plugin that you can install to make sure to actually do quality of service and throttling, which means if I get more requests than a certain number, I will start to queue the requests instead of trying to serve them, and I can actually do also real quality of service, like saying for these users, I don't want to,
24:21
my throughput cannot be more than X request per second. There is no time to explain how that works, but I mean, it's pretty sophisticated. And it actually allows you to do something like this. The blue line, it's actually a measured throughput,
24:40
so you see at a certain time, you start to go down, so what you usually do, use control flow to make sure that when the, for example, in this case, your server will not execute more than 16 requests at the same time. Follow me here is not 16 requests per seconds. If each request executes in 50 milliseconds,
25:01
it will be 16 per 20 requests per second. This is the number of requests that are executing. If you have four cores, we will need more time to explain this, but if you have four cores, ideally you won't be able to execute more than eight, 10 requests at the same time. At the same time, like a line of code that are executing.
25:22
There will be some IO8, so if you have four, it could be eight, because they could switch, they need a connection, they're writing, et cetera, but it will never be 200, okay? Okay, there will be an interesting part at the end. I didn't have time.
25:42
Yeah, you checked the presentation. It's about what you do afterwards when you are in deployment, so that is one thing which I just want to show you. You need to make sure when your server is in production, it's when the fun starts. I heard another thing, but I don't remember where that is.
26:01
You need to be prepared, because everything will fail sooner or later. If it doesn't, nobody's using your services, so keep that in mind. You just need to be prepared for when that happens. So monitoring, logging, and taking snapshots, metering, et cetera, et cetera. That's it.
26:28
Yeah, so maybe one quick question, because I was a bit late. Anyone? Maybe, really in the beginning you said that there's no stable release anymore,
26:41
or did I understand it correctly? Sorry, I didn't hear you. There was no stable release for GeoServer? No, no, no, there's always a stable release. Yes, but there's no maintenance, or I just didn't understand what you said exactly. I just, every time there is a development branch, a stable branch, and a maintenance branch, and the release is as time boxed,
27:01
so you get releases every more or less one or two months, and they scale back. So basically we release one month of the stable, one month in the maintenance, the next month the stable, and so on, and every six months we switch the development back to stable, the stable back to maintenance, and all the maintenance goes away. Okay, then I probably understood your role.
27:22
Thank you.