Asp to PHP Konvertierung

Asp to PHP Konvertierung (58 Beiträge, 433 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Grundprob ist die Geschindigkeit der Page. Habe ein altes ASP Projekt mit ca 19.000 Zeilen und nun will ich das Projekt auf PHP und eine Linuxkiste bringen. Hab ein paar Converter gegoogelt und bin auf nichts gescheites gestoßen. Kennt wer ein Proggi mit dem er gute Erfahrungen hat? Wie lange würdet ihr schätzen das es dauert? (DaumenMalPi)

Leider hats wer anderer geproggt und es gibt keine Doku. Leicht wirds sicher nicht, aber zum neuproggen hab ich die Zeit nicht.

wurlog

Ich kann mir nicht vorstellen, dass das gut funktioniert. Allein schon wenn ein derartiges Programm nur 10 Fehler liefert, könntest du Monate daran verbringen, diese zu finden.

bin auf nichts gescheites gestoßen.

dann gibts auch nichts gescheits - weil so was gar nicht gescheit funktionieren kann!

Gibts nicht - geht nicht...

Und WARUM willst Du das auf eine Linuxkiste bringen?

Alter HP Server den wir geerbt haben. Glaub ein Dual P3-400 Mhz mit 512 Mb hauptspeicher.
Jeder sagt mir für ne Linuxkiste ists genug. Tja für WinXp ists sehr zaaaach.

09.07.2006, 18:54 Uhr - Editiert von wrlog, alte Version: hier

Das ist logisch...mit mehr RAM wirds zwar schneller - aber sicher nicht die Welt...

wenn du sie in php genauso unperformanct scriptest bringt die die potierung nichts.

mit 19.000 zeilen code entweder ein schon ordentlich großes projekt, oder einfach nur verdammt schlechter asp code.

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
Smartforum.at

schon größer. Adreßverwaltung, Lohnverrechnung, Faxsystem etc. und alles Marke Eigenbau *grummel*

intranet?

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
Smartforum.at

ca 90% intranet, ein paar Abfragen sind auch von außerhalb, aber nichts großes
trotz intranet brauchen manche seiten 45 secs bis sie erscheinen.
meist ist die db (mysql 3.23) dabei voll ausgelastet. tests auf einem G5 *PIEP*michanrechner haben eigentlich nichts gebracht.

trotz intranet brauchen manche seiten 45 secs bis sie erscheinen.

O M F G

SO mies kann kein Code der Welt sein und so langsam auch kein Rechner oder Server

. . .

Locker. Eine Normale Abfrage bei der Varta hat auch schon mal loocker 1-2 Minuten gedauert. Da hat er dann 4 Millionen Datensaetze gelesen, gefiltert, Mittelwerten und Standardabweichungen berechnet, und dann pro Monat und Batterietyp ausgegeben. Ich habe dann schnell parallel zur Schirmausgabe (auch ASP) ein Dokument schreiben lassen...

<stolz> Mein Sohn! </stolz>

If it's too loud, then you're too old!
!!! VIRUSWARNUNG !!!

Da hat er dann 4 Millionen Datensaetze gelesen, gefiltert, Mittelwerten und Standardabweichungen berechnet

Ist das über mysql gelaufen?

Na gut, ich bin vielleicht verwöhnt, meine Datenbanken haben alle nur ein paar tausend Einträge, das geht flott und ich habe kaum Verzögerung drin (trotz dem schrottigen mysql)

Ich habe dann schnell parallel zur Schirmausgabe (auch ASP) ein Dokument schreiben lassen...

Gefinkelt

Offtopic: ich hab im Forum von soned was gefunden, das ist doch von deiner besseren Hälfte oder? Finde die Idee an sich nämlich gut nur fürchte ich, daß "wir" noch nicht reif dafür sind.
Es wäre nämlich teils wirklich eine bessere Welt MÖGLICH aber eben auch wieder nicht aufgrund der Rahmenbedingungen.

Nochmal Offtopic: mein herzliches Beileid zum Ausscheiden der Oranjes

- das war aber gestern imho ein absolutes Skandalspiel und der Schiedsrichter ein wenig deppad.

. . .

Ist das über mysql gelaufen?

Nein. Microsoft SQL-Server 2000 auf ein Dual-Pentium3-1000MHz Server. 1GB Speicher, Raid5, usw.

ich hab im Forum von soned was gefunden, das ist doch von deiner besseren Hälfte oder?

Yep. Leider hat sie es eh noch sehr neutral formuliert. Das was sie mir die letzte 6 Wochen ueber der 'verplichtende Einladung' erzaehlt hat, hat meine Meinung uebers ALVA (ArbeitsLosenVerwaltungsAnstalt) und der verordnete Schulungen noch mehr gestaerkt. Ich werde sie fragen das erlebte aufzuschreiben. Leider wird das von dir schon mal nicht geglaubt werden, ihr seit eh so super...

<stolz> Mein Sohn! </stolz>

If it's too loud, then you're too old!
!!! VIRUSWARNUNG !!!

Das was sie mir die letzte 6 Wochen ueber der 'verplichtende Einladung'
erzaehlt hat, hat meine Meinung uebers ALVA (ArbeitsLosenVerwaltungsAnstalt)

Die Abkürzung wird auch von mal zu mal nicht lustiger

Ich werde sie fragen das erlebte aufzuschreiben.

Subjektive Erfahrungsberichte sind immer gut.
Was hat man ihr denn vorgeschlagen, was so "schlecht" ist?

Leider wird das von dir schon mal nicht geglaubt

Woher willst du das wissen?

ihr seit eh so super...

Das ist allerdings (meistens) richtig.

. . .

Was hat man ihr denn vorgeschlagen, was so "schlecht" ist?

Sie hat gerade 6 Wochen "JobExpress" machen duerfen. Der Trainer (bis vor kurzen war er Fahrradbote) hat schon mal keine Ahnung gehabt, von die KursInhalte wie beschrieben wurden 2/3 nicht behandelt, und man wollte sie (Magistra, frueher Projektmanagerin in ein EDV-Unternehmen) erklaeren was sie braucht um ins Internet einsteigen zu koennen: "Browser?" "Provider?" "Computer?" "Nein, sie brauchen eine 'Adresse'...".

Woher willst du das wissen?

Weil du betriebsblind bist, und negative Ausserungen uebers ALVA entweder verneint oder auf gesetzliche Vorgaben schiebst.

Das ist allerdings (meistens) richtig.

Betriebsblind. Q.E.D.

<stolz> Mein Sohn! </stolz>

If it's too loud, then you're too old!
!!! VIRUSWARNUNG !!!

Weil du betriebsblind bist

Du urteilst schnell über Menschen. Normalerweise reagiere ich auf so etwas anders aber was soll's.
Ich will deine "Einstellung" nicht ändern. Du hast eine festgefahrene Meinung. Meinetwegen behalte sie.
Genauso gut könnte ich über DICH sagen, du hältst dich für etwas Besonderes und nur alleine DU hast recht und alle anderen automatisch nicht. Tue ich aber nicht

Q.E.D.

Siehe oben

Aja nochwas: Warum hat sie Jobexpress machen "müssen"? Hat sie selbst keine Vorschläge gebracht (als Projektmanagerin ist sie ja Kommunikation und Selbständigkeit gewohnt, hmm?) oder wurden die vom "bösen, bösen" AMS abgelehnt?
Warum nur klappt das bei meinen engeren Kollegen und mir meistens reibungslos und immer bei deinen "Fällen" kommt das "böse" AMS zum Vorschein. Irgendwie unverständlich.

. . .

26.06.2006, 15:39 Uhr - Editiert von Tom@33, alte Version: hier

Lächerlich

Du hast eine festgefahrene Meinung

Im "richtigen Leben" fallen solche Meinungen aber net vom Himmel wie die 18 tons bei Monty Pythons - sondern /entstehen/. Woher die wohl kommt ?

Ich kenne ein paar, die net arbeiten wollen - und ein paar, die mal in die Arbeitslose kamen und dringend wieder hackeln wollten. Was passierte: Beide Arten von Leuten bekamen die gleiche Schulung verordnet

. Seeehr individuelle Betreuung - LOOL.

Ich hoffe noch immer, daß das AMS (wenn ich das schon finanzieren muß) endlich mal optimiert... Erinner dich einfach an Banken vor 10 Jahren, als die Visionen gezeichnet wurden "Personal auf die Hälfte reduzieren, jeder macht sich alles im INet oder am Automaten selbst"... Der ehemalige BA-Chef wurde ausgelacht.... Und heute ? Ist seine Vision Realität.

An sich teile ich selten Ardjan's Meinung. Er ist kompetent, engagiert, hat den Blick "über das Ganze" - nur leider meist die falsche (weil M$) Religion

.

Hier teile ich aber aus allen Berichten übers AMS seinen Punkt... Das alleine mag was heissen

26.06.2006, 19:30 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Lächerlich

Wenn DU das sagst...

An sich teile ich selten Ardjan's Meinung. Er ist kompetent, engagiert, hat
den Blick "über das Ganze"

Bis auf den "Blick über das Ganze" stimme ich dir zu. Er gehört leider auch zu denen, die blindlings hinschlagen wenn's ums AMS geht. Und er macht sich nicht die Mühe seine festgefahrene Meinung EVENTUELL zu revidieren. Er VERSTEHT auch nicht, warum es manchmal zu diesen von ihm zitierten "Problemen" kommt. Es kommt meistens deshalb dazu, weil viele Menschen verlernt haben zu kommunizieren. Und wenn es dann mangels dieser einseitigen NICHT-Kommunikation zu "vorgeschriebenen" Vereinbarungen kommt, die demjenigen dann eben nicht "passen", dann wird hingedroschen. Mir kommt's manchmal so vor, als WARTEN bestimmte Leute nur darauf, daß wieder einmal etwas (in ihren Augen) "Falsches" passiert nur um dann sofort in den stereotypen Chor der "Hindrescher" einzustimmen.
Extrem kontraproduktiv!

Hier teile ich aber aus allen Berichten übers AMS seinen Punkt... Das alleine mag was heissen

Ich teile seine Ansicht nicht. Siehe oben.
Ich bin weder betriebsblind (kann ohne Übertreibung behaupten, ein wenig mehr vom Leben zu kennen als viele andere, da ich mir die MÜHE mache, Bereiche die ich nicht kenne zu analysieren und Zeit investiere um zu verstehen warum gewisse Dinge so laufen und nicht anders) noch euphorisch wenn es um's AMS geht.
Ich KANN beurteilen ob etwas gut funktioniert oder nicht, aufgrund meiner langjährigen beruflichen Erfahrung - im AMS und auch ausserhalb.

Weiteres interessantes Beispiel sind die in den letzten Jahren wie Pilze aus dem Boden schiessenden Arbeitsloseninitiativen - bis auf wenige Ausnahmen sind sie unnötig und tun nichts anderes als bewusst zu polarisieren und aufzuhussen!
Wenn die ihre Energie in sinnvollere Agenden stecken würden, dann hätten sie eventuell die Aufmerksamkeit die sie gerne hätten und es würden sie eventuell auch die Verantwortlichen ernst nehmen.
Einen Schreihals, der stereotyp immer die gleichen Phrasen runterdrischt kann man im Gegensatz dazu eben NICHT ernstnehmen.
Und genau das wird von vielen blindlings praktiziert ohne die Hintergründe zu durchleuchten oder gar eine ernsthafte Diskussion einzugehen.
Traurig.

. . .

Geh komm...

Wieso kennt niemand in meinem Umfeld jemand der sagt "Als ich beim AMS war, wurde mir super geholfen - und die Beratung war erstklassig!" sondern viele, die motzen ?

Ach ja, ich denke du hast selbst mal was berichtet über Leutchen, die zB mit fürchterlichsten Zähnen, Kleidung, ... kommen und wohl auch deshalb unvermittelbar sind.

Was wäre eine pragmatische Lösung:
- Investieren wir in eine komplett-Gebiß-Rundumerneuerung und einen Anzug. Wenn die für ihn gratis sind, schlägt er sicher zu und seine Berufswiedereintrittschance steigt.

Was macht das AMS stattdessen ?
- es schickt ihn um die doppelten Kosten zu diversen Kursen

Netterweise bringst du auch selbst, daß es Leute gibt, die sich intrinsisch motivieren können, Engagement zeigen und - so sie sich vom AMS verarscht fühlten, sich eben gegen das AMS engagieren...

Wieso um Himmels willen schafft man es nicht, gerade solchen Leuten einen Hob zu verschaffen ? Wenn grad keiner frei ist, sieht's eh jeder ein. Nur wenn man die Leute verscheißert, darf man sich nicht wundern, wenn sie aufbegehren...

Und nachdem eine kritische Masse überschritten wurde, klappt es halt auch vom AMS net mehr, sie in ein kindisches, dümmliches Eck zu stellen

Wieso kennt niemand in meinem Umfeld jemand der sagt "Als ich beim AMS war, wurde mir super geholfen - und die Beratung war erstklassig!" sondern viele,
die motzen ?

Du kennst scheinbar die falschen Leute

Ach ja, ich denke du hast selbst mal was berichtet über Leutchen, die zB mit fürchterlichsten Zähnen, Kleidung, ... kommen und wohl auch deshalb
unvermittelbar sind.

Da verwechselst du mich mit jemand anderen...

Nur wenn man die Leute ver*PIEP*t, darf man sich nicht wundern, wenn sie aufbegehren...

Bei uns wird niemand versch...

Was schrieb ich schnell noch mal über stereotyp usw.?

. . .

Dann tritt den Beweis an:
Starte eine Umfrage a la

Ich erlebe das AMS wie folgt:

War noch nie beim AMS, mir hat noch keiner berichtet
War noch nie beim AMS, mir wurde ausschließlich negatives von Bekannten berichtet
War noch nie beim AMS, mir wurde eher negatives von Bekannten berichtet
War noch nie beim AMS, mir wurde neutral von Bekannten berichtet
War noch nie beim AMS, mir wurde eher positives von Bekannten berichtet
War noch nie beim AMS, mir wurde ausschließlich positives von Bekannten berichtet

War beim AMS, erlebte es ausschließlich negativ
War beim AMS, erlebte es eher negativ
War beim AMS, erlebte es neutral
War beim AMS, erlebte es eher positiv negativ
War beim AMS, erlebte es extrem positiv negativ

Wichtig bei der Antwort: Beurteilen sie bitte, ob die Hilfe (so vorhanden) auch Erfolg brachte. Ein vermittelter Job trotz beshissenem Berater kann also net ganz negativ sein, ein seeehr netter Mitarbeiter, der aber nix vermitteln konnte, hingegen net ganz positiv

Und ich wette schon jetzt, daß (so mehr als 100 Poster antworten) mehr als 50% das AMS als negativ bewerten...

Und ich wette schon jetzt, daß (so mehr als 100 Poster antworten) mehr als 50% das AMS als negativ bewerten...

Das streite ich nicht ab. Ich denke sogar es wären mehr als 80%.
Daher spare ich mir die Umfrage auch

Aaaaaber: WARUM hat das AMS dieses Bild in der Öffentlichkeit?
--> Weil meistens nur das NEGATIVE im Gedächtnis "hängenbleibt" und das überwiegend Positive still und heimlich "untergeht"!

Ich hatte heute wieder recht viele Vorsprachen mit teils nicht angenehmen Folgen für den/die KundIn. "Wahl" es anders zu machen hatte ich keine wirklich grosse. Ich hatte trotzdem das Gefühl, daß der überwiegende Teil verstanden hat, WARUM wir es machen mussten.
Jetzt im Sommer im Juli/August haben wir zum Bsp. wieder vermehrt Abmeldungen mangels aufrechter Kinderbetreuung, auch nicht einfach für die Betreffenden, meist Frauen, oft alleinerziehend. Das Sozialreferat reagiert auch nicht immer sehr "schnell" um die finanzielle Abfederung zu gewährleisten.
Und Prüfungen auf §10 haben wir derzeit auch wieder recht viele.

Fazit: ich KANN verstehen warum wir so ein schlechtes Bild haben, versuche aber es zu ändern

. . .

Datenbank?

mysql 3.23
Versuche sie auf 4er oder 5er zu bringen gabs massig Fehlermeldungen im asp code.
Die Abfrage sind frei im sourcecode verteilt. sprich ich müßte den kompletten code durchforsten.
Die Umstellung von nt4 auf winxp war schon ein heiden arbeit.

Hmmm....

Zuerst würde ich mal versuchen, die DB auf einen extra-Server zu legen.
Dann u.U., ob man nicht viel durch Indizierung in der DB lösen kann.

Scheinbar ist dein Problem ja die DB und net der Webserver selbst.....
Daher würde ich mal versuchen, die zu tunen.

Abgesehen davon halte ich jeden Zugriff auf eine DB, die net in eine "myquery()"- oder ähnliche Funktion gekapselt ist für seeehr suboptimal.

Anderer Rechner für Datenbank hab ich versucht. Ein netter G5. Einmal nur die DB drauf u einmal die DB u den Webserver. Beides fast keine Verbesserung.

Indizierungen habe ich durchgeführt. Teilweise Verbesserungen, aber von 40 auf 25 sec zu kommen ist nicht ziel der sache

Sicherlich muss ich mich in dieser Hinsicht noch mehr in Mysql einlesen um die Indizes auch richtig zu setzen.

Wenns nicht was ganz primitives ist, kannst es vergessen. Und bei 19.000 Zeilen Code wirds wohl nicht ganz so primitiv sein. Und die Performance wird dadurch mit Sicherheit auch nicht besser, von Les- und Wartbarkeit ganz abgesehen.

Suche im Forum
Forums-FAQ
Kino 2006
Täglich frische Sudokus

Und bei 19.000 Zeilen Code wirds wohl nicht ganz so primitiv sein.

gerade bei soviel code wirds wohl eher so sein.

jeder andere hätte schon den include-befehl entdeckt, oder das projekt auf andereweise aufgeteilt

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
Smartforum.at

include kannte mein vorgänger schon. natürlich sind die 19k zeilen auf alle Dateien des Projekts bezogen. Inhaltlich ist es aber ziemlich verschlungen. Seine Gedankengänge nachzuvollziehen ist eigentlich niemals leicht

In welcher Programmiersprache?

21.06.2006, 13:53 Uhr - Editiert von nergal, alte Version: hier

Meinst du die Konvertierung??? Das ist mir egal

Nein die Ausgangssprache in der das Projekt kodiert wurde - da ASP für Micorsoft steht - nehme ich an VisualBasic.

yap

Bist du dir sicher das die Wurzel allen Übels wirklich der ASP Code und nicht doch vielleicht die DB inkl. deren eventl. unperformanten Queries ist?

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Dasselbe habe ich hier http://forum.geizhals.at/t427265,3483750.html#3483750 formuliert...

Wobei er ja scheinbar die Queries net tunen will sondern mehr "Symptome kaschieren", was ja bei einem seeeehr großen Ist-Projekt durchaus Sinn macht.

An seiner Stelle würde ich wohl:
1.) Die DB von MySQL auf PostgreSQL migrieren
2.) Testen, welche Queries es auffetzt und diese modifizieren
3.) Durch Indizierung (PostgreSQL finde ich da phantastisch) mal das ärgste lösen

Damit könnte er mal mit wenig Zeiteinsatz die Zeit gewinnen um das scheinbar notwendige Großprojekt "Reengeneering from Scratch" anzugehen. Sowas kostet zwar immens Zeit, ist allerdings bei über die Jahre gewachsenen Riesenapplikationen, wo abwechselnd mal da, mal dort was angeflanscht wurde (und nie dokumentiert wurde), absolut sinnstiftend...

Das Neue Projekterl könnte er dann gerne auf ne Linux-Kiste mit PHP legen... Ich vermute, daß er das will, weil eben dort seine Stärken liegen...

25.06.2006, 13:26 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Es ist zwar eine reine Vermutung aber allein schon das "tunen" mittels regelmäßigem - so mysql das überhaupt kann - reorg + sinnvolleres anlegen der Indixes hilft mein schon Wunder und das mit absolut geringem Aufwand.

Das Neue Projekterl könnte er dann gerne auf ne Linux-Kiste mit PHP legen...
Ich vermute, daß er das will, weil eben dort seine Stärken liegen...

Nunja scheint einfach gesagt.. denn ein rebuild from scratch, kann bei einer undokumentierten SW fatale Probleme aufweisen, vorallem wenn es niemanden gibt welcher sich soweit mit dem Ding beschäftigt hat oder will und es dann zum Schluss an zig Enden und Ecken fehlt.

Bin schon gespannt wie er sich tut, mein bis jetzt einziges solches Projekt geht paradoxerweise demnächst - fachlich ungetestet - an den Start.... und ich warte nur drauf, dass irgendwas nicht hinhaut

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Bei undokumentierter SW passiert, was passieren muß:
Irgendwann klappt irgendwas katastrophal net, und keine Sau weiß, warum... Aber man braucht sie dann dringendst gefixt

.

Du /brauchst/ einen dokumentierten Stand, den kannst du entweder per Reengineering erzielen (wobei man dann oft raten muß, ob manche Sachen per Design sind, wie sie sind oder schlicht bugs) - oder du beginnst mit der Anforderungsanalyse von vorne.

Letzteres hilft eh oft, da meist Benutzer im Laufe der Jahre draufkommen, was sie noch brauchen könnten....

Einfach ist es nicht, aber wer net dokumentiert (oder als Auftraggeber keine Doku einfordert) ist einfach selbst schuld.

Er hat schon etwas unperformantes ... wieso sollte er dann noch soetwas wollen. Sprich PHP *gg*

Undying

Ich persönlich finde PHP sauflott - kann echt net meckern...

Aber wie gesagt - sein Problem ist scheinbar eh net der Webserver sondern die DB...

Also doch wieder die Anwendung, da sie teuere Fernaufrufe schlecht verwaltet. Martin Fowler hat dazu mal ein gutes Buch geschrieben ...

Neee...

wenn ich's richtig verstanden habe:
1.) ist sein DB-Server gleichzeitig sein Webserver
2.) geht die DB auf 100% CPU, wenn ne Query kommt
3.) ist daher die App selbt (mit Ausnahme der abgesetzten Queries) net der HotSpot, der zu tunen ist...

Die DB soll bei jeder Query eigentlich auf 100% gehen. (Oder solls doppelt so lang dauern bei nur 50%?)

Mein Gesichtspunkt ist eher: Wieso wird eine Query ausgeführt? Wieso wird nicht gegeacht damit die Query erst garnicht notwendig ist? Stichwort: Identity Map
Ich setz diese Dinge gerade bei einer Intranet Anwendung um. Es geht zwar mehr Ram drauf aber das ist heutzutage eigentlich Piep-Egal

Gerade bei Intranetanwendungen sind die Datenmengen (in der DB) meist minimal.

Aber schon richtig ... Tunen kannst auf beiden Seiten (Anwendung und Datenbank) ... Ersteres bringt bei kleinen Datenmengen nur einen unglaublich höhere Performence.

Pfew.... Das sehe ich ganz anders als Du

Meine Apps sind so gebaut, daß sie prinzipiell (mit wenigen Ausnahmen) net cachen.
Begründungen:
- Es wird einfacher und damit tendenziell fehlerfreier. Denn nach jedem commit müßtest deinen Cache ja wieder invalidieren, da ja uU ein anderer Benutzer inzwischen deine gecachten Daten modifizierte.
- EIN Lösungsansatz für obiges sind NOTIFYs, die zB PostgreSQL kennt. Das könnte ungefähr so klappen: Beim Erstzugriff cacht jeder Benutzer ab Abfrage zB Metadaten. Gleichzeitig registriert er sich zB für das NOTIFY "HABE_PERSONALTABELLE_MODIFIZIERT" am DB-Server. Sobald ein UPDATE/INSERT/DELETE auf die Tabelle losgeht, stößt ein Trigger das NOTIFY am DB-Server an und jeder Benutzer kann dieses NOTIFY abfangen - durch invalidieren des Cache.
- Performance: Der Witz dabei ist, daß bei großen Datenmengen eine DB bei weitem performanter im Zugriff ist als jede selbstgeschnitzte PHP/Java/...-App. Alleine deshalb, weil kein Schwein von uns freiwillig den Optimizer, Statistiken, ... nachbaut

. In C/C++ könntest via der perfect-hash-Lib nahe drankommen, aber in Wirklichkeit kaum

Mein Punkt ist, daß eine sauber designte Datenbank auch bei größten Datenmengen bei weitem performanter ist als jedes Client-Caching, insbesondere da (damit der Client überhaupt cachen kann) die Datenmengen erst mal übers Netz müßten.

Natürlich impliziert das
- ein sauberes Design
- Ausnutzung aller Technologien wie zB
    - Materialized Views
    - Korrekte Indizierung inklusive Wahl des Indextyps (Wann nehme ich B-Tree, wann R-Tree, wann nehme ich einen Hash-Index, wann nehme ich einen Bitmap-Index, wann schreib' ich einen eigenen, wann mach ich einen function-based)
    - korrektes Unterstützen des Optimizers(Statistiken)
    - BitBuckets bzw. Histogramme
    - Gelegentlich Optimizer-Hits mitgeben
    - Beachten der Implikationen der (Nicht-)Verwendung von Bind-Variablen
    - passende Konfig der DB, so zb PCTFREE, ...
    - "Aufrüstung" der DB durch in C formulierte Funktionen
    - Stored Procedures
    - Wenn einige Queries dynamisch generiert werden und du net die Hand drauf hast: Query rewrites
.....

Ich komme aber /vermutlich/ aus einem ganz anderen Eck als Du - eben aus der Systemprogrammierung, net Anwendungsprogrammierung - und habe daher ganz sicher andere Zugänge als Du (und will deine keinesfalls kritisieren).

Optimal ist natürlich eine Synergie von beiden Optimierungen... Wobei:
Wenn die Query langsam ist und der Server für mehrere Sekunden auf 100% geht - dann ist ganz sicher net die Applikation zu tunen (außer dem SQL-Statement natürlich), sondern definitiv im Datenmodell bzw. in der Config des DB-Servers was ganz falsch...

Grundsätzlich sollte IMHO ein DB-Server
- massiv Memory-Bound sein
- ziemlich IO-Bound
- und praktisch nie CPU-Bound.

Alles natürlich nur in der großen IMHO-Klammer und je nach Anwendungsfall unterschiedlich - in meinem Umfeld (=bei den von mir wahrgenommenen Tasks) sieht's i.d.R. so aus. Kein Anspruch auf Vollständigkeit

- Es wird einfacher und damit tendenziell fehlerfreier. Denn nach jedem commit müßtest deinen Cache ja wieder invalidieren, da ja uU ein anderer Benutzer inzwischen deine gecachten Daten modifizierte.

Nein bei verwendung einer Identiy Map wird genau das Problem der Nebenläufigkeit Umgangen. Allternativ (im kleineren Ansatz) wäre auch ein SQL-CacheDependency ein Lösungsansatz. (Der Cache wird automatisch invaild wenn Daten geändert werden)

- Performance: Der Witz dabei ist, daß bei großen Datenmengen eine DB bei weitem performanter im Zugriff ist als jede selbstgeschnitzte PHP/Java/...-App. Alleine deshalb, weil kein Schwein von uns freiwillig den Optimizer, Statistiken, ... nachbaut . In C/C++ könntest via der perfect-hash-Lib nahe drankommen, aber in Wirklichkeit kaum

Ich kann zwar nur aus der Microsoft .net Welt reden aber:
Da kann ich dir nur x-Mal widersprechen. Remoteaufrufe sind eigentlich immer um vieles langsamer als interne aufrufe. Besonders Cachezugriffe belasten im besten fall nichtmal den Webserver (wird bereits im Webserver treiber erledigt). Performance gewinn ist oft ein tausendfaches.

ein Punkt ist, daß eine sauber designte Datenbank auch bei größten Datenmengen bei weitem performanter ist als jedes Client-Caching, insbesondere da (damit der Client überhaupt cachen kann) die Datenmengen erst mal übers Netz müßten.

Ich spreche von Serverseitigen Caching und NICHT von Clientcaching. (Beispiel: Laden eines Kunden. Erstellen Des Kundenobjektes. Hinzufügen des Kundenobjectes dem Cache.) Ruft der nächste User den Kunden auf erfolgt ein Arbeitsspeicherzugriff und kein Zugriff auf die Datenbank) Wieviel das schneller ist kannst du dir selbst denken.

Aber ich denke das wird sowieso eine Endlosdiskussion. Ich bin eben der Meinung das die Applikation von der Anwendung von der Datenbank KOMPLETT getrennt werden soll(te). Optimieren kannst dann die Datenbankzugriffe immer noch. Allerdings sollten auf Dinge wie Caching keines falls verzichtet werden. Aber wir können uns gerne drauf einigen, dass sowohl die Anwendung als auch die Datenbankzugriffsidee dahinter schrott ist +ggg+

Die obrigen Aspekte sind übrigens erst zu einem kleinen Teil meine eigenen Erfahrungen sondern eher die Sicht eines (wirklichen) Profis bei Unternehmensanwendungen für große Versicherungen, etc. Wenn dich das Thema interessiert empfehle ich dir Patterns of Enterprise Application Architecture von Martin Fowler. Das Buch ist echt WOW

Naja, die Identity Map kannst aber nur verwenden, wenn es nur genau einen Pfad zur DB gibt - zB durch den Applikationsserver, oder ? Sobald du Statements gegen die DB hast, die direkt fahren sollten (zB vom HOST) wird's stressig (vermute ich mal

).

Des weiteren ist das Problem eine Frage der Menge - wo ich eben meinte, daß Datenbanken schneller sind:
Angenommen, du hast eine Tabelle mit mehreren 100k Einträgen (zB deine Kundendatenbank) - und möchtest nur mal alle Kunden mit dem Anfangsbuchstaben "M" finden. Da gäbe es nun 2 Wege:
1.) Du hast alle 100K in deinem AppServer gecacht - das bedeutet aber, daß du Memory in den Appserver anstatt in den DB-Server investiert hast.
1a.) Wenn dem so ist - dann hast du den Kundennamen im schlimmsten Fall so hinterlegt, daß du ne lineare Suche brauchst... also durchschnittlich 50k Vergleiche
2.) Du machst eine einfache Query per SQL.
Du hast zwar den Overhead des Parsens/optimizens/..., andererseits gewinnst du massivst durch den eben sehr effizienten Optimizer und die dann nur notwendigen (Hausnummer) durchschnittlich 20 Indexzugriffe plus einem Datenblockzugriff bei rund mehr als einer Mio Datensatzzeilen.

eine preparsed-SQL-Query kostet so ziemlich genau 0... Netterweise kümmert sich dein DB-System ja laufend auch drum, daß es die gerade am häufigsten verwendeten Statements eh im eigenen Cache läßt und sich so den Parsing und den Optimizer-Run erspart (und genau das sind ja die teuren).

Wenn die Kundentabelle nun oft verwendet wird, so kommen die oft verwendeten Blöcke (=genau die relevanten Kunden) zusätzlich in den Datencache.

Wenn du aber sogar ne Index organized Table verwendet hast, so ist der Datensatz direkt im Indexnode - also nochmal flotter.

Natürlich hast du prinzipiell recht, daß ein Memory-Zugriff um den Faktor 1000+ schneller sein kann als DiskIO (abhängig natürlich von den Storagesystemen. Bei ner IBM-ESS bekommst zB 2GB/s Datenrate - da werden die Potenzen schon weniger). IMHO sollten bei großen Datenbanken die oft benötigten Indizes zumindest tendenziell im Ram liegen - wenn es "Standard"-Queries sind, wo viele Datensätze durchsucht werden und das Resultset eher klein ist, scheint das für mich zielführend zu sein.

Ich bin eben der Meinung das die Applikation von der Anwendung von der Datenbank KOMPLETT getrennt werden soll(te

Das ist ein sinnvoller Design-Ansatz. Wobei DBs derart viel Funktionalität bieten, daß es IMHO fast fahrlässig wäre, auf sie zu verzichten. Es ist IMHO auch fahrlässig, wenn Appentwickler die DB als eine Blackbox betrachten (und bei uns auch untersagt. Ein App-Entwickler, der zB keine Storage-Parameter-definitionen für seine DB liefert, kann sich brausen gehen), andererseits auch fahrlässig, wenn die DB'ler sich nicht nach den Bedürfnissen der App'ler richten. Sowohl Client als auch App-Server als auch DB-Server müssen bei großanwendungen sehr verzahnt sein. Vorteil: Viel kürzere Entwicklungszeit, Massiv performantere Apps. Nachteil: Bindung an ein DB/AppServer-System.

IMHO ist SW-Engineering immer die Kunst der Implementierung des machbaren. Wenn du ne Standard-DB hast (sagen wir 200Gigs komplettstorage) wird's zugegeben fast wurscht sein. Wenn du an die Grenzen der Möglichkeiten gehst, mußt IMHO (und ich meine echt IMHO

) Kompromisse eingehen - und da gehört auch das Aufgeben des grnudsätzlich brauchbaren Black-Box-Ansatzes.

Wobei ne BlackBox und DB sich IMHO eh net vertragen, denn keine DB hat den SQL99-Standard 100%ig umgesetzt... Und der Ansatz des "kleinsten gemeinsamen Nenners" bietet zwar den Vorteil der Flexibilität, dafür zahlt man halt im Sinne von Mehraufwand bei der Entwicklung bzw. schlicht weniger Möglichkeiten. Es mag aber durchaus zuhauf Anwendungsfälle geben, wo genau der Blackbox-Ansatz absolut zielführend und sinnbringend ist..

Ich spreche von Serverseitigen Caching und NICHT von Clientcaching.

Und ?
Der App-Server (oder Webserver) ist ja auch nur ein Client für den DB-Server, oder ?

26.06.2006, 12:32 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Er hat schon etwas unperformantes ... wieso sollte er dann noch soetwas
wollen. Sprich PHP *gg*

php ist gerade für "kleine" Sachen sauschnell - mein am häufigsten verwendetes Script hat knapp 5.000 Zeilen und performt SUPER im Intra- wie Internet

. . .

Ach das sollte doch nur ein kleiner Seitenhieb sein um auf .net zu setzen

Undying

Kostenlose Werbung für Mirkosoft?

. . .

Frei nach dem Motto möge der bessere Gewinnen :D +gg+

Der Kampf ist aber leider schon entschieden, durch die anfängliche Marktpolitik von Mirkosoft von vor über 10 Jahren

. . .

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung