Re: WebApplication und Betriebssystem Performance Fragen.

On Sat, 17 May 2008 13:20:26 +0200 rudi(at)je-more(dot)de wrote:

> Andreas 'ads' Scherbaum schrieb:
> > Statement-basierte Lösungen sind nett ... allerdings muss man einige
> > Sachen beachten. Z.B. wie man mit Timestamps ect. umgeht. Das steht
> > aber imho auch in der FAQ so mit drin.
> >
> Du meinst wenn man eine zu "generalisierte" Lösung einsetzt, die dann
> möglicherweise nicht mehr
> in der Lage ist z.B Postgres Timestamps zu behandeln?

Nein, das Problem entsteht eher, wenn man Funktionen einsetzt, die auf
jeder der Datenbanken hinter dem Pool ein anderes Ergebnis liefern,
weil die Ergebnisse volatil sind. Auf so etwas muss die Anwendung
vorbereitet sein.

> > Slony dagegen ist eine Master-Slave Lösung, aber auch hier wird die
> > Verwendbarkeit stark von deinen Anforderungen und deiner Applikation
> > abhängen.
> >
> Slony ist gefährlich, weil man mit dem Master doch wieder einen Single
> point of Failure hat.

Slony ist nicht "gefährlich", Slony ist ein Konzept. Aber dazu hat
Bernd schon mehr geschrieben.

> Ok, dann hoffe ich das es sowas wie ein kleiner Anforderungsplan ist
> (der Priorität nach).

Das ist ein Anforderungsplan für dich, aber nicht für deine Applikation.
Das ist ein Unterschied.

> 1.
> Geschwindigkeit auch unter Last bei vielen konkurierenden Insert/Select
> Queries, desto schneller
> desto besser (die User am Webfrontend sollen zu jeder Zeit in,
> Bruchteilen von sek. ihre dynamischen
> HTML Operationen durchführen können (also sprich wie CGI/Perl/PHP das
> auch machen).

Die Lösung hierfür ergibt sich, wenn man sich Gedanken über die
Anforderungen für deine Applikation macht - und etwas Know How dazu ins
Spiel bringt.

> 2.
> Das Projekt ist eine Communityseite,wo ständig Nachrichten mittels
> Inserts in Tabellenspalten eingefügt
> werden (mid int = MessageNr) sender id (Verschicker) (recipid int =
> Empfaenger), subject (TEXT) hier
> kann quasi eine Bildschirmseite Text drin stehe (und dieses Feld macht
> mir am meisten Kopfzerbrechen).

Konzept anpassen, Konzept verändern, Datenbankstruktur überprüfen ect.
Da gibt es viele Möglichkeiten.

Ich wette mal dass von deinen vielen Millionen oder Milliarden
Nachrichten nur ein sehr geringer Teil ständig abgerufen wird. Dafür
gibt es geeignete Technologien, so etwas verfügbar zu machen.

> 3.
> Keine Downtimes durch Backup, Patch Update/Upgrade

Ich darf mal kurz und heftig lachen, oder?
Sind wir wieder bei "keine Downtime, weil Patches gibt es nur alle 3
Monate"?

Für eine Community-Webseite verlangst du ziemlich viel, deine
Anforderungen gehen in Richtung Hochverfügbarkeit. Dazu gehört aber
auch die Absicherung gegen Strom- und Netzausfälle, gegen
Hardwareprobleme und noch eine Reihe weiterer Maßnahmen und
Fehlerfällen. Wirf etwas mehr Geld auf dein Problem, um deine
Anforderungen zu erfüllen - speziell im Bereich Hardware und Hosting.

Deine Anforderungen lassen sich erfüllen, aber ich bezweifle, dass du
als Neueinsteiger in PostgreSQL da sehr weit kommen wirst. Dafür
benötigst du schon tiefgreifendes Wissen und einen Support, der schnell
reagieren kann.

> 4.
> Keine Unterbrechnung des DB-Betriebs durch Hardwareprobleme

Was heisst bei dir "keine". 100%? Unrealistisch. Wieviele neuner
möchtest du hinter dem Dezimalpunkt stehen haben?

> 5.
> Skalierbare Performance des Gesammtsystems durch hinzufügen und
> entfernen von
> neuen DB Servern.

Entspricht deinem Konzept.

> Appserver:
> Applicationserver ist Apache Geronimo 2.1.1, 64-Bit AMD64 JRE 1.6.0_06,
> Webserverlayer
> Tomcat 6.x DB Schnittstelle JDBC (Postgres 8.1 JDBC Treiber) innerhalb
> des Geronimo Connectionpools.
> Appserver Loadbalancing der Webapplikationen läuft über das in Geronimo
> bereits integrierte
> WADI (Web Application Distributed Infrastructure) von Codehaus.

Warum ist da immer noch PG 8.1 im Spiel? Oder welche Version läuft da
bei dir?

> Performanceschwächster Teil der Gesammtapplikation ist die DB, da die
> Formulare immer
> erst dann ausgeliefert werden können wenn die DB die Daten angeliefert
> oder verarbeitet hat.

Logisch.

Aber so langsam frage ich mich, was wir hier diskutieren. Niemand wird
dir einen Plan aufstellen, was du für deine Anwendung benötigst, weil
du auch immer nur auf Nachfrage mit Details herausrückst. Wie deine
Anwendung aufgebaut ist, weiss immer noch keiner. Wie deine
Anforderungen im Detail (nicht nur in 5 Stichpunkte gefasst) aussehen,
weiss auch niemand. Bei dem, was du hier schreibst, fallen
normalerweise ein paar Dutzend Seiten Anforderungen hinten aus dem
Prozess heraus - und das alles, bevor auch nur ein Server installiert
wurde.

Wenn die Anforderungen unabhängig von der zu verwendenden Software
definiert sind, entscheidet man, wie man zum gewünschten Ziel kommt -
und welche Datenbank die Anforderungen erfüllt. Alles andere ist
Herumprobieren ohne definiertes Ziel.

Aus dem Grund verabschiede ich mich aus dieser Diskussion. Wenn du ein
konkretes Konzept hast und wenn ihr wisst, wie wichtig euch die gesamte
Applikation ist ("keine Ausfallzeit" heisst im Umkehrschluss: der
Betrieb der Datenbank ist lebenswichtig), lass uns das doch mal wissen.

Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors