Großes Projekt und viele Fragen

[Max Rhönung]

Hallo.

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.

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?

2.) Welche Linux Distribution sollte man am besten nehmen? Ich dachte an Debian.

3.) Als Webserver dachte ich auf jeden Fall an Lighttpd statt Apache2. Was denkt ihr?

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?

5.) Angenommen die Seite hat 10000 Seitenaufrufe am Tag, reicht ein Server? Ich kann einfach nicht einschätzen wieviele Sever wir brauchen.

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?

7.) Auf was sollte ich unbedingt achten? Welche Möglichkeiten gibt es PHP "schneller" laufen zu lassen? Sollte das ganze OOP sein?

Liebe Grüße,

Max

[suit]

1.) Warum einen Linux Server und nicht Windows Server?
Ich denke mal er ist sicherer, stabiler und schneller - der Linux. Gibt es noch andere?

sicherer nicht unbedingt, durch den hohen verbreitungsgrad von linux im serverbereich finden sich wesentlich mehr defacements von linux-kisten als von windows-servern

stabiler: ich kann mich bei meinen windows/iis/mssql-server nicht beklagen
schneller: ja, windows/iis/mssql ist wesentlich langsamer als vergleichbare dinge mit linux/php/mysql

2.) Welche Linux Distribution sollte man am besten nehmen? Ich dachte an Debian.

hatte bisher noch keine probleme damit, würde ich auch sagen

3.) Als Webserver dachte ich auf jeden Fall an Lighttpd statt Apache2. Was denkt ihr?

ich kenne lighttpd nicht - bin aber mit apache 2.2 sehr zufrieden

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?

nimm einen server und schau dir an, wies mit der performance läuft - mit wachesender dimension kannst du aufteilen

5.) Angenommen die Seite hat 10000 Seitenaufrufe am Tag, reicht ein Server? Ich kann einfach nicht einschätzen wieviele Sever wir brauchen.

locker, 10.000 pageviews an einem tag sind garnix

6.) Ab wieviel Datenbankeinträgen sollte man statt MySQL, PostgreSQL nehmen?

ich denke mysql ist ausreichend, in jedem fall - wenn die performance zu klein wird: ein zweiter server mit loadbalancing

Ab wann lohnt sich dort der Umstieg oder bzw. notwendi/empfehlenswert?
Oder würdet ihr eine ganz andere Datenbank nehmen?

idr nutzt man unterschiedliche dbms wegen der features, nicht wegen der performance (bitte um korrektur wenn ich mich irre)

7.) Auf was sollte ich unbedingt achten? Welche Möglichkeiten gibt es PHP "schneller" laufen zu lassen? Sollte das ganze OOP sein?

bevor du dich für eine funktion entscheidest, prüfe alternativen und führe benchmarks durch (bzw informiere dich online)

viele funktionen haben 1:1 aliase die aus irgend einem grund langsamer oder schneller sind, weil sie intern leicht anders behandelt werden (aber zum selben ergebnis führen)

zb "else if" und "elseif"

[Sven Rautenberg]

Moin!

1.) Warum einen Linux Server und nicht Windows Server?
Ich denke mal er ist sicherer, stabiler und schneller - der Linux. Gibt es noch andere?
sicherer nicht unbedingt, durch den hohen verbreitungsgrad von linux im serverbereich finden sich wesentlich mehr defacements von linux-kisten als von windows-servern

Das liegt aber weder an Linux, noch an Windows, sondern schlicht an schlampig programmierten Skripten, die solche Angriffe zulassen.

7.) Auf was sollte ich unbedingt achten? Welche Möglichkeiten gibt es PHP "schneller" laufen zu lassen? Sollte das ganze OOP sein?
bevor du dich für eine funktion entscheidest, prüfe alternativen und führe benchmarks durch (bzw informiere dich online)

viele funktionen haben 1:1 aliase die aus irgend einem grund langsamer oder schneller sind, weil sie intern leicht anders behandelt werden (aber zum selben ergebnis führen)

zb "else if" und "elseif"

Solche Mikrooptimierungen bringen garnichts. Sie komplizieren lediglich den Programmierprozess, und kosten damit deutlich mehr Zeit, als sie später jemals einsparen können.

- Sven Rautenberg

[Cheatah]

Hi,

1.) Warum einen Linux Server und nicht Windows Server?

Linux ist für Server-Rechner schlicht und ergreifend das OS der Wahl. Wenn Du keine Anforderungen hast, die nur mit einem Windows zu lösen sind, stellt sich IMHO die Frage erst gar nicht.

2.) Welche Linux Distribution sollte man am besten nehmen? Ich dachte an Debian.

Enthaltung.

3.) Als Webserver dachte ich auf jeden Fall an Lighttpd statt Apache2. Was denkt ihr?

Lighty ist schneller und kann weniger. Überlege Dir, welches Potenzial an Möglichkeiten Du ggf. in der Zukunft benötigen wirst - wozu übrigens auch Kompetenz in Sachen Serverkonfiguration gehört. Wenn Deine Liste nichts enthält, was Lighty nicht auch könnte, dann nimm das Teil.

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?

Enthaltung.

5.) Angenommen die Seite hat 10000 Seitenaufrufe am Tag, reicht ein Server? Ich kann einfach nicht einschätzen wieviele Sever wir brauchen.

Der Tag hat 86400 Sekunden. Wenn Du befürchtest, dass ein Seitenaufruf mehr als 8 Sekunden[1] benötigt, solltest Du an Deiner Programmierung arbeiten ;-)

6.) Ab wieviel Datenbankeinträgen sollte man statt MySQL, PostgreSQL nehmen?

Es gibt Leute, die würden jetzt mit "1" antworten. Welche Anforderungen hast Du an die DB, wie gut kannst Du ein DB-Layout (wozu auch die Statements gehören) optimieren oder optimieren lassen?

7.) Auf was sollte ich unbedingt achten? Welche Möglichkeiten gibt es PHP "schneller" laufen zu lassen? Sollte das ganze OOP sein?

Stelle Dir die Frage, ob Du PHP als Modul oder als CGI laufen lassen willst. Überlege Dir, welche Anforderungen Du an Ausfallsicherheit hast, und lege Dir einen Schlachtplan für Notfälle bereit. Erstelle ein Backup-Konzept. OOP ist etwas, das man wegen vieler Vorteile wählt - üblicherweise gehört Geschwindigkeit jedoch nicht dazu.

Cheatah

[1] So kann man natürlich nicht rechnen, weil in Stoßzeiten die Requests eine viel höhere Dichte haben, aber in diesem Fall macht das den Kohl auch nicht fett.

[Max Rhönung]

Hi.

3.) Als Webserver dachte ich auf jeden Fall an Lighttpd statt Apache2. Was denkt ihr?

Ich weiß nicht viel was mein Server können sollte.
PHP, MySQL/PostgreSQL, Mod-rewrite... mehr fällt mir auf anhieb nicht ein

Der Tag hat 86400 Sekunden. Wenn Du befürchtest, dass ein Seitenaufruf mehr als 8 Sekunden[1] benötigt, solltest Du an Deiner Programmierung arbeiten ;-)

Wie siehts denn bei 500000 Seitenaufrufen am Tag?

Es gibt Leute, die würden jetzt mit "1" antworten. Welche Anforderungen hast Du an die DB, wie gut kannst Du ein DB-Layout (wozu auch die Statements gehören) optimieren oder optimieren lassen?

Die Qualität meines DB-Layouts kann ich schlecht einschätzen.

Stelle Dir die Frage, ob Du PHP als Modul oder als CGI laufen lassen willst. Überlege Dir, welche Anforderungen Du an Ausfallsicherheit hast, und lege Dir einen Schlachtplan für Notfälle bereit. Erstelle ein Backup-Konzept. OOP ist etwas, das man wegen vieler Vorteile wählt - üblicherweise gehört Geschwindigkeit jedoch nicht dazu.

Die Frage stelle ich gerne zurück. Ich meine aber unter Lighttpd kann man PHP nur als CGÌ unter FastCGI laufen lassen oder täusch ich mich?
Wo wären da die Unterschiede? Performance?

[suit]

Wie siehts denn bei 500000 Seitenaufrufen am Tag?

kommt auf die hardware, die internetanbindung, die programmierung der seite, die anzahl der ausgelieferten ressourcen usw an - da gibts keine pauschalantwort

[Sven Rautenberg]

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

[Max Rhönung]

Hi.

Da hast du dir ja was vorgenommen.

Ja das weiß ich ;).

Du nimmst die Distri, die du am besten kennst. Oder halt die, die dein Hoster hat.

Erfahrung habe ich nur mit Windows Servern und freeBSD...

Du nimmst den Webserver, den du am besten kennst.

Apache kenn ich besser, lighttpd soll aber wirklich einen imensen Vorteil bringen.

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.

Sie wird auf jeden Fall in PHP geschrieben da ich die anderen Sprachen nicht/wenig/ungenügend beherrsche.

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.

Könntest du mir TDD genauer erläutern?

Ich muss in sehr vielen Punkten die du sagst Einsicht zeigen. Ich platze atm vor Eifer nach Taten. Deswegen soviele Fragen die ich mir eigendlich und normalerweise auch selbst beantworte. Aber ich habe gerne direkt die Meinung kompetenter Leute dazu.

Der Server wird demnacht Lighttpd sein, auf Debian laufen und MySQL als DB und PHP als führende Projektsprache nehmen.

Danke für deine Worte.

Mit freundlichen Grüßen,

Max R.

[Sven Rautenberg]

Moin!

Da hast du dir ja was vorgenommen.

Ja das weiß ich ;).

Insbesondere, wo es schon für jede relevante und zahlenmäßig starke Interessengruppe ein passendes Portal gibt. Welche Lücke willst du denn da besetzen? :)

Du nimmst die Distri, die du am besten kennst. Oder halt die, die dein Hoster hat.

Erfahrung habe ich nur mit Windows Servern und freeBSD...

Warum dann nicht FreeBSD als OS?

Du nimmst den Webserver, den du am besten kennst.
Apache kenn ich besser, lighttpd soll aber wirklich einen imensen Vorteil bringen.

"Soll" - aber welche Vorteile, für wen und unter welchen Bedingungen?

Ich würde mich zuallererst darauf konzentrieren, die zu erstellende Software zu bearbeiten, und ansonsten nur Komponenten einzusetzen, die du kennst. Macht das Leben deutlich einfacher. Sollte es tatsächlich irgendwann einmal ein Problem geben, was von Apache schlecht und von lighttpd besser gelöst wird, kannst du immer noch umstellen.

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.

Sie wird auf jeden Fall in PHP geschrieben da ich die anderen Sprachen nicht/wenig/ungenügend beherrsche.

Dann stell' keine Fragen nach Performance.

Jedes Performanceproblem ist lösbar, wenn die Problemanalyse des konkret aufgetretenen Problems vernünftig durchgeführt wird und zu folgerichtigen Ansätzen führt. Und wenn das Problem nicht lösbar ist, hilft auch der Wechsel der Programmiersprache nichts.

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.

Könntest du mir TDD genauer erläutern?

Googlen!

Für PHP: http://www.simpletest.org/

Ich muss in sehr vielen Punkten die du sagst Einsicht zeigen. Ich platze atm vor Eifer nach Taten. Deswegen soviele Fragen die ich mir eigendlich und normalerweise auch selbst beantworte. Aber ich habe gerne direkt die Meinung kompetenter Leute dazu.

Dein beabsichtigtes Projekt wird geschätzt mindestens zwei Mannjahre Entwicklungszeit benötigen. Du bist also allein mindestens zwei Jahre damit beschäftigt. Und mußt während der Projektlaufzeit von zwei Jahren zwischendurch auch auf die Weiterentwicklung der Technologie reagieren, die du verwendest. Beispielsweise neue Versionen der Server, von PHP (6, 7?), von Webtechnologien (was kommt nach AJAX?) etc.

Du hast also ausreichend Zeit, dich reinzufuchsen. Insbesondere aber benötigst du nicht vom Start weg gleich drei physikalische Server in deiner Testumgebung.

Der Server wird demnacht Lighttpd sein, auf Debian laufen und MySQL als DB und PHP als führende Projektsprache nehmen.

Bis auf lighttpd würde ich ja zustimmen.

- Sven Rautenberg

[Alexander (HH)]

Moin Moin!

Da ich seit ungefähr einem Jahr an einem vergleichbaren Projekt arbeite, kann ich Svens Ausführungen nur bestätigen.

Ein paar Ergänzungen noch:

Den Server kriegst du beim Hosting-Anbieter deines Vertrauens in jeder gewünschten Konfiguration.

Ich würde für's erste trotz Extra-Kosten einen Server mit RAID-1 (in Software) nehmen, das sorgt bei einem (gar nicht so seltenen) Festplattenausfall für eine wesentlich entspanntere Stimmung, weil der Provider einfach nur die tote Platte austauschen muß, ohne dass der Server tagelang tot ist. Eine gewisse Downtime wird es in aller Regel geben, weil die meisten günstigen Root-Server eben nicht komplett Hot-Plug-fähig sind. Aber die beschränkt sich dann auf eine Stunde oder so, die der Techniker braucht, um den Server runterzufahren, die Platte zu tauschen, und den Server wieder zu starten. Danach kann man im laufenden Betrieb fdisk laufen lassen und das RAID wieder aufbauen lassen.

Ein virtueller Root-Server auf einem dicken Server hat solche Probleme natürlich nicht, dafür muß man sich mit wahrscheinlich mit Resourcen fressenden Nachbarn rumschlagen und ist bei entsprechendem Erfolg der Plattform bald zum Umzug auf einen dedizierten Server genötigt.

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.

Schalte *ALLE* Services ab, die nicht benötigt werden. X11 hat auf einem Webserver genauso wenig verloren wie Samba oder Avahi. Idealerweise installierst Du die entsprechenden Pakete gar nicht erst, bzw. deinstallierst Du sie.

Auf "meinem" Server laufen exakt zwei von außen erreichbare Dienste: sshd und httpd. Außerdem laufen noch ntpd und postgresql, beide sind jedoch von außen nicht erreichbar, weil sie entweder gar keinen Server-Socket öffnen (ntpd) oder ausschließlich via localhost erreichbar sind (postgresql).

Vermeide frei zugängliche oder nur per Passwort geschützte Konfigurationssoftware. Setze SSH v2 mit Public-Keys statt Passworten ein, schalte Password-Authentication im sshd aus. Erlaube kein root-Login, verwende ausschließlich sudo.

Ich sehe auf "meinem" Server täglich Routine-Scans auf den SSH-Server, die mit Wörterbüchern vergeblich versuchen, funktionierende Kombinationen von Usernamen und Passworten zu finden. Ebenso gibt es reichlich Routine-Scans nach phpadmin, Wikis, Web-Mailern, Frontpage-Umgebungen, und einiger anderer Web-Software.

ssh ersetzt FTP in Form von scp und sftp vollständig und sicher. rsync über ssh reduziert außerdem das administrative Datenvolumen. Es ist also absolut unnötig, einen FTP-Server laufen zu lassen.

Die Datenbank sollte von außen nicht zu erreichen sein, d.h. die Anwendung connectet sich über Unix Domain Sockets oder eine Loopback-Adresse (127.0.0.0/255.0.0.0, z.B. 127.0.0.1) auf die Datenbank. Für Wartungsarbeiten kann man mit einem auf dem Server installierten DB-Kommandozeilen-Client arbeiten oder per SSH einen lokalen Port auf den DB-Server-Port auf der Loopback-Adresse tunneln und auf dem lokalen Rechner mit entsprechenden Mausschubser-Tools arbeiten.

4.) Letztendlich wollte ich 3 Server nehmen. Einen für die Datenbank, einen für die Userbilder und einen Für die PHP Files.

Overkill. Du wirst im ersten und sehr wahrscheinlich auch im zweiten Jahr genügend Arbeit haben, für Auslastung eines Servers durch entsprechende Userzahlen zu sorgen.

Plane so, dass Du diese Trennung im Erfolgsfall vornehmen kannst, aber lasse alle drei Aufgaben zunächst auf einem Server laufen. Überlege auch, dass Du bei getrennten Servern die Datenbank von außen erreichbar machst. Ein VPN oder eine dedizierte, von außen nicht erreichbare Verbindung (sprich: zwei Netzwerkkarten und ein Patchkabel) schaft da Abhilfe.

Mein System ist (aus Erfahrung mit "zu" erfolgreichen Systemen) sogar noch weiter auftrennbar: Ich könnte mehrere identisch konfigurierte Webserver parallel hinter einem Loadbalancer laufen lassen und -- wie schon von Dir angedacht -- statische Resourcen von getrennten Webservern ausliefern lassen, bei Bedarf auch nochmal über Loadbalancer. Auch aus der Datenbank könnte ich einen Cluster machen, um so die DB-Last auf mehrere Server zu verteilen. Das ist im Moment aber noch unsere geringste Sorge, noch stemmt der Root-Server unsere User-Anzahl locker als "Maschinchen für alles".

Ich will anfangs nicht mehr als 120€/Monat investieren - geht sowas?

Nicht mit so "größenwahnsinnigen" Plänen. Nimm den kleinsten Root-Server, der zwei Platten hat. Suche Dir einen Hoster, bei dem Du nicht Kunde 25.893.382 bist. "Mein" Hoster wirbt mit "Menschlich. Einfach. Besser", und den kann ich nur weiter empfehlen -- schnell, kompetent und freundlich. Und die Kundennummer ist nur vierstellig. ;-)

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.

Wenn die Community so groß wird, dass der Server Dauerlast hat, sollte auch genügend Geld reinströmen, um einen zweiten, notfalls einen dritten Server anzuschaffen und sich ggf. auch mal ein paar Tage externe Beratung zu kaufen.

Und es ist ja ganz offensichtlich (oder?), dass Webserver *UND* Datenbank-Server genau in dem Moment beide viel CPU, viel RAM und viel Festplatte haben wollen, in dem ein Request abgearbeitet wird. Es bietet sich also an, als ersten Schritt im Falle des Erfolges Webserver und Datenbank auf zwei getrennte Maschinen zu packen. Meistens hat die DB etwas weniger Last und kann auf der schwächeren (alten) Maschine bleiben, während man den Webserver auf die aktuellere Hardware umzieht. Damit sich DB-Traffic und HTTP-Traffic nicht ins Gehege kommen, ist ein DB-Netz (und sei es nur ein Crossover-Kabel und zwei 100er-LAN-Karten) empfehlenswert.

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?

Drittens: Stehen Dir Sonderfall-Optimierungen (wie z.B. sehr gehäuft in MySQL) und andere exotische Dinge im Weg oder nützen sie Dir sogar?

Ich kam für mein Projekt zu dem Ergebnis, dass *mir* MySQL mehr im Weg stehen würde als PostgreSQL, und das PostgreSQL gegenüber (dem allen ernstes von einem selbsternannten Experten vorgeschlagenen) Oracle einen "geringfügigen" Kosten- und Dokumentationsvorteil hat.

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.

Exakt.

Außerdem ein paar Dinge, die man im Laufe der Zeit entweder lernt oder an denen man kläglich scheitert:

* Arbeite nicht ohne schriftlichen Vertrag, egal ob selbständig oder angestellt. Eine "Hallo Welt, hier ist Hein Meier"-Seite für den Nachbarn kann man für zwei Scheine auch mal ohne Vertrag machen, aber ein Projekt, das Wochen bis Jahre dauert, sollte auf einem Vertrag basieren.

* Arbeite nicht ohne Plan. Schreibe einen Plan für das Projekt, und einen weiteren Plan für jeden Aspekt. Fang mit den wichtigsten Aspekten an, plane Optionales später detailiert. Auch ein Schmierzettel mit zwei Skizzen und 10 Stichworten kann ein Plan (für einen sehr kleinen Aspekt) sein.

* Leite aus den Plänen einen Zeitplan ab. Vergiß beim Schätzen des Aufwands nicht, dass Du Zeit für Tests, Debugging, Pannen, weitere Pläne, Administratives und die eine oder andere unangenehme Überraschung brauchst. Bauchgefühl + 100% + großzügig Aufrunden funktioniert bei mir ganz gut. Ohne Bauchgefühl mußt Du einfach ins Blaue hinein Codezeilen und darauf basierend Zeit raten, während der Umsetzung zählen und messen, und den Fehler beim nächsten Rateversuch mit einberechnen. Dann zählst und mißt Du wieder und nimmst den neuen Fehler mit in die dritte Schätzung, und so weiter. Irgendwann entwickelst Du Dein persönliches Bauchgefühl und Deinen persönlichen Korrekturfaktor.

* Sammle Feedback von Deinen Nutzern, so viel wie möglich. Berücksichtige das Feedback bei der weiteren Planung. Wir haben so herausgefunden, dass ein von uns für völlig unwichtig erachtetes Feature für unsere User quasi lebensnotwendig ist, und diesem Feature entsprechend Priorität bei der Entwicklung eingeräumt.

* Stelle 100% sicher, dass Du für Entwicklungsserver, Entwicklungs-Workstation *UND* Produktivserver zu jeder Zeit ein verifiziertes Backup hast, von dem Du die betreffene Maschine jederzeit ab "bare metal" wiederherstellen kannst.

* Benutze eine Quelltextverwaltung (Subversion, GIT, ...), committe jeden kleinen, getesteten Arbeitsschritt und kommentiere diesen Arbeitsschritt in der Quelltextverwaltung (nicht "was geändert", sondern "warum geändert" -- "was geändert" liefert Dir "svn diff" vollautomatisch)

* Benutze eine Fehler- bzw. Anforderungsverwaltung, wie z.B. Bugzilla, und trage JEDEN Fehler und JEDE neue Anforderung dort ein.

* Automatisiere alle Routine-Arbeitsschritte durch Makefiles oder Shell-Scripte. Halte diese ebenfalls in der Quelltextverwaltung. So reicht dann ein "make update-testserver" oder "make update-liveserver" aus, um den aktuellen Stand auf den Server zu bringen, *OHNE* dass Du jedes mal wieder darüber nachdenken mußt, was Du alles berücksichtigen mußt. rsync und Make (auch auf dem Server) sind dabei extrem hilfreich.

* Teste und entwickle nicht auf dem Produktivsystem.

* Vertraue keinem einzigen Wert, der nicht aus deinem Programm kommt. Mißtraue allen Benutzereingaben, allen URL-Parametern, allen Cookies, allen Daten, die per GET oder POST hereinkommen. Behandle all dieses als gezielten Angriff eines hoch motivierten, exzellent ausgestatteten und exzellent ausgebildeten Bösewichts auf Deine Software, bis durch eine gründliche Validierung das Gegenteil bewiesen ist. Erst dann beginne mit der Verarbeitung der Eingaben.

* Überwache alle (relevanten) Logfiles des Produktivsystems.

* Oftmals reicht erstmal aus, eine Lösung zu finden, die für 80% der User ausreicht. Erst recht, wenn die restlichen 20% einen astronomischen Aufwand erfordern.

* Wenn Du als Selbständiger oder mit einer Mini-Firma das Projekt als einzige Einnahmequelle durchziehst, geh davon aus, dass das Geld irgendwann aufgebraucht ist, und Du fremdes Geld benötigst. Wenn Du nicht gerade auf einem sehr großen Sack Geld sitzt, wird das vor Fertigstellung des Projekts sein.

* Wenn Du als Angestellter arbeitest, oder spätestens wenn Du einen Investor brauchst, sieh zu, dass Du jederzeit IRGENDETWAS vorführen kanst, und sei es noch so häßlich und zickig. Sei in jeder Minute bereit vorzuführen, dass die Entwicklung voranschreitet.

Alexander

[ritschmanhard]

Hi Max,

Ich will nur kurz auf folgenden Punkt eingehen (für den Rest habe ich zuwenig Erfahrung, um qualifiziert zu antworten):

1.) Warum einen Linux Server und nicht Windows Server?
Ich denke mal er ist sicherer, stabiler und schneller - der Linux. Gibt es noch andere?

Ja, etliche:
a) Wenn dir der Speicherplatz knapp wird, kannst du unter Linux einfach eine Platte ins bestehende Filesystem dazumounten.
b) Linux erfordert nicht, dass der Rechner nach dem Schließen einer Sicherheitslücke neu gestartet wird
c) Linux bietet in der default Konfiguration der meisten Distributionen eine wesentlich bessere Fernwartbarkeit.
d) Linux unterstützt mit den meisten Filesystemen (ExtX, ReiserFS) eine wesentlich klarere Zugriffsberechtigungssteuerung

Somit ergänze ich (ohne Anspruch auf Vollständigkeit) noch um die Attribute: erweiterbarer, dauerbetriebsgeeigneter, komfortabler (im Fernzugriff).

Grüße,
Richard

[Sven Rautenberg]

Moin!

Hi Max,

Ich will nur kurz auf folgenden Punkt eingehen (für den Rest habe ich zuwenig Erfahrung, um qualifiziert zu antworten):

1.) Warum einen Linux Server und nicht Windows Server?
Ich denke mal er ist sicherer, stabiler und schneller - der Linux. Gibt es noch andere?

Ja, etliche:
a) Wenn dir der Speicherplatz knapp wird, kannst du unter Linux einfach eine Platte ins bestehende Filesystem dazumounten.

Geht auch mit Windows.

b) Linux erfordert nicht, dass der Rechner nach dem Schließen einer Sicherheitslücke neu gestartet wird

Doch, Kernelpatches erfordern zwingend einen Neustart. Andersherum erfordern Patches unter Windows auch nicht jedesmal einen Neustart.

c) Linux bietet in der default Konfiguration der meisten Distributionen eine wesentlich bessere Fernwartbarkeit.

Wenn du einen Server bei einem Hoster mietest, dürfte dieses Argument nicht relevant sein.

d) Linux unterstützt mit den meisten Filesystemen (ExtX, ReiserFS) eine wesentlich klarere Zugriffsberechtigungssteuerung

Klarer vielleicht, aber auch einfacher. ACLs sind standardmäßig nicht aktiv, obwohl man sowas in vielen Fällen gut brauchen könnte.

Somit ergänze ich (ohne Anspruch auf Vollständigkeit) noch um die Attribute: erweiterbarer, dauerbetriebsgeeigneter, komfortabler (im Fernzugriff).

Das sind alles keine wirklich stichfesten Argumente.

- Sven Rautenberg

[suit]

a) Wenn dir der Speicherplatz knapp wird, kannst du unter Linux einfach eine Platte ins bestehende Filesystem dazumounten.

das ist unter windows auch problemlos möglich

b) Linux erfordert nicht, dass der Rechner nach dem Schließen einer Sicherheitslücke neu gestartet wird

das erfordert windows auch nicht, es kommt auf die art drauf an - kernel-patches wirst du auch unter linux nicht ohne reboot einspielen können (spezialsoftware wie ksplice jetzt mal ausgenommen)

c) Linux bietet in der default Konfiguration der meisten Distributionen eine wesentlich bessere Fernwartbarkeit.

auch das halte ich für ein gerücht, jede für den servereinsatz gedachte windows-version wird mit rdp ausgeliefert, mit ausnahme des einschaltknopfs des rechners ist das exakt wie davorzusitzen

d) Linux unterstützt mit den meisten Filesystemen (ExtX, ReiserFS) eine wesentlich klarere Zugriffsberechtigungssteuerung

auch ntfs hat eine klare rechtesteuerung die für den betrieb eines webservers bei weitem ausreicht