Kundens klagomål på att "servern är väldigt långsam ibland" eller "ibland fungerar servern inte som förväntat" är det problem som är svårast att hantera, särskilt i stora miljöer där du inte kan fråga kunden "Vad har du gjort som är annorlunda?"

Med användarloggar och kunskap om hur de ska läsas och utnyttjas kan vi upptäcka och förstå många av de här problemen. Om vi dessutom använder verktygen för att observera serverns beteende under normala förhållanden kan vi snabbt identifiera möjliga problem och lösa dem, ibland innan kunden ens har märkt av dem.

Med början på 4D v11 SQL tillhandahåller 4D Server många loggfiler, vilket möjliggör detaljerade analyser på annan plats som hjälper oss förstå serverns beteende och problem. Den här delen av utbildningen fokuserar på fyra verktyg som skapats för detta syfte.

4D Cache Log Analyzer

En av passets höjdpunkter är detta verktyg för att spara resultatet av kommandot GET CACHE STATISTIC och analysera det, vilket ger en klar bild av cacheminnets beteende, till exempel:

Dessutom ger det information om cacheanvändning, till exempel stora lediga block och fysiskt eller virtuellt minne, vilket hjälper oss förstå applikationens minneskrav.
 

Alla dessa data gör att vi inte bara kan felsöka, utan också analysera och förstå applikationens minneskrav så att vi kan finjustera dem och inställningarna och skapa en kravtabell, till exempel för 5, 10, 25, 50 och 100 användarinstallationer för specifika applikationer och användningsområden.

4D Info Report Component 3.0

Information Report Component ger viktig information om miljön, med detaljerad information om maskinvaran som används (datortyp, CPU, minne osv.), operativsystem (till exempel Windows Server R2 SP1) och version av 4D (till exempel 12.2 Hotfix 2), samt en ögonblicksbild av den aktuella statusen för använt minne, antal användare och antal processer, till exempel:

Tillverkare:                  	PowerEdge R710

Datortyp:                 	         x64-baserad PC

Totalt RAM:                     	16384 MB

Antal processorer:          	2

Processornamn:                	Intel Xeon  E5520

CPU-hastighet:                     	2,27 GHz

Totalt antal kärnor:         	8

Totalt antal CPU-trådar:   	         16

Operativsystem:              	Windows Server 2008 Standard SP1 
                                    (64-bitar)

Applikationstyp:              	4D Server (64-bitar)

Applikationsversion:           	v12 release 2  (F0021220)

Den här komponenten bör ingå i alla utplacerade serverapplikationer som ett första steg för att förstå situationen (även historiskt) hos kunden. I följande tabell visas till exempel beteendet för den cache som används i förhållande till antalet användare och det totala antalet användarprocesser under en veckas användning:

4D Pop Data Analyzer

4D Pop Data Analyzer är en komponent som analyserar storlek och innehåll i 4D-datafiler. Det här verktyget hjälper dig förstå minsta och största storlekskrav för en post och analyserar storlekskraven både utifrån verkliga data och tabellfragmentering.

Network Log Analyzer

4D Servers nätverkslogg producerar snabbt stora mängder data, vilket gör det svårt att identifiera ett problem på grund av antalet paket. Network Log Analyzer fokuserar på undantag, till exempel mycket stora eller mycket långsamma paket.

Network Log Analyzer samlar alla paket i 5-minutersintervall, så att vi snabbt kan identifiera problematiska tider under dagen:

Det här exemplet visar en extremt överbelastad server med genomsnittliga svarstider på mellan 0,5 till 5 sekunder, och en maximal svarstid på upp till 113 sekunder för en enda begäran.

Ett dubbelklick leder snabbt till de berörda operationerna:

Paketen sorteras efter tidsbehov, så det är enkelt att se att den långsammaste operationen på 113 sekunder var en fråga, följd av en annan långsam fråga och sedan en Selection to array som tar 25 sekunder och sedan snabbt minskar. Användarnamn/processnamn (suddat här eftersom detta är verkliga kunddata) gör att vi kan identifiera operationen, och ännu ett dubbelklick reducerar operationerna till en enda process. Att veta exakt vad som gjordes före och efter gör det ofta enkelt att hitta motsvarande del av källkoden.

Dessutom kan vi synkronisera kundens felsökningslogg med nätverksloggen och visa dem sida vid sida:

Lär dig den här tekniken och mycket annat på förutbildningen för 4D Summit 2011 i Boston, Massachusetts, tillsammans med 4D:s bästa tekniker och utvecklare från hela världen.