Hallo!

Wir haben bei einem Kunden ProfiCash auf einen neuen Terminalserver umgezogen, die Daten liegen auf einem anderen Server, beide sind über 1000MBit miteinander vernetzt. Wenn der Kunde nun Daten holen will macht er dies über HBCI und EBICS, er hat mehrere Konten. Über HBCI geht das sehr schnell (30 Konten in ca. 30 Sekunden), über EBICS geht es aber sehr langsam. Die Verschlüsselungsdaten sind auf einem USB-Stick, der über die RDP-Session gemappt wird. Auf diesen wird auch problemlos zugegriffen. Der Standort ist über VPN mit 10MBit (symetrisch) mit der Serverfarm verbunden, an der Bandbreite sollte es also eigentlich nicht liegen.

ProfiCash ist auf dem letzten Stand (9.4). Die Einstellungen vom EBICS sind:
-Adresse: https://ebics.sozialbank.de/
- Version 2.2
- ohne verteilte EU angehakt

Leider habe ich nicht so den Plan von dem gesamten Verfahren

Hat vielleicht jemand eine Idee wo ich drehen kann, um die Übertragung schneller zu bekommen?

Danke,
Kucht

is der port komplett freigeschalten? EBICS läuft im gegensatz zu HBCI (port 3000) über den port 443, wenn der irgendwie den datentransfer überwacht, kann das die ganze geschichte verlangsamen.

nur so ne idee....

die Ports sind in der Firewall komplett frei geschaltet. Noch eine Sache, die ich gestern nicht erwähnt hab. Vorher lief das ProfiCash ohne Probleme auf einem Windows 2000 (Citrix) im gleichen Segment, war nur was zäh, da der Server alt ist. Jetzt ist es auf einen Windows 2008 Server (Standard deutsch mit allen SP und Patches, 32bit) umgezogen. Da geht alles bis auf das EBICS schnell. Firewall ist auf dem Server aus, Antivirus hab ich deaktiviert zum Test, hat aber auch nicht geholfen.

also bei mir war da entweder der port, firewall oder das virenprogramm dafür verantwortlich. am proficash selber kanns meiner meinung nach nicht liegen, da sonst die hbci-übetragung ebenfalls so langsam wär!

ist irgendwo noch ne firewall geschalten die die daten oder pakete o.ä. überwacht?oder ein anderes virenprogramm?

Ich weiss nicht wie bzw. wann Proficash das macht, aber die beiden Kernel für HBCI und EBICS müssen ja wenigstens zur Datenübertragung in den Speicher und in obiger Konstellation vorher übers Netz geladen werden.

Die Größen der Kernel unterscheiden sich signifikant, es sind 3-4 gegenüber 60-70 MB zulasten von EBICS.

Trotz Gigabit Netz und aktuellen Rechnern ist dabei auf jeden Fall ein Unterschied spürbar. Müsste aber früher ebenfalls aufgefallen sein....

Hmm, wir haben nur die "große" Firewall vor's LAN geschaltet, da ist aber alles freigegeben und Security Services haben wir dort nicht laufen. Mir ist der Windows Defender noch eingefallen, dem hab ich daraufhin verboten die ProfiCash Verzeichnisse zu überwachen, hat aber auch nicht geholfen.

Von wo nach wo werden denn die Kernel übertragen? Merkwürdig ist halt, dass es vorher in gleicher KOnstellation nur mit anderem Server geklappt hat. Bin echt ratlos

Die Applikation wird ja auf dem Terminalserver gestartet und holt sich die Daten vom Fileserver. Die Frage ist, wann und wie oft das passiert.

Die Ursache kann natürlich auch was ganz anderes sein.

Ich würde auch mal in der Richtung forschen:
Wo das Programm liegt und wo die Daten, siehst du an den einzelnen Ini-Dateien (wpc.ini und die wpcdir.ini). Manchmal sind die ausführbaren Dateien ja mehrfach vorhanden, deshalb empfiehlt sich hier mal nachzusehen.

Gruß
Raimund

Hallo,

im EBL-Forum wurde diese Thematik nun auch angesprochen und dort wurde auf folgenden Ini-Eintrag verwiesen, der wohl mit PC 9.3 ins Programm kam.

Gruß
Daniel

Zitat:
Das EBICS-Übertragungsprogramm wird in der DFÜ-Programmversion in Zukunft bereits beim Start von Profi cash in den Speicher geladen, falls der sich anmeldende Anwender eine EBICS-Berechtigung besitzt. Dadurch können spätere EBICS-Transaktionen in einer deutlich kürzeren Zeit ausgeführt werden. Der WPC.INI-Eintrag "EBICS_START=0" bewirkt, dass das EBICS-Übertragungsprogramm wie bisher immer nur dann, wenn es benötigt wird, in den Speicher geladen wird.

Hi!

Hab den Tipp mit dem Eintrag "EBICS_START=0" in der WPC.ini auch gerade eben von der Bank bekommen. Erste Aussagen sind wohl, dass das Programm wieder wie gewohnt läuft, also schneller, aber genaues kann ich erst morgen sagen. Werde natürlich dann gleich das Ergebnis bekannt geben!

stimmt, da hab ich gar nicht drangedacht, aber is logisch!

Was ist daran logisch?

Ohne den INI-Eintrag wird der Kernel schon beim Starten des Programm geladen, mit dem Eintrag erst beim Beginn einer EBICS-Übertragung.
Logisch erscheint mir da viel eher, dass es ohne den INI-Eintrag schneller geht als mit (was ja wohl auch der Sinn dieser Änderung in Profi cash war...).

Edit: Sorry, was Produktives kann ich leider nicht beitragen, weil ich mir das ganze Verhalten nicht erklären kann....

Bratwurst, wäre dann nicht logischer, dass die benötigte Zeit für das Laden einfach nur verschoben wird und zwar a) mit Eintrag 0 auf den Beginn der Übertragung und b) mit Eintrag 1 auf den Programmstart?

Warum sollte das Kernel laden schneller werden, weil es zu einem anderen Zeitpunkt stattfindet?

Die objektive Zeit für das Laden des Kernels bleibt natürlich immer gleich.
Wichtig ist, dass die subjektive Zeit bis zum Start einer Datenübertragung aber sehr viel kürzer ist, wenn der Kernel schon im Speicher ist. Die Zeit beim Programmstart spielt das aus Anwendersicht keine so große Rolle.

Was glaubst du, warum Firefox und OpenOffice so viel Zeit beim Start benötigen?

Und ehe der Eindruck entsteht, dass ich würde gegen die OpenSource-Welt lästere noch eine kurze Ergänzung:
Die Gegenstücke von MS starten schneller, aber auch nur deshalb, weil Teile von deren Laufzeitzumgebung schon bei Windows-Start in den Speicher geballert werden.

:moin:

Hab gerade mit dem Kunden gesprochen, an der Übertragung hat sich leider nichts geändert.
Hätte ich aber ehrlich gesagt auch komisch gefunden aus dem gleichen Grund wie M. Döring

Moin,

kapiert hab ich die Funktion auch nicht, aber ein Versuch war´s wert

Wenn ich hier so lese Port 443......
Irre ich mich jetzt komplett oder läuft eine Terminalserver-Session auch auf 443? Und läuft nicht alles mögliche rund um SSL auch auf 443?
Kann es nicht sein, dass da einfach zuviel los ist?
Gibt es die Möglichkeit, mal testweise den Datenabruf per EBICS nicht von einem Terminalserver-Client sondern auf dem Server auszuführen? Also quasi eine Client-Profi-Cash Installation auf dem Server und Abschaltung aller Terminalserver-Komponenten, damit keine Session läuft?

Ne, der RDP-Port ist 3389, es sei denn man ändert den.
Überlastung auf einem bestimmten Port kann ich mir allerdings gar nicht vorstellen, demnach müsste auf 80 ständig Stau sein

Cpt. Frag, ich habe schon Dinge gesehen, die anfangs jeder für unmöglich gehalten hat und hinterher gabs das große Staunen und Raunen. Ist auch nur das berühmte Stochern im Nebel. Nur irgendwo muss man ja mal anfangen. Durch darüber nachdenken allein behebt sich das Problem ja nicht

<-- Dann wäre das Problem schon gelöst
Leider weiß der Bankmensch nicht mehr so recht weiter, es eskaliert sich gerade in irgendein Bank-Rechenzentrum. Mal schauen. Auf dem Server zu testen wäre natürlich eine Möglichkeit, muss mir dazu nur so eine Diskette "besorgen".... Ich meld mich wieder!