Hallo Depia,
jetzt, wo wir wissen was du konkret vor hast, können wir dir auch eine wirklich sinnvolle Antwort geben. Du bist ja nicht der Erste, der vor diesem Anwendungsfall steht. Ich will versuchen zu erklären, wie man einen solchen Fall sinnvollerweise anpackt.
Zum Anderen darfst du nicht den Fehler machen, den nginx eines vServers mit einem Apache eines (professionellen) Shared-Hostings zu vergleichen. Dein nginx wird die meiste Zeit im IO-Wait hängen, den andere vServer auf dem selben Host verursachen und in dieser Zeit rein gar nichts tun, während die Apache-Cluster der Shared-Hoster hoch optimiert tausende von Requests weg schaufeln ohne mit der Wimper zu zucken.
Datenbanken cachen übrigens ihre Abfragen selbständig, so dass du mit Memchached nicht viel Performance rausholen wirst. Zudem ersparst du dir Probleme mit Cache-Poisoning und Invalidierung, wenn du nicht noch eine Abstraktion oben drauf packst.
Du legst dir irgendwo im Netz dein Repo an, ich glaube bitbucket hat auch kostenlos private Repos. Dort läuft die Entwicklung zusammen.
Jetzt mietest du dir irgendwo Billig-Webspace und richtest dir eine Staging-Umgebung deines Projektes ein, die du mit deinem Deployment-Tool aus dem zentralen Repo ausrollst, sobald ein Entwickler ein neues Feature fertig hat. Auf der Staging-Umgebung kannst du in aller Ruhe testen. Wenn das Ergebnis zufriedenstellend ist, rollst du mit dem Deployment-Tool deine finale Production-Umgebung aus. Es gibt Deployment-Tools, die per SSH oder sogar per FTP ausrollen können.
Obendrein gehst du ein echtes Projekt-Risiko ein. Die Wahrscheinlichkeit, dass du mit deinem jetzigen Wissenstand einen Fehler machst ist hoch. Wenn dir dein vServer gehackt wird und du eine Kompromitierung deiner Kundendaten einräumen musst, kannst du deine schönes Projekt mit einer Träne im Knopfloch sofort wieder absagen.
jetzt, wo wir wissen was du konkret vor hast, können wir dir auch eine wirklich sinnvolle Antwort geben. Du bist ja nicht der Erste, der vor diesem Anwendungsfall steht. Ich will versuchen zu erklären, wie man einen solchen Fall sinnvollerweise anpackt.
Diese Aussage ist viel zu allgemein und unkonkret. Bei statischen Files auf ein und dem selben Server unter hoher Last gemessen, ja. So einfach ist die Realität leider nicht. Zum einen ist deine Web-Anwendung sicher nicht rein statisch. In diesem Fall wird die Haupt-Last von der Webanwendung selbst verursacht und das verhalten der Frontend-Webserver wird zusehends vernachlässigbar. Was bringt es dir, wenn der Frontend-Server 300 statt 200 Files in der Sekunde raus schicken kann, wenn deine Web-Applikation nur 20 Requests pro Sekunde schafft?
Zum Anderen darfst du nicht den Fehler machen, den nginx eines vServers mit einem Apache eines (professionellen) Shared-Hostings zu vergleichen. Dein nginx wird die meiste Zeit im IO-Wait hängen, den andere vServer auf dem selben Host verursachen und in dieser Zeit rein gar nichts tun, während die Apache-Cluster der Shared-Hoster hoch optimiert tausende von Requests weg schaufeln ohne mit der Wimper zu zucken.
Nein. Die sind genau so sicher. Die Lücken liegen in den Web-Applikationen hinter den Webservern.
Siehe oben. Wenn dein vServer im IO-Wait hängt oder der RAM vom Host-System in den Swap geschoben wurde, steht der Datenbank-Request. Zusätzlich teilen sich bei vServern noch alle Prozesse eine einzige VM, da du nginx, Web-App und Datenbank-Server auf auf der gleichen Maschine laufen hast. Bei Shared-Hosting hast du einen dedizierten Datenbank-Cluster, der mit Sicherheit schneller ist als du es auf einer einzelnen VM je realisieren kannst.
Datenbanken cachen übrigens ihre Abfragen selbständig, so dass du mit Memchached nicht viel Performance rausholen wirst. Zudem ersparst du dir Probleme mit Cache-Poisoning und Invalidierung, wenn du nicht noch eine Abstraktion oben drauf packst.
Du willst die Coder per SVN direkt in die Produktiv-Umgebung greifen lassen? Das ist der sichere Tod für einen stabilen Betrieb deines Projektes! Was du suchst nennt sich Deployment. z.B. capistrano, fabric oder batou.
Du legst dir irgendwo im Netz dein Repo an, ich glaube bitbucket hat auch kostenlos private Repos. Dort läuft die Entwicklung zusammen.
Jetzt mietest du dir irgendwo Billig-Webspace und richtest dir eine Staging-Umgebung deines Projektes ein, die du mit deinem Deployment-Tool aus dem zentralen Repo ausrollst, sobald ein Entwickler ein neues Feature fertig hat. Auf der Staging-Umgebung kannst du in aller Ruhe testen. Wenn das Ergebnis zufriedenstellend ist, rollst du mit dem Deployment-Tool deine finale Production-Umgebung aus. Es gibt Deployment-Tools, die per SSH oder sogar per FTP ausrollen können.
Ganz schwerer Denkfehler. Du vergisst, dass deine eigene Arbeit auch Geld wert ist, auch wenn du sie nicht bezahlen musst. Du musst enorm viel Zeit aufbringen, um dir das nötige Wissen anzueignen. In dieser Zeit kannst du nicht das tun, was du sichtlich besser kannst: Dein Projekt umsetzen. Das ist echter Verlust!
Obendrein gehst du ein echtes Projekt-Risiko ein. Die Wahrscheinlichkeit, dass du mit deinem jetzigen Wissenstand einen Fehler machst ist hoch. Wenn dir dein vServer gehackt wird und du eine Kompromitierung deiner Kundendaten einräumen musst, kannst du deine schönes Projekt mit einer Träne im Knopfloch sofort wieder absagen.
Ich hoffe ich konnte dir erklären, dass du da einem Irrtum unterliegst. Webspace ist mit Sicherheit performanter als ein einzelner vServer. Denke bitte bei Webspace nicht nur an die Billig-Hoster. Die Einschränkungen sehe ich, ich denke aber nicht, dass sie für dich relevant sind. Eher im Gegenteil: Sie entbinden dich von einer enormen Verantwortung und geben dir die Freiheit dich um den Kern deines Projektes zu kümmern.