On Sunday 04 March 2001 18:19, Reinhard Foerster wrote:
On Sun, Mar 04, 2001 at 10:50:01AM +0100, Konrad Rosenbaum wrote:
Nun, eigentlich auch kritische. Aber die Dimensionierung des Systems muss anders gemacht werden (diese Bedingungen würde ich auch an fork-OOM-Systeme stellen): *der Speicher muss auch für unwahrscheinliche Szenarien reichen
Nein. Wozu?
Damit es nicht zu OOM-Szenarien kommen _kann_.
*genug Rechenpower für extremen Traffic
Nein. Wozu?
Hat mit OOM nix zu tun, macht sich in der Praxis aber sicher besser, da weniger User die Geduld verlieren und durch Reloads alles noch schlimmer machen.
*mehrfache Filterung durch Firewalls (DMZ-Prinzip)
völlig off topic
Wie kommst Du darauf? Die Idee ist ganz einfach: je besser die Firewall filtert um so weniger muss sich der Server um Müll auf Ports kümmern, die eigentlich nicht für "draußen" bestimmt sind. Und umso weniger Spoofing kommt durch und belastet den Server durch sinnlose Routing-Einträge und sinnlos gestartete Server-Prozesse.
Ein nicht unerheblicher Teil der Attacken beruht auf Spoofing und anderen Prinzipien, die effektiv durch eine Firewall abgeblockt werden können.
*DB läuft auf einem anderen Rechner als der Webserver
Nein. Wozu? (dadurch habe ich lediglich das gleiche Problem an 2 stellen)
Falsch: Du hast die Wahrscheinlichkeit verringert, dass eine Fehlfunktion (egal ob Bug oder durch overload erzeugt) des einen Servers den anderen mit in die Tiefe zieht.
Ich habe keine blassen Schimmer, weshalb du solche Dinge forderst. Vor allem verstehe ich nicht, warum du immer was von CPU/Rechenpower erzählst?
s.o.
IMHO ist der Punkt bei beiden Systemen: sie müssen in kritischen Sektionen so gestaltet sein, dass es bei High-Traffic weder zu CPU-Engpässen, noch zu OOM's kommt.
Es ist völlig schnuppe, wie schnell die CPU ist. Von Echtzeit war bisher nie die Rede. Ob die Kiste schnell oder langsam arbeitet hat mit Korrektheit _nichts_ zu tun. (modulo ein paar Timingsachen in einigen Protokollen, die aber aus CPU-Sicht völlig unkritisch sind)
In der Theorie (Stichwort "Korrektheit") hast Du natürlich vollkommen recht: man kann durchaus ein Weltwunder einsetzen, wo es eine dickere Mauer auch getan hätte. ;-)
Wir scheinen hier zwei sehr gegensätzliche Herangehensweise zu haben (wen wunderts): RF: es ist möglich ein korrektes System zu schaffen, dass theoretisch nicht crashen kann KR: Programmierer sind alles andere als perfekt, also spielen wir hier mit Wahrscheinlichkeiten, die auf unterschiedlichen Wegen verändert werden können.
Sicher kann man einen Rechner auch dadurch lahmlegen, daß man die CPU zu irgendwelchen Sachen zwingt, die nicht beabsichtigt waren. Mit dem Thema des Threads "speicher" hat das absolut nix zu tun und macht die Diskussion nur unübersichtlicher. Genauso das Firewallzeugs - was soll das? Was das Kernthema betrifft, hast du mir ja in deinem letzten Posting bereits zugestimmt. Jetzt muss ich nur noch Torsten bearbeiten :-)
Mathematisch ausgedrückt: der Punkt des aktuellen Optimums sollte möglichst nie die Randbedingungen berühren müssen.
Ooops, ich habe deine Mathe-Ausflüge zwar nur flüchtig überflogen, an eins kann ich mich aber noch erinnern: Bei einem Optimierungproblem liegt die optimale Lösung immer auf einer oder meheren Randbedingungen, also in einer Ecke des Lösungsraums. Würde das Optimum keine Randbedingungen berühren, wäre keine der Randbedingungen wirklich relevant für das Problem und somit das ganze Optimierungsproblem sinnlos. (Nenne die nat. Zahl 30, die zwischen 20 und 40 liegt :-)
Eben: mein Ansatz ist es die Randbedingungen (Hardwarebeschränkungen) zu beseitigen. Deiner ist es scheinbar ein Optimum auf den Randbedingungen zu finden.
Es handelt sich dann natürlich nicht mehr um ein klassisches Optimierungsproblem, da der Anteil "Problem" fehlt(*).
(*)Zugegeben es taucht ein anderes auf: Finanzierung.
Konrad