nicht angemeldet
Moin!
Nachdem ich mich nun jahrelang mit PHP, sämtlichen DBMS, XML, XHTML, JS auseinander gesetzt habe und viele kleine Privatkunden hatte, kommt jetzt das erste größere Projekti n eigener Sache.
Eine Community in der Art wie Schüler/Studi/MeinVZ.net.
Da hast du dir ja was vorgenommen.
Ich habe nun folgende Fragen:
1.) Warum einen Linux Server und nicht Windows Server?
Ich denke mal er ist sicherer, stabiler und schneller - der Linux. Gibt es noch andere?
Den Server kriegst du beim Hosting-Anbieter deines Vertrauens in jeder gewünschten Konfiguration.
2.) Welche Linux Distribution sollte man am besten nehmen? Ich dachte an Debian.
Du nimmst die Distri, die du am besten kennst. Oder halt die, die dein Hoster hat.
3.) Als Webserver dachte ich auf jeden Fall an Lighttpd statt Apache2. Was denkt ihr?
Du nimmst den Webserver, den du am besten kennst.
4.) Letztendlich wollte ich 3 Server nehmen. Einen für die Datenbank, einen für die Userbilder und einen Für die PHP Files.
Ich will anfangs nicht mehr als 120€/Monat investieren - geht sowas?
Du hast am Anfang keinerlei Performanceprobleme. Also reicht im Prinzip auch "Webspace" irgendwo. Welche Performanceprobleme auftreten, wirst du nur kennenlernen, wenn deine Community tatsächlich so wächst, dass du mehr als einen Server benötigst. Bzw. erst dann findest du einen zum Problem exakt passende Lösung, so dass die Performanceprobleme optimal bearbeitet werden.
Deine jetzige Problemlösung wird dich hingegen viel Geld kosten, ohne auch nur ein einziges Problem zu lösen. Du gehst davon aus, dass das Ausliefern von Userbildern ein Problem wird, und du gehst davon aus, dass die Abfragen der Datenbank ein Problem werden. Das sind zwei Annahmen, die im Moment durch nichts gerechtfertigt sind.
Es spricht ja nichts dagegen, sich beim Programmieren schon mal Gedanken zu machen, an welchen auffälligen Stellen man so eine mögliche Aufteilung integrieren kann. Mehr als eine Konfigurationsvariable für "Bilderserver-URL" und "DB-Server-Connection" wäre das aber nicht - und egal, was du dir auch ausdenkst, du kannst einerseits nie sicher sein, dass diese geplante Aufteilung auch tatsächlich gebraucht wird, oder dass diese Aufteilung im Gebrauchsfall auch tatsächlich ausreicht, und nicht deutlich erweitert werden muß.
5.) Angenommen die Seite hat 10000 Seitenaufrufe am Tag, reicht ein Server? Ich kann einfach nicht einschätzen wieviele Sever wir brauchen.
Der am stärksten belastete SELFHTML-Server hat von heute 01:00 Uhr bis 11:16 Uhr insgesamt schon über 422.000 Hits gehabt - und das in den Nachtstunden. Der Server ist CPU-mäßig absolut nicht ausgelastet.
6.) Ab wieviel Datenbankeinträgen sollte man statt MySQL, PostgreSQL nehmen?
Ab wann lohnt sich dort der Umstieg oder bzw. notwendi/empfehlenswert?
Oder würdet ihr eine ganz andere Datenbank nehmen?
Ich habe noch nie gehört, dass die Wahl der Datenbank sich aufgrund der Zahl der Datenbankeinträge entscheidet. Da wären immer andere Faktoren entscheidender. Allen voran: Mit welcher DB kennst du dich am besten aus? Denn es ist abzusehen, dass du das gesamte Featureangebot der DB benötigen wirst. Zweitens: Bietet diese Datenbank all das, was du an DB-Features benötigst?
Du versuchst auch für diese Fragestellung schon vor dem Projektstart die Performancefrage zu stellen, ohne dass du auch nur im geringsten weißt, welche Performanceprobleme auftreten werden.
Jede verfügbare Datenbank ist in der Lage, mehrere Milliarden Datensätze zu verwalten und auszuliefern. Keine Datenbank ist in der Lage, diese Milliarden Datensätze ständig komplett mit hoher Performance lesend auszuliefern und parallel noch Millionen von Schreibzugriffen auszuführen. Sprich: Du kannst jede Datenbank so auslasten, dass dir die Performance nicht mehr gefällt. Die Frage ist aber doch, ob es dazu kommt, und wo dann genau das Problem liegt.
7.) Auf was sollte ich unbedingt achten? Welche Möglichkeiten gibt es PHP "schneller" laufen zu lassen? Sollte das ganze OOP sein?
Du solltest unbedingt darauf achten, dass du keine voreiligen Performanceoptimierungen vornimmst. Sowas kostet dich nur unnötig Geld: Zum einen verbrätst du mit der Umsetzung einer Lösung unnötige Ressourcen (Programmierzeit, Extraaufwand), zum anderen müssen die antizipierten Probleme ja gar nicht auftreten - dafür dann aber andere, viel schlimmere Probleme, an die niemand gedacht hat.
Zweitens sind Performanceoptimierungen immer auch Programmkomplizierer. Du willst aber kein Programm schreiben, das von Anfang an schon kompliziert ist, du willst immer eine möglichst einfache Lösung haben: Einerseits sind einfache Lösungen schneller hergestellt, damit man sie in Aktion sehen und ihre Auswirkung auch tatsächlich verstehen kann. Andererseits sind einfache Lösungen leichter zu verstehen, zu warten, zu erweitern und auf später auftretende Performanceprobleme optimierbar, als komplizierte Lösungen.
Deine Frage nach einem "schnelleren" PHP zielt in dieselbe Kerbe. Wenn's dir darum geht, vom Start weg eine schnell ausführende Programmiersprache zu wählen, dann schreib das Projekt in Java oder C, aber nicht in PHP. Das wäre vor allem deshalb angesagt, weil nach deiner Voraussage dieses Projekt ja wirklich riesig werden würde. Der Nachteil von C ist nur, dass das Programmieren von Webapplikationen wirklich richtig aufwendig ist, und auch mit Java ist der Vorgang deutlich aufwendiger, als wenn man eine "direkt wirkende" Skriptsprache wie PHP einsetzt.
Was OOP angeht: Natürlich sollte es das sein. Und als zwingend sehe ich auch den Einsatz von automatisierten Tests nach der Maßgabe von TDD (test-driven design). Andernfalls geht das Projekt unter. OOP wird aber nicht verwendet, damit das Programm schnell ausgeführt wird, sondern einzig und allein deswegen, damit einfacher, schneller und fehlerfreier programmiert werden kann.
Deine limitierte Ressource heißt am Anfang "Entwickler", nicht "Performance". Wenn das Projekt Erfolg haben soll (was ich angesichts der langjährig existierenden Konkurrenz bezweifle), dann muß es sich durch absolut gute Qualität und interessante Features hervorheben. Zur Erreichung guter Qualität ist es unabdingbar, dass die Software fehlerfrei ist. Fehlerfreie Software erhält man nur durch organisiertes und strukturiertes Testen, nicht durch wildes Programmier-Hacken. TDD sorgt für Struktur beim Testen. Der Einsatz von TDD führt dann fast zwangsläufig zum Einsatz von OOP.
- Sven Rautenberg
suit