Client/Server-Performanceprobleme



  • Ich suche Literatur aber auch konkrete Techniken zum Thema "Client/Server-Systeme und Performance".

    Bei einigen Projekten in meinem Umfeld habe ich schon gesehen, dass es inzwischen selbst (oder gerade für) kleinste Firmen nötig ist auf ihr System von überall zugreifen zu können. Da wird schnell mit C# und MSSQL ein Server gebastelt und dazu ein Client.

    Leider kommt es da sehr schnell zu Performanceproblemen. Man kann das ganze natürlich auch als Web-Anwendung anlegen, aber das ist oftmals auch nicht optimal. (Andere Frage: Denkt ihr zukünftig werden die meisten "Business-Anwendungen" web-basiert sein? SAP? Oracle MS Dynamics?

    Naja jedenfalls suche ich hier Literatur wie man die Performance steigern kann. Von Caches über Daten offline replizieren bis hin zu "im Hintergrund nachladen", etc. etc.

    MfG SideWinder



  • SideWinder schrieb:

    Leider kommt es da sehr schnell zu Performanceproblemen.

    Ich würd sagen dann ist die Anwendung schlecht gemacht oder die Putzfrau hat beim Saugen wieder das Netzwerkkabel aus der Dose gezogen

    (Andere Frage: Denkt ihr zukünftig werden die meisten "Business-Anwendungen" web-basiert sein? SAP? Oracle MS Dynamics?

    Ja, selbstverständlich, viele sind ja schon längst Webanwendungen (Salesforce, Sharepoint, etc...)



  • schmaler breiter kleiner schrieb:

    SideWinder schrieb:

    Leider kommt es da sehr schnell zu Performanceproblemen.

    Ich würd sagen dann ist die Anwendung schlecht gemacht oder die Putzfrau hat beim Saugen wieder das Netzwerkkabel aus der Dose gezogen

    Ist nicht wahr. Und jetzt kommt's, bei meinen Projekten will ich dagegen mit Wissen vorbeugen. Deswegen ja auch der ganze Thread.

    MfG SideWinder



  • SideWinder schrieb:

    schmaler breiter kleiner schrieb:

    SideWinder schrieb:

    Leider kommt es da sehr schnell zu Performanceproblemen.

    Ich würd sagen dann ist die Anwendung schlecht gemacht oder die Putzfrau hat beim Saugen wieder das Netzwerkkabel aus der Dose gezogen

    Ist nicht wahr.

    Der Thread hört sich eher so an als ob du meintest Performenceprobleme seien inhärent bei solchen Webanwendungen. Wenn dem nicht so wäre, würdest du aber nicht nach spezieller Literatur für sowas fragen, da bei Webanwendungen natürlich genau die gleichen Performance Techniken zum tragen kommen wie bei stinknormalen Clientanwendungen und anderen Datenbankanwendungen und anderen Netzwerkanwendungen.



  • Also erstmal kommt es darauf an wieviele Nutzer gleichzeitig auf der Plattform sind.

    Recht easy heute:

    Windows Server R2 mit IIS, MSSQL
    MSSQL wird repliziert auf X Server

    Problem sind heute nicht die Webserver sondern das RDBMS.
    Je nach Replikation kann man von verschiedenen Servern abfragen oder eben einer zum schreiben und der Rest zu lesen.
    Reicht der Webserver mit den Anfragen nicht aus hängt man einen 2. 3. etc. rein.
    Das ganze per HardwareLoadbalace.
    Das sollte mal ausreichen für den Mittelstand.
    Problem heutzutage mit WEB ist eher das man einen MySQL verwendet der mit der Anzahl nicht klar kommt und alle verwenden ID und Autowert um etwas abzubilden.
    Da ist dann nur eine Select/INSERT möglich.
    Besser ist es alle Server als INSERT und SELECT zu verwenden.
    Man sollte auch ONTHEFLY nicht zu viele Grafiken erstellen.



  • schmaler breiter kleiner schrieb:

    Der Thread hört sich eher so an als ob du meintest Performenceprobleme seien inhärent bei solchen Webanwendungen. Wenn dem nicht so wäre, würdest du aber nicht nach spezieller Literatur für sowas fragen, da bei Webanwendungen natürlich genau die gleichen Performance Techniken zum tragen kommen wie bei stinknormalen Clientanwendungen und anderen Datenbankanwendungen und anderen Netzwerkanwendungen.

    ich denke nicht dass client anwendungen dieselben probleme haben wie server. Als biespiel: auf client seite nutzen die wenigsten SQL datenbanken um daten abzulegen, auf server seite meinen die meisten dass das noetig waere. wenn dazu noch ein paar andere langsame/generische loesungen dazukommen, kann man schnell in probleme laufen, die eine simple client applikation nicht kennt.

    ich denke, das wichtigste um gute software zu haben ist erfahrung (wichtiger als wissen aus buechern). Da man nicht alle erfahrungen selber machen kann, ist es oft besser bekanntes wissen zu nutzen, deswegen wuerde ich in so kritischen faellen eher bestehende software evaluieren, ein unternehmen mit erfahrung beauftragen sich darum zu kuemmern, einen consultant bestellen oder jemanden mit erfahrung einstellen.



  • Es ist sicherlich eine Mischung: wenn der Server langsam ist, ist die Auswirkung auf dem Client, eine langsame Datenverarbeitung. Ist der Client langsam, nützt der schnellste Server nichts.

    Ich habe hier Erfahrung mit allen möglichen Konstellationen: Mainframe (DB2, IMS) mit 3270-Terminal, Mainframe mit Java-Client (dazwischen ein selbst entwickelter XML-Gateway) und Mainframe mit Web-Client. Aber auch SQLServer mit Web-Client, SQLServer mit Java-Client.

    Man muß der Mainframe+3270 Kombination eines lassen: suuuuper schnell! Egal ob der User am Standort oder auf der anderen Seite des Atlantiks sitzt. Und wir haben hier nicht wenig Daten. 😮 Du gibst einen Schlüssel ein, drückst ENTER, und nicht mal einen Wimpernschlag später hast du die Daten. Durch scrollen durch Datensätze geht genauso schnell. Und man beachte, das so ein 3270-Terminal nichts vorlädt oder puffert. Es ist dumm wie Brot. Der Mainframe ist nur am Ackern. Egal ob die User in den Produktionsstandorten, bei den Autohändlern, externe Logistik, usw.

    Sobald aber sowas wie XML-Gateway, Java-Client, HTML und HTTP ins Spiel kommt, wird alles irgendwie träge. Die Antwortzeiten dauern spürbar länger. Dabei spielen mehrere Stationen eine Rolle. Angefangen beim lokalen, den lokalen Libs, ein Gateway oder die Java-Storedprocedure auf dem Mainframe (DB2). Am Ende gewinnt immer COBOL auf Mainframe-DB2 und der native Terminal. COBOL ist zwar uncool und unmodern, aber es darf hier keinen Ausreißer geben.

    Du kannst bei einem C#/Java-Client durch Chaching und Preload was raus holen, aber es ist immer nur ein Eingeständnis. 😉



  • Hmm, vielleicht ist es nicht durchgekommen, aber es handelt sich schon um klassisches Client/Server und nicht Web.

    Als Frontend, auch wen Artchi davon performancemäßig abrät, würden es definitiv Java/C#-Clients sein, als Server würde ich die jeweils selbe Sprache wählen, übergreifende Remote-Sachen sind meistens weniger performant (CORBA oder gar WebServices vs pure RMI bei Java bspw.).

    Also was kann man in diese Richtung machen?

    Edit: Die Clients die ich gesehen habe, haben soweit keine Performanceprobleme, es dauert nur oftmals sehr lange bis Suchabfragen oder große Ergebnislisten vom Server da sind. Jetzt weiß ich als Laie natürlich noch nicht ob sich das im Bereich Übertragungsmenge oder Art der Übertragung abspielt. Weiters dauern natürlich auch oftmals die einzelnen Abfragen lange, etc.

    Irgendwie muss man sich dann immer von "schönem" OO-Desgin verabschieden um performant zu bleiben, also sucht man nach Best Practices, Patterns, etc. in diesem Bereich.

    MfG SideWinder



  • SideWinder schrieb:

    Als Frontend, auch wen Artchi davon performancemäßig abrät, würden es definitiv Java/C#-Clients sein, als Server würde ich die jeweils selbe Sprache wählen, übergreifende Remote-Sachen sind meistens weniger performant (CORBA oder gar WebServices vs pure RMI bei Java bspw.).

    Mit "nativ" meinte ich nicht Maschinencode anstatt Bytecode. Ich meinte die reinen Daten zwischen Client und Server. Diese sollten nativ sein und nicht noch tausend mal umgewandelt werden, wie wir das hier teilweise haben. Wie gesagt, wenn ich auf den Mainframe nativ zugreife, ist das schneller, als wenn ich das über das XML-Gateway mache, wo das Gateway die nativen Daten in XML wandeln muß, und der Java-Client wieder das XML in Objekte umwandeln muß. Rückweg genauso.

    Aber wenn ich das so überschlage, weiß ich nur eines: der Server muß schnell sein. Also nicht nur die Hardware (Mainframe ist natürlich optimal), sondern auch das Tabellendesign und die STPs müssen schnell sein. Wir nutzen hier in unserer Abteilung nur COBOL für die STPs. Obwohl seit ein paar Jahren auch auf dem Mainframe Java vom Konzern erlaubt wird. Aber die meisten Abteilungen schwören hier weiter auf COBOL, nicht nur bei Altsystemen.

    Und wenn du sagst, das einzelne Abfragen lange dauern, dann ist wahrscheinlich an den STPs und Tabellen was faul? Dafür braucht man wirklich Leute mit Knowhow. Ich selber bleibe Client-Progger und lasse meine Host-Kollegen ihre DB2-Arbeit. Die wissen, was sie zu tun haben.

    Ich schüttele immer mit dem Kopf, wenn ich Job-Anzeigen sehe, in denen Client-Programmierer auch noch RDBMS-Kenntnisse mitbringen müssen/sollen. So was kann nur in langsamen Datenabfragen enden.

    Nutzt ihr denn STPs oder wenigsten Prepared Statements?



  • Artchi schrieb:

    SideWinder schrieb:

    Als Frontend, auch wen Artchi davon performancemäßig abrät, würden es definitiv Java/C#-Clients sein, als Server würde ich die jeweils selbe Sprache wählen, übergreifende Remote-Sachen sind meistens weniger performant (CORBA oder gar WebServices vs pure RMI bei Java bspw.).

    Mit "nativ" meinte ich nicht Maschinencode anstatt Bytecode. Ich meinte die reinen Daten zwischen Client und Server. Diese sollten nativ sein und nicht noch tausend mal umgewandelt werden, wie wir das hier teilweise haben. Wie gesagt, wenn ich auf den Mainframe nativ zugreife, ist das schneller, als wenn ich das über das XML-Gateway mache, wo das Gateway die nativen Daten in XML wandeln muß, und der Java-Client wieder das XML in Objekte umwandeln muß. Rückweg genauso.

    das ist eher fall abhaengig. wenn man auf kompatibilitaet und einfachheit setzt, kann xml wieder besser sein. ein server sollte nicht durch parsen von xmls ans limit kommen, denn dann liefe etwas komplett falsch in der architektur. Ich hab hier einen server der 2Mio-10Mio request in 10min bekommt und der nutzt einfach nur TinyXML und hat selten mehr als 8% cpu auslastung (dual socket quad-core xeon mit 2Ghz), beim profiling ist davon <1% tinyxml, und das obwohl ein request 200byte bis 100kb+ sein kann.

    Und wenn du sagst, das einzelne Abfragen lange dauern, dann ist wahrscheinlich an den STPs und Tabellen was faul? Dafür braucht man wirklich Leute mit Knowhow. Ich selber bleibe Client-Progger und lasse meine Host-Kollegen ihre DB2-Arbeit. Die wissen, was sie zu tun haben.

    ganz meine meinung. und gleich hinter experten wuerde ich 'tools' einordnen. nicht zu wissen wo etwas schief geht, oder was langsam ist, oder in welchen situationen dinge nicht mehr laufen wie man es erwartet kann nur durch gute tools beseitigt werden.

    Im beispiel von sidewinder, wo requests manchmal ewig dauern, waere es schon gold wert in die requests time tags zu integrieren. abschick zeit client, empfangszeit server, ruecksende zeit server und empfangszeit client. daraus koennte man schon erheblich das bottlenck einkreisen. und diese statistiken sollten nicht nur bei problemen an sein, sondern immer und von einem unabhaengigen network monitoring tool beobachtet werden und bei abweichungen (z.b. per mail) alarm schlagen, noch bevor es so schlimm ist, dass es clients merken und sich beschweren.

    Ich schüttele immer mit dem Kopf, wenn ich Job-Anzeigen sehe, in denen Client-Programmierer auch noch RDBMS-Kenntnisse mitbringen müssen/sollen. So was kann nur in langsamen Datenabfragen enden.

    ich halte es nicht verkehrt wenn die auf client seite sich mit den server leuten ueber grundlegende dinge unterhalten koennen. manchmal braucht es ewig viel arbeit auf server seite etwas zu umschiffen (z.b. eben caching), was manche auf clientseite einfacher loesen.



  • rapso schrieb:

    ich halte es nicht verkehrt wenn die auf client seite sich mit den server leuten ueber grundlegende dinge unterhalten koennen. manchmal braucht es ewig viel arbeit auf server seite etwas zu umschiffen (z.b. eben caching), was manche auf clientseite einfacher loesen.

    Klar, du mußt dich mit den Kollegen der anderen Seite unterhalten können. Schon alleine deshalb, damit sie einem Fehler, die auf dem Client sichtbar werden, nicht gleich anhängen... obwohl der Fehler den Ursprung auf dem Server hat. 😉

    Aber solche Job-Anzeigen suggerieren mir meistens, das der Client-Entwickler bitte auch gleich die DB-Programmierung/Design übernehmen soll, weil man sich das Geld für einen entsprechenden Mitarbeiter sparen will. Weil ich ehrlich gesagt noch nie jemand gesehen habe, der beide Techniken gleich gut oder besser sehr gut kann. Entweder jemand macht jeden Tag 8 Std. DB oder Client. Alles andere ist nicht optimal. Oder täusche ich mich da?


Anmelden zum Antworten