PERFORMANCE DokumentBrokeren Copyright 2012
INDHOLDSFORTEGNELSE 1 Målinger og analyse...1 1.1 Kørsler på Amazon-serveren...1 1.1.1 PDF...1 1.1.2 ODF...2 1.2 Kørsler på PC med 2 kerner og 12 GB RAM...2 1.3 Analyse og konklusion...3 1.3.1 PDF på Amazon-serveren...3 1.3.2 ODF på Amazon-serveren...4 1.3.3 PDF på PC med 2 kerner og 12GB RAM...4 1.3.4 Konklusioner og anbefalinger...5
Målinger og analyse 1 MÅLINGER OG ANALYSE Filen /client/broker_client.py er modificeret, så den inkluderer en stresstest. Køres den fra kommandolinjen med en enkelt parameter, tolkes denne parameter som antallet af gange, der skal genereres en fil, i første omgang en simpel PDF-fil. 1.1 Kørsler på Amazon-serveren Filerne (med start- og slutttidspunkt for hver generering til brug for statistisk analyse) er vedhæftede, og filnavnene fremgår af specifikationen af hver enkelt kørsel. Bemærk: Disse kørsler er på vores Amazon-server, som har 4 GB RAM og kun én kerne. De bør gentages på en maskine med mere RAM og flere kerner. 1.1.1 PDF Første kørsel: Generer 100 PDF'er i træk, uden at serveren i øvrigt er belastet. time python broker_client.py 100 > time_file.txt 9m48.972s 0m0.844s 0m0.556s Anden kørsel: Generer 100 PDF'er i træk samtidig med, at der kører 10 andre, identiske processer, der gør nøjagtig det samme (der genereres altså i alt 1100 PDF'er): time python broker_client.py 100 > time_file_10simultaneous.txt 79m30.104s 0m0.940s 0m0.576s Tredje kørsel: Kun fem samtidige processer, dvs. 6 i alt: time python broker_client.py 100 > time_file_5simultaneous.txt 48m14.503s 0m0.952s 0m0.632s Fjerde kørsel: 50 samtidige processer (5100 dokumenter genereres): 428m53.516s 0m1.424s 1
Kørsler på Amazon-serveren 0m0.412s Det ser ud til, at CPU'en er flaskehalsen, fordi der skal bruges en vist mængde CPU-tid pr. FOPproces. Det betyder, at løsningen med FOP skalerer dårligt, hvis der kun er en enkelt kerne til rådighed. Målinger på andre temer vil kunne be- eller afkræfte den antagelse. 1.1.2 ODF 100 ODF'er uden yderligere belastning: 2m6.376s 0m1.224s 0m0.444s 100 ODF'er med 10 samtidige processer (1100 dokumenter i alt): 3m0.774s 0m1.312s 0m0.312s 100 ODF'er med kun 5 samtidige processer: 2m19.938s 0m1.212s 0m0.380s 100 ODF'er med 50 samtidige processer (5100 dokumenter i alt): 16m20.220s 0m1.388s 0m0.288s Bemærk: Det tager stadig længere tid, når serveren er hårdere belastet, men der er ikke den distinkte flaskehalseffekt, som vi observerer for PDF-filers vedkommende. 1.2 Kørsler på PC med 2 kerner og 12 GB RAM 100 PDF'er uden yderligere belastning: 3m35.125s 0m0.676s 0m0.232s 100 PDF'er med 10 samtidige processer: 2
Kørsler på PC med 2 kerner og 12 GB RAM 29m1.108s 0m0.516s 0m0.128s 100 PDF'er med 5 samtidige processer: 14m54.352s 0m0.476s 0m0.120s 100 PDF'er med 50 samtidige processer: 121m53.701s 0m0.472s 0m0.172s 1.3 Analyse og konklusion 1.3.1 PDF på Amazon-serveren Hvis vi plotter den tid, det tager at generere 100 PDF-filer mod belastningen, det vil sige det samlede antal dokumenter, får vi for Amazon-serverens vedkommende: 3
Koefficienterne betyder umiddelbart, at det altid tager ca. 5 sekunder (grafens hældningskoefficient) at generere hvert dokument. Dette bekræfter formodningen om, at det er serverens CPU, som i praksis kommer til at fungere som flaskehals. 1.3.2 ODF på Amazon-serveren En tilsvarende analyse af vore data for ODF-generering viser, at der ikke er den samme lineære sammenhæng mellem det samlede antal dokumenter og den tid, det tager at generere. Der er dog stadig en stærk korrelation svarende til, at hvert ODF-dokument tager ca. 0,2 sekunder at generere. 1.3.3 PDF på PC med 2 kerner og 12GB RAM Hvis vi laver et plot, der svarer til det for Amazon-serveren, ser vi samme meget lineære sammenhæng og "flaskehals-effekt" som før. Den væsentligste forskel er, at det enkelte dokument genereres ca. tre gange så hurtigt, på 1,4 sekunder i modsætning til 5 sekunder. 4
1.3.4 Konklusioner og anbefalinger Generering af PDF-filer med Apache FOP er en tung proces, som lægger beslag på 100% af CPU'en i et ret veldefineret tidsrum - for vores test-dokuments vedkommende ca. fem sekunder på Amazon-serveren. Dette medfører uundgåeligt kødannelse, hvis forespørgsler efter dokumenter ankommer med en frekvens, der er større end den tid, det tager at behandle dem. Hvis Apache FOP skal bruges til dokumentgenerering i et produktionsmiljø medfører dette, at det er nødvendigt at være bevidst om den forventede belastning af dokument-brokeren og indkøbe hardware herefter. Generelt anbefaler vi, at en server, der skal generere PDF-filer og risikere at møde en stor belastning, udstyres med: 1. Meget RAM - min. 8GB, gerne 12GB RAM. 2. Flere CPU'er eller CPU-kerner - gerne 4 eller 8 kerner. Der kan laves en del optimering af dokument-brokeren, som den er i dag. Væsentlige punkter er: 1. Hav alle temporære samt genererede filer i RAM, ikke på disk. (Dette kan laves ved at 5
Analyse og konklusion montere nogle dele af filtemet som RAM-disk, se f.eks. http://www.ubuntuka.com/ubuntu-ramdisk-ramdrive-easy-way/). Dette erstatter næsten al disk-i/o med det meget hurtigere RAM. 2. Generer XSL-FO v.hj.a. XSLT når en skabelon gemmes, ikke når PDF'en genereres. 3. Lav profiling af Python-koden og identificér de steder, hvor der bruges mest CPU. Vi har endnu ikke nogen sikker viden om, hvor meget der kan vindes ved en sådan optimering. Flaskehalsen er stadig Apache FOP og dens høje forbrug af CPU-cykler, så det vil måske højst være i størrelsesordenen 10-20%. Der kunne vindes betydeligt mere ved at finde ud af, hvorfor FOP er så forholdsvis tungt eller måske udskifte det med et andet PDF-værktøj. (P.t. kender vi dog ikke til andre FOSS-værktøjer, der vides at understøtte PDF/A.) Med hensyn til HTML-skabelonerne har vi følgende anbefalinger, som vil undgå dårligere performance end nødvendigt. 1. Vær opmærksom på, at al grafik til inklusion i PDF-filer har en passende størrelse og især ikke har højere opløsning end nødvendigt. 2. Undlad interne referencer i de resulterende PDF-filer, især fremadrettede interne referencer. Grunden er, at dokumenter med fremadrettede interne referencer kræver meget mere RAM at generere, fordi FOP er nødt til at generere hele dokumentet på én gang. 3. Undlad DOCTYPE-linjen i starten af dokumenterne. Denne får af ukendte årsager genereringstiden til at eksplodere. Bemærk, at ODF-generering går så meget hurtigere, at det slet ikke er det punkt i processen, der bliver flaskehalsen, hvilket gør det meget nemmere at dimensionere hardware. Det er dog ikke helt rimeligt at sammenligne de to scenarier, eftersom ODF-genereringen i alt væsentligt er en simpelt tekst-fletning, mens PDF/A-1a-genereringen genererer et færdigt print med indlejring af komplekse elementer som skrifttyper og grafik. Den vigtigste anbefaling ved generering af PDF er, at man er opmærksom på, at Apache FOP er et forholdsvis tungt værktøj. Dimensionering af hardware er derfor kritisk. Den nuværende Amazon-server ville formentlig være acceptabel for en lille kunde, der f.eks. kun skal have genereret 10 dokumenter i døgnet, mens det for større installationer er vigtigt at dimensionere efter de præcise behov, for eksempel ved hjælp af performance-målinger baseret på kundens vigtigste dokumenter. 6
adresse Studiestræde 14, 1. 1455 København K email info@magenta-aps.dk telefon (+45) 33 36 96 96