Re(10): Asp to PHP Konvertierung

Asp to PHP Konvertierung (58 Beiträge, 484 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

Re: Asp to PHP Konvertierung (Fragestellender am 21.06.2006, 11:41:24)

Re: Asp to PHP Konvertierung (fleptin am 21.06.2006, 11:42:46)

Re: Asp to PHP Konvertierung (Pervasive am 21.06.2006, 11:44:10)

Re(2): Asp to PHP Konvertierung (wrlog am 09.07.2006, 18:54:07)

Re(3): Asp to PHP Konvertierung (Pervasive am 09.07.2006, 19:00:57)

Re: Asp to PHP Konvertierung (error-is.org am 21.06.2006, 11:55:51)

Re(2): Asp to PHP Konvertierung (wrlog am 21.06.2006, 12:01:43)

Re(3): Asp to PHP Konvertierung (error-is.org am 21.06.2006, 12:05:10)

Re(4): Asp to PHP Konvertierung (wrlog am 24.06.2006, 16:20:30)

Re(5): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 07:55:03)

Re(6): Asp to PHP Konvertierung (Ardjan am 26.06.2006, 12:49:02)

Re(7): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 14:15:40)

Re(8): Asp to PHP Konvertierung (Ardjan am 26.06.2006, 14:31:32)

Re(9): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 15:17:46)

Re(10): Asp to PHP Konvertierung (Ardjan am 26.06.2006, 15:24:03)

Re(11): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 15:36:55)

Re(12): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 26.06.2006, 19:29:27)

Re(13): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 19:54:51)

Re(14): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 26.06.2006, 20:05:31)

Re(15): Asp to PHP Konvertierung (Tom@33 am 27.06.2006, 13:04:36)

Re(16): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 27.06.2006, 13:19:39)

Re(17): Asp to PHP Konvertierung (Tom@33 am 27.06.2006, 13:58:05)

Re(3): Asp to PHP Konvertierung (Pervasive am 21.06.2006, 12:05:38)

Re(4): Asp to PHP Konvertierung (wrlog am 24.06.2006, 16:22:09)

Re(5): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 24.06.2006, 19:03:58)

Re(6): Asp to PHP Konvertierung (wrlog am 09.07.2006, 18:57:54)

Re: Asp to PHP Konvertierung (Robert Craven am 21.06.2006, 11:57:52)

Re(2): Asp to PHP Konvertierung (error-is.org am 21.06.2006, 12:00:38)

Re(3): Asp to PHP Konvertierung (wrlog am 24.06.2006, 16:24:22)

Re: Asp to PHP Konvertierung (nergal am 21.06.2006, 13:49:11)

Re(2): Asp to PHP Konvertierung (wrlog am 24.06.2006, 16:26:58)

Re(3): Asp to PHP Konvertierung (nergal am 25.06.2006, 13:58:26)

Re(4): Asp to PHP Konvertierung (wrlog am 09.07.2006, 18:58:41)

Re: Asp to PHP Konvertierung (pong am 25.06.2006, 06:57:59)

Re(2): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 25.06.2006, 13:25:06)

Re(3): Asp to PHP Konvertierung (pong am 25.06.2006, 17:05:44)

Re(4): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 25.06.2006, 17:32:14)

Re(3): Asp to PHP Konvertierung (Undying am 25.06.2006, 22:49:47)

Re(4): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 25.06.2006, 22:51:36)

Re(5): Asp to PHP Konvertierung (Undying am 25.06.2006, 23:32:03)

Re(6): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 25.06.2006, 23:36:19)

Re(7): Asp to PHP Konvertierung (Undying am 26.06.2006, 05:53:09)

Re(8): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 26.06.2006, 11:04:18)

Re(9): Asp to PHP Konvertierung (Undying am 26.06.2006, 11:18:57)

Re(10): Asp to PHP Konvertierung (gepeinigter_aon_neukunde am 26.06.2006, 12:00:47)

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

[ Dieser Beitrag wurde inzwischen editiert. Die aktuelle Version befindet sich hier. ]

Re(4): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 07:57:43)

Re(5): Asp to PHP Konvertierung (Undying am 26.06.2006, 08:03:52)

Re(6): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 10:32:21)

Re(7): Asp to PHP Konvertierung (Undying am 26.06.2006, 10:58:19)

Re(8): Asp to PHP Konvertierung (Tom@33 am 26.06.2006, 12:42:49)

Vom Autor zurückgezogen oder Autor hat seine Registrierung nicht bestätigt (MG am 26.06.2006, 09:46:44)

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