Re: WebApplication und Betriebssystem Performance Fragen.

From: "rudi(at)je-more(dot)de" <rudi(at)je-more(dot)de>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: WebApplication und Betriebssystem Performance Fragen.
Date: 2008-05-17 11:20:26
Message-ID: 482EBF7A.6000904@je-more.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

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?

> 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.

> Der Vorschlag wäre, für deine Anwendung mal einen Anforderungskatalog
> aufzustellen und dann zu schauen, welche Datenbank das erfüllt. Alles
> andere ist wildes Herumrühren im Dunst der möglicherweise vorhandenen
> Features.
>

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

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).

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).
3.
Keine Downtimes durch Backup, Patch Update/Upgrade
4.
Keine Unterbrechnung des DB-Betriebs durch Hardwareprobleme
5.
Skalierbare Performance des Gesammtsystems durch hinzufügen und
entfernen von
neuen DB Servern.

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.

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.

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Bernd Helmle 2008-05-17 12:29:29 Re: WebApplication und Betriebssystem Performance Fragen.
Previous Message Andreas 'ads' Scherbaum 2008-05-17 09:57:41 Re: WebApplication und Betriebssystem Performance Fragen.