Performance Problem durch mehrfaches Starten eines JAVA Prog

[Chris81T]

Hallo zusammen!


Also grundlegend bin ich kein JAVA Programmierer, okay hatte mal ein kleines Spiel programmiert, sondern arbeite vorrangig mit C++ / Qt.

Bei einer Projektvorgabe geht es um eine Verbesserung eines bestehenden Projekts.


Was macht das Projekt / Programm:

Es bekommt ein XML geschickt und besitzt eine passende XSL Vorlage (erstellt durch das XSL Fast Programm für XSL-FO). XSL Fast muss auch weiterhin verwendet werden und kann nicht ersetzt werden. Leider bietet es nur Unterstützung zum Apache FOP und 2 kommerziellen FO Prozessoren.

Diese 2 Formate werden als Parameter mit dem Apache FOP Java Programm transformiert und es kommt ein PDF hinten raus.

Nun zum Problem:

Es kommen beispielsweise in kürzester Zeit so 100 XML Daten an und müssen alle mit schon vorhandenem XSL als PDF transformiert werden, um u.a. zum Drucken bereitzuliegen (also 100 FOP ext. Prozess Aufrufe - multithreaded realisiert), dann wird's schon langsam.

Die zwei kommerziellen Alternativen sind zu teuer.

Gibt es eine Möglichkeit, dass irgendwie zu optimieren? Also das man irgendwie das FOP Programm hochlädt und dann 100 mal ausführen kann?? Irgend sowas in der Art?
Ich kenn mich halt mit der JVM / Java Programme nicht gut aus

Hat jemand Rat für mich?


Wäre super

Vielen Dank

Gruß Christian


PS: Plattformunabhängigkeit muss auch weiterhin gewährleistet sein Win / Linux

 

[tuxedo]

>> Diese 2 Formate werden als Parameter mit dem Apache FOP Java Programm transformiert und es kommt ein PDF hinten raus.

Verstehe ich das richtig, dass für jede zu konvertierende XML Datei das Konverterprogramm, geschrieben in Java, gestartet wird und dann also als eigener Prozess im Taskmanager/in der Taskliste zu sehen ist??

Wenn ja, dann erklärt das dein Performance-Problem.

 

[Chris81T]

>> Verstehe ich das richtig, dass für jede zu konvertierende XML Datei das Konverterprogramm, geschrieben in Java, gestartet wird und dann also als eigener Prozess im Taskmanager/in der Taskliste zu sehen ist??

Hallo,


grundlegend ja.

programmiert wird halt in c++ / qt, dass bedeutet doch, sofern ich mich nicht irre, dass ich das FOP Java Programm doch nur über einen eigenen Prozess innerhalb meines Programms zum laufen bekomme. Oder gibt's ne andre Möglichkeit?

Grundlegend geht die Verarbeitung eines XML + XSL recht schnell (Das JAVA Programm ist ein reines Consolen- Programm). Aber durch jeden neuen Prozess kommen doch noch zusätzliche Laufzeiten zustande (von der Erzeugung mal abgesehen), weil doch dann jedesmal die JVM den Byte- COde vorbereiten muss, bis dieser ausgeführt wird, oder?

So war mein Gedanke, den einmalig vorzubereiten und dann immer wieder zu nutzen, falls es sowas gibt.

Wenn ich ja ein C++ compiliertes Programm starte, habe ich dieses ja direkt zur Verfügung, wenn man es startet.


PS: Es muss nicht zwingend sein, dass 100 Prozesse parallel laufen! Das war nur so in Richtung "worst case"

 

[tuxedo]

Also den Converter jedesmal neu starten und damit eine komplette JVM starten ist absoluter quatsch. Sowas macht kein "normaler" Mensch (sorry...).

Es gibt genug möglichkeiten Java mit anderen Sprachen zu kombinieren. Sei es JNI oder, auf die altmodische Art, mit einer Socketverbindung.

Ich würde, weil ich JNI nicht mag und es auch wieder zu performanceschwierigkeiten kommen kann wenn wirklich viel zwischen C und Java transportiert wird, zur Socketberbindung greifen.

Sprich: die Java-KOnverter-Anwendung als eine Art Server machen, zu dem sich die C anwendung hinverbindet, die Daten überträgt und Java dann die PDF ausspuckt. Damit reicht eine einzige JVM Instanz die dann in einzelnen Threads die eingehenden Konvertieranfragen bearbeitet.

An der bestehenden Implementierung irgendwas "performanter" machen zu wollen scheint mir unnütz, da vermutlich wirklich der ganze overhead durch das ständige starten und beenden der JVM entsteht.

 

[Murray]

Man kann aus einem C(++)-Programm eine Java-VM per JNI erzeugen; diese VM läuft dann im Kontext der Anwendung (es gibt also aus OS-Sicht nur einen Prozess). Und in dieser VM kann man dann Objekte erzeugen und Methode aufrufen (im Prinzip macht die java.exe nichts anderes - sie erzeugt eine VM und ruft dann die (statische) main-Methode der Anwendungsklasse auf). Insofern könntest Du Dir den Prozess-Overhead sparen.

 

[Chris81T]

@alex

>> Also den Converter jedesmal neu starten und damit eine komplette JVM starten ist absoluter quatsch. Sowas macht kein "normaler" Mensch (sorry...).


Das bestehende Projekt ist nicht auf meinem Mist gewachsen.. Ich gebe dir da natürlich recht, dass das so nicht schön ist! Ganz klar.

Deswegen hab ich gefragt (auch für Alternativen, mein ich...)


Das mit der SOcket- Verbindung ist nicht schlecht, hör sich gut an. An eine solche Lösungsart hatt ich gar net gedacht, da man jetzt erst das eine Problem vor der Nase hatte


Also konkreter Ansatz:

Ich muss mir im den FOP Transformator ein JAVA Programm drumrum bauen, dass halt auf eingehende Daten vom "Cpp/Qt Prog." Prozess wartet. Wenn welche kommen, mit nen erzeugenden Thread auf JAVA Basis den FOP nutzen (FOP ist OPenSource) und das pdf transformieren, Thread schließen; usw...

Hast du das so gemeint?

@Murray

danke für den Post


@all:

Vielen Dank schonmal für eure Anregungen! jetzt hab ich was zum Weiterschauen. Falls jemand noch was weis, bitte melden

 

[tuxedo]

Wobei ich mir hab sagen lassen (von meinem Projektleiter während meines Praxissemesters bei Daimler), dass es nicht sehr performant wäre viele Daten via JNI zwischen Java und C auszutauschen. Schneller gehts dann nur noch via Sockets (localhost).

Worauf er sich da gestützt hat: Keine Ahnung, aber ich hab eine bestehende JNI Lösung jedenfalls neu implementieren dürfen, mit Sockets. Und laut meinem Projektleiter war das um um längen schneller als die JNI Lösung.

 

[Murray]

Wobei ich mir hab sagen lassen (von meinem Projektleiter während meines Praxissemesters bei Daimler), dass es nicht sehr performant wäre viele Daten via JNI zwischen Java und C auszutauschen. Schneller gehts dann nur noch via Sockets (localhost).

Worauf er sich da gestützt hat: Keine Ahnung, aber ich hab eine bestehende JNI Lösung jedenfalls neu implementieren dürfen, mit Sockets. Und laut meinem Projektleiter war das um um längen schneller als die JNI Lösung.

So allgemein würde ich die Aussage "Datenübertragung per JNI ist langsamer als über Sockets" nicht stehen lassen - wenn das in einem konkreten Projekt (ich würde hinzufügen: ausnahmsweise) mal der Fall war, dann ist bei der Neuimplementierung sicher noch deutlich mehr verändert worden. Denn eigentlich muss bei der Übertragung von Daten über Sockets alles passieren, was auch bei JNI passiert (Allokation und später Deallokation der benötigten Speicherbereiche, ggfs. Überführung der Datenrepräsentation aus der C- ind die Java-Welt etc) - nur dass zusätzlich auch noch Prozesswechsel, I/O-Operationen und komplexe Netzwerkprotokolle erforderlich werden.

 

[tuxedo]

Naja, er hat's damals (ist etwa 3 Jahre her) damit begründet, dass es mehrere JVM Calls bedarf damit die Kommunikation funktioniert. Genau hab ich's nicht verstanden.

Konkret gings um Datenübertragung mit einem CAN-Bus (eine Art Netzwerk, für alle die mit CAN nix anfangen können). Da kommen schon Megabyteweise Daten zusammen.
Aber ich könnte mir vorstellen, dass in diesem Fall hier, auch einiges zusammenkommen kann.

- Alex