FOP, constante prestaties krijgen bij het genereren van pdf's

We ondervinden problemen met de prestaties van fop (v0.95) bij multiples-oproepen. We maken een pdf met een paar afbeeldingen en onze eigen lettertypen.

De eerste oproep is veel langer dan de andere en het is een probleem voor ons. Hier zijn enkele oproepvoorbeelden (tijden zijn in ms):

  • Oproep # 1 - verstreken tijd = 13929
  • Oproep # 2 - verstreken tijd = 2817
  • Oproep # 3 - verstreken tijd = 3312
  • Oproep # 4 - verstreken tijd = 1629
  • Oproep # 5 - verstreken tijd = 1436
  • Oproep # 6 - verstreken tijd = 1356
  • Oproep # 7 - verstreken tijd = 911
  • Oproep # 8 - verstreken tijd = 1244
  • Oproep # 9 - verstreken tijd = 780
  • Bel # 10 - verstreken tijd = 895

We hebben verschillende dingen geprobeerd om dit op te lossen:

  1. Ons lettertype laden met behulp van de parameter folder in plaats van of laden elk lettertype met de fonttag
  2. Stric-configuratie instellen op true
  3. Strenge validatie instellen op false
  4. Gebruik van het cachebestand (cache-bestandstag)

Niets verbetert de prestaties tijdens het eerste gesprek aanzienlijk. Onze enige oplossing op dit moment is het genereren van een nep-pdf in de constructor, dus de eerste aanroep zal kunstmatig worden gedaan bij jvm start.

Heeft u een suggestie om de uitvoeringen te verzachten, en misschien enkele uitleg over dit gedrag?

Bij voorbaat dank.

 2
toegevoegd
Bekeken: 38
de bron
ru fr es pt de hi bn ar kk tr

2 antwoord

Dat is een effect van het laden van Java-klassen en JIT (just-in-time compileren), de zogenaamde JVM-warming-up. De JVM verbetert de prestaties geleidelijk omdat het optimalisatiepotentieel ziet. Als je bijvoorbeeld 100 oproepen uitvoert, zie je uiteindelijk min of meer constante prestaties. Er is eenvoudig niets dat u kunt doen om dit te veranderen, en hetzelfde geldt voor elke Java-toepassing.

Misschien kunt u overschakelen naar de client-VM (-client als JVM-parameter) als u momenteel de server-VM uitvoert (standaard met een 64-bits CPU). Dat kan het effect dat je ziet een beetje verminderen, maar waarschijnlijk niet veel.

0
toegevoegd
de bron
@jakcam: naast JIT/Startup-tijd (die kan significant zijn), werkt u ook op voorgevulde buffers met alle behalve de eerste oproepen (dwz het besturingssysteem heeft al alle benodigde bronnen gelezen en heeft niet niet nodig om je schijf te laten draaien voor de tweede, derde, ... tijd rond).
toegevoegd de auteur Joachim Sauer, de bron
Ik ben het met je eens JIT verbetert de prestaties na 4-5 gesprekken (ik zie enkele referenties op het net die mijn gedachten bevestigen). Ik kan echter niet uitleggen waarom de eerste oproep ~ 14 seconden kost en de tweede 6 keer minder. Bedankt.
toegevoegd de auteur jakcam, de bron

Hoe vaak veranderen de onderliggende bronnen in de gegenereerde PDF?

Ik heb eerder met FOP gewerkt en had ongeveer dezelfde problemen en heb er nooit een schone manier omheen gevonden (ook al is er misschien een).

Het enige dat ik achteraf zou hebben geprobeerd zou zijn om de pdf te genereren wanneer de onderliggende bronnen blijven bestaan; en serialize het in tegenstelling tot rendering on demand. Telkens wanneer een verzoek binnenkomt, retourneert u gewoon de meest recentelijk in series verdeelde pdf. Ook al zou u uiteindelijk PDF's kunnen genereren die nooit worden gebruikt; het zal de tijd voor de gebruiker om hun pdf te krijgen drastisch verminderen; waarschijnlijk meer dan de tijden die je nu ziet.

0
toegevoegd
de bron