Re(8): Asp to PHP Konvertierung

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

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

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)

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