Hallo,
Geh nicht nur auf die absoluten Werte los. Untersuch doch mal, ob Netzwerkkarte, Plattensystem, Prozessor etc. Warteschlangen haben. Ich halte mich da immer an den Performanceguide in der Technischen Referenz.
Mit SQLServer kenn ich mich leider kaum aus. Aber ein schlecht designter SQLServer (tempdb, Systemdatenbank, Transaktionsprotokolle etc) kann einem die Performance jedenfalls auch verhageln.
Bestimmt gibts für SQL ebenso Performanceguides.
die Festpaltten (wenn du es meinst) sind ein RAID5
Wenn einem Geschwindigkeit wichtig ist, dann setzt man kein RAID5 ein. Das ist das langsamste RAID, was Du haben kannst.
Und beim SQL-Server sollte man auch die DBs und die LOGs auf unterschiedliche Datenträger legen. Auch eine andere Partition reicht da nicht aus, da es ja trotzdem die gleichen Schreib/Leseköpfe bleiben .
Ob das jetzt alleine für Deinen Flaschenhals verantwortlich ist, weiß ich allerdings auch nicht.
Wie ist es mit der üblichen Hauptverdächtigen, der Namenauflösung, könnte die eine Rolle spielen?
Wie ist denn die Namenuflösung realisiert?
Könnte die Einstellung flow control des Netzwerkinterfaces eine Rolle spielen?
solche Sachen werden von dem Rechenzentrum geregelt und wir haben gar keinen Einfluss drauf (glaube ich zumindest). Unsere Rechner bekommen immer eine IP vom Rechenzentrum, die wir in die Einstellungen der Netzwerkkarte eintragen. Wie dort (RZ) die Namensauflösung realisiert ist, weiß ich leider nicht.
Der DBserver wird aber direkt über seine IP angesprochen. Das Ganze läuft über FreeTDS (linux - windows Schnitstelle für PHP-SQL).
Geh nicht nur auf die absoluten Werte los. Untersuch doch mal, ob Netzwerkkarte, Plattensystem, Prozessor etc. Warteschlangen haben. Ich halte mich da immer an den Performanceguide in der Technischen Referenz.
Wenn die Daten zurückkommen ist ein Kern der CPU immer voll ausgelastet. Das haben wir schon gemerkt. Aber die CPU übernimmt dann die Aufgaben des LAN-Chipsatztes oder hilft der RAID-Karte. Wenn erste - dann hilft eventuell der Kauf einer extra 1G LAN-Karte (Oder?). Wenn zweite - dann ist die dedizierte RAID-Karte einfach zu schlecht. Wofür ist die dann überhapt da wenn die CPU für sie noch was macht?
Wenn einem Geschwindigkeit wichtig ist, dann setzt man kein RAID5 ein. Das ist das langsamste RAID, was Du haben kannst.
Und beim SQL-Server sollte man auch die DBs und die LOGs auf unterschiedliche Datenträger legen. Auch eine andere Partition reicht da nicht aus, da es ja trotzdem die gleichen Schreib/Leseköpfe bleiben .
DA kann ich auch nicht viel zu sagen. Mir ist grade aufgefallen: könnte es an den Einstellungen des Controllers liegen? Wie z.B Buffer Size oder was da gibt?
Kannst du den Ausführungsplan des SQL Querys zeigen, welches so langsam geht?
Geht Dateiübertrgaung (z.B. per SCP) vom DB Server zum Webserver (und anderst herum) schneller?
EDIT:
Zitat von Bioinformatiker
z.B. die Übertragung der Abfrage Select * From TableBig dauert derzeit 12 Sek - es sind ca. 300 MB.
Wenn es aber keine Geschwindigkeitsbegrenzung gäbe, würden die gleichen Daten innerhalb von vier (4) oder sogar weniger Sekunden übertragen.
Ach ja. Wo wird dieses Testquery ausgeführt? Auf dem DB oder auf dem Webserver? Gibt es Unterschiede bei beiden Fällen?
Kannst du den Ausführungsplan des SQL Querys zeigen, welches so langsam geht?
Geht Dateiübertrgaung (z.B. per SCP) vom DB Server zum Webserver (und anderst herum) schneller?
Was meinst du mit dem Ausführungsplan? Select * FROM TabelleGroß - Das sind 1.800.000 Zeilen und glaube maximal 20 Spalten (bin grade zuhause). Alle Werte sind entweder Int, Float oder VARCHAR (bis 400).
Oder willst du sehen wie SQL-Statement vom Query-Prozessor in die relationalle Algebra umgewandelt wird?
SCP habe ich nicht getestet, jedoch iperf zeigt ungefähr die gleichen Werte (wie ich oben schrieb). Jedoch SCP (Backup) zwischen dem Webservern (1 und 2) läuft bei 65-75 MB/S (also bis 550 Mbit/S), wähgrend iperf bis 950 schafft (da vlt nur den Arbeitspeicher dafür nutzt und nix auf die Festplatten schreibt). Also hätten wir eine der SCP ähnliche Geschwindigkeit zw DB und WEbserver wäre es schon OK. Aber es sind leider 160-180 MBit/S.
Ernsthaft: Ich empfehle ein Seminar für den SQL-Server. BTW: Warum sollte ein Webserver ständig Select * Abfragen machen ?
Oh Gott. Mir reicht es dass ich RDB (relational databases) 1 und RDB (Entwurf) 2 vertieft habe (Technische Universität). Natürlich muss der Webserver keine solche Abfragen machen. Es war bloß ein Beispiel um zu zeigen dass mehrere Megabytes zusammenkommen.
Wenn du es empfiehlst dann eine Frage: Hast du selber Ahnung in SQL (meine aber nicht böse).
ICh sage nicht dass ich ein DB-Profi bin, aber ich habe genug Erfahrung mit den Datenbanken. Erkläre nun in welchem Fall viele Daten gesammelt werden. Select Spalte 1, Spalte 2, Spalte 3, Spalte 4, Spalte 5, Spalte 6, From View1 UNION ALL Select Spalte 1, Spalte 2, Spalte 3, Spalte 4, Spalte 5, Spalte 6, From View2 UNION ALL Select Spalte 1, Spalte 2, Spalte 3, Spalte 4, Spalte 5, Spalte 6, From View2 Und ja dazu kommen noch fünf bis zehn where Bedingungen, sowie Order By. In diesem Fall dauert selbst die Abfrage zienlich lang aber auch die Übertragung nimmt genug Zeit (10-15 Sekunden in Anspruch). Ich wollte oben nur vereinfachen.
Und so mamchmal bis 5 Views (Sichten - d.h. Gejointe Tabellen).
Diese Daten werden für spätere Modellierung benötigt. So kommen manchmal einige hundert Megabytes zusammen (also bis 2 GB)
Natürlich könntest du die Frage stellen: wie lange das Ganze dauert? Das ist doch ein Web-Interface? Ja zu recht. Aber die Menschen die das benutzen wissen schon vorher das es einige Minuten dauern kann und sind bereit zu warten.
Bitte mach keine Empfehlungen wenn du nicht weißt was die Menschen können, selbst wenn du ein Expert Member bist
Dieses Testbeispiel. Wo hast du es ausgeführt und die langsamen Werte herausbekommen?
Auf dem DB Server oder auf dem Webserver? Wenn auf dem Webserver, kannst du das selbe auf dem DB Server testen und schauen ob das genauso langsam ist?
. 
(meine aber nicht böse).
