|
| Von:Olaf Doschke b2xhZkBkb3NjaGtlLm5hbWU@strconv.14.de An:Thomas Ganss tganss_at_t_dash_online_dot_de-remove-all-after-fi |
| erstellt am:24.01.2011 10:11:54
- #14697 in section
Antworten Antworten mit Zitat
--from Newsreader at Montag, 24. Januar 2011; 10:11:54-- >> >>Du kannst z.B. mal das Artikelstammformular per SET COVERAGE seine >> performance im einzelnen loggen lassen<< >> >> Vielen Dank für den Tip. Werde ich versuchen. Ich erstelle gerade diese >> Maske neu, hoffe das bringt mich auch weiter. >Wenn Du mit CA arbeitest, ist IMHO die bequemste Art, derartige Sachen >zu finden, ein Logging das in der CA Basisklasse alle Bulk-Kommunikation >zur Basistabelle mitscreibt. * Coverage an SET COVERAGE TO Datei ADDITIVE *Coverage aus SET COVERAGE TO Und das möglichst als Klammer um den Code, der die Daten holt. Du kannst aber durchaus auch alles bis Ende des Inits loggen lassen, alos im Load() oder im DE BeforeOpenTables() an und am Ende des Init() aus. Die erstellte Logdatei kann man per Coverage Profiler auswerten, sich da etwas besseres suchen oder einfach selbst die Rohdaten in einen Cursor ziehen: Create Cursor curCoverage (bExecTime B, cClass C(128), cMethod C(128), iLine I, cFile C(254), iStacklevel I) Set Point To '.' Append From coverage.log Type CSV Select * From curCoverage Order By iStacklevel, bExecTime Descending Stacklevel ist hilfreich, weil Coverage einen Datensatz pro Codezeile loggt, also auch für Aufrufe von Methoden. Rein nach Zeit absteigens sortiert findest Du als dicken Brummer dann u.U. einen Methodenaufruf, nicht die einzelne bremsende Zeile innerhalb der aufgerufenen Methode. Je exakter Du also das Logging bei den interessanten Codestellen an- und abschaltest, je einfacher dann, den Flachenhals zu finden. Interessant ist natürlich z.B. auch Select Sum(bExecTime), cFile, cMethod, iLine ... Group By cFile, cMethod, iLine Tschüß, Olaf. |
| Von:Thomas Ganss tganss_at_t_dash_online_dot_de-remove-all-after-fi An:Jörg Richter joerg.richter@chello.at :gelesen |
| erstellt am:23.01.2011 12:21:41
- #14695 in section
Antworten Antworten mit Zitat
--from Newsreader at Sonntag, 23. Januar 2011; 12:21:41-- Jörg Richter schrieb: > Hallo Olaf, > > >>Du kannst z.B. mal das Artikelstammformular per SET COVERAGE seine > performance im einzelnen loggen lassen<< > > Vielen Dank für den Tip. Werde ich versuchen. Ich erstelle gerade diese > Maske neu, hoffe das bringt mich auch weiter. Wenn Du mit CA arbeitest, ist IMHO die bequemste Art, derartige Sachen zu finden, ein Logging das in der CA Basisklasse alle Bulk-Kommunikation zur Basistabelle mitscreibt. my 0.05 (been there, done that...) tg |
| Von:Jörg Richter joerg.richter@chello.at An:Olaf Doschke b2xhZkBkb3NjaGtlLm5hbWU@strconv.14.de |
| erstellt am:22.01.2011 14:47:19
- #14694 in section
Antworten Antworten mit Zitat
Hallo Olaf, >>Du kannst z.B. mal das Artikelstammformular per SET COVERAGE seine performance im einzelnen loggen lassen<< Vielen Dank für den Tip. Werde ich versuchen. Ich erstelle gerade diese Maske neu, hoffe das bringt mich auch weiter. |
| Von:Olaf Doschke b2xhZkBkb3NjaGtlLm5hbWU@strconv.14.de An:Jörg Richter joerg.richter@chello.at :gelesen |
| erstellt am:22.01.2011 13:51:24
- #14693 in section
Antworten Antworten mit Zitat
--from Newsreader at Samstag, 22. Januar 2011; 13:51:24-- >>>Und 16 nicht? Und diese 16 haben Performanceprobleme?<< >Ja genau die. Ich kann das Programm von meinen Büro aus auch über VPN >starten und habe keine Probleme. Na dann liegt wOODy ja richtig. Dann liegts an schlechter optimierung und Indizierung der Daten. So daß lokaler vs Zugriff über Netzwerk die Performance hauptsächlich beeinflußt. Die anderen dann auch über RDP Client arbeiten zu lassen wäre dann wohl die schnelle Lösung. Performanceoptimierung die langfristige. Indizes sind dabei nur ein Thema. VFX sollte per se keine riesigen Probleme verursachen, sonst wäre es als Framework nicht tragfähig. Aber gerade für Datenindizierung zur Optimierbarkeit von Abfragen wirst Du schon selbst zuständig sein. Du kannst z.B. mal das Artikelstammformular per SET COVERAGE seine performance im einzelnen loggen lassen. Das läuft sogar innerhalb der EXE, verlangsamt zwar nochmal im Moment der Analyse, erlaubt Dir dann aber die Methoden und SQLs, Views oder was auch immer aufzufinden, die langsam laufen. Tschüß, Olaf. |
| Von:Jörg Richter joerg.richter@chello.at An:Olaf Doschke b2xhZkBkb3NjaGtlLm5hbWU@strconv.14.de |
| erstellt am:22.01.2011 08:31:05
- #14691 in section
Antworten Antworten mit Zitat
Hallo Olaf >>Und 16 nicht? Und diese 16 haben Performanceprobleme?<< Ja genau die. Ich kann das Programm von meinen Büro aus auch über VPN starten und habe keine Probleme. |
| Von:Olaf Doschke b2xhZkBkb3NjaGtlLm5hbWU@strconv.14.de An:Jörg Richter joerg.richter@chello.at :gelesen |
| erstellt am:21.01.2011 08:00:10
- #14690 in section
Antworten Antworten mit Zitat
--from Newsreader at Freitag, 21. Januar 2011; 08:00:10-- Hallo Jörg, >>>>Ist es vielleicht eher so, dass das Programm zwar auf dem TS abgelegt >>>>ist, >>aber von Anwendern im lokalen Netzwerk tatsächlich auf ihren Rechnern >>ausgeführt wird?<< >Von 20 Workstation gehen 4 über ein RDP-Fenster rein. Und 16 nicht? Und diese 16 haben Performanceprobleme? Tschüß, Olaf. |
| Von:Jörg Richter joerg.richter@chello.at An:Jürgen_Wondzinski juergen@wondzinski.de |
| erstellt am:21.01.2011 07:28:39
- #14689 in section
Antworten Antworten mit Zitat
Hallo wOOdy, Vielen Dank für die Erklärung. >>Ist es vielleicht eher so, dass das Programm zwar auf dem TS abgelegt ist, aber von Anwendern im lokalen Netzwerk tatsächlich auf ihren Rechnern ausgeführt wird?<< Von 20 Workstation gehen 4 über ein RDP-Fenster rein. |
| Von:Jürgen_Wondzinski juergen@wondzinski.de An:Jörg Richter joerg.richter@chello.at :gelesen |
| erstellt am:20.01.2011 12:12:23
- #14683 in section
Antworten Antworten mit Zitat
--from Newsreader at Donnerstag, 20. Januar 2011; 12:12:23-- Hallo Jörg, wenn das Programm auf dem Terminalserver (also in einer Server-Sitzung) ausgeführt iwrd, sollte es ziemlich schnurz sein, ob die Bildschirm-Spiegelung via VPN-Netzwerk oder internem Netzwerk an den Client übertragen wird. Zumindest kann ich mir keinen technischen Grund vorstellen. Ein RDP-Client am TS ist immer via Netzwerk angebunden, und ob das Netzwerk nun nur intern geroutet ist oder irgendwie (zb via VPN) auch nach ausserhalb geht, ist der eigentlichen TS-Session schnurz. Ist es vielleicht eher so, dass das Programm zwar auf dem TS abgelegt ist, aber von Anwendern im lokalen Netzwerk tatsächlich auf ihren Rechnern ausgeführt wird? Sobald die EXE direkt auf deren Desktops läuft, anstelle in einem RDP-Fenster, hat das nix mit TerminalServer zu tun... -- wOOdy Servoy und Visual FoxPro Technologieberater Microsoft "Most Valuable Professional" 1996 bis 2009 "*´¨) ¸.·´¸.·*´¨) ¸.·*¨) (¸.·´. (¸.·` * ...·`.Visual FoxPro: It's magic ! (¸.·``··* Servus wOOdy Lianja, Servoy und Visual FoxPro Technologieberater Microsoft "Most Valuable Professional" von 1996 bis 2009 Servoy Valued Professional 2011 "*´¨) ¸.•´¸.•*´¨) ¸.•*¨) (¸.•´. (¸.•` * .•`.Visual FoxPro: It's magic ! (¸.•``••* Servus |
| Von:Jörg Richter joerg.richter@chello.at An:All :gelesen |
| erstellt am:15.01.2011 10:13:25
- #14658 in section
Antworten Antworten mit Zitat
Hallo zusammen, Ich habe bei einen Kunden folgendes Problem: Programm (mit VFX erstellt) und Daten sind auf einem Terminalserver installiert. Etwa 20 Leute arbeiten täglich mit dem Programm. Davon 3 über VPN u. 17 direkt über das Netzwerk. In einer einzigen Form (Artikelstamm - 8.000 Sätze - 27 Dateien werden geöffnet - optimistisches locking) dauert das Öffnen der Form und das speichern eines Datensatzes bis zu 2 Minuten. Allerdings nur über das Netzwerk. Über VPN gibt es keine Probleme (auch ich kann vom Büro aus über VPN ohne Probleme arbeiten). Mir fehlen leider die nötigen Hardwarekenntnisse um das zu erklären. Kann man da an irgen etwas schrauben oder auf was muß ich bei der eventuellen Neuprogrammierung der Form achten? |