Es ist ein beruhigender Text in einem Verkaufstrichter, kein technisches Versprechen. Wenn ein Anbieter "unbegrenzt" auf die Tarifkarte druckt, verspricht er nicht unendlichen Transfer über Physik und Budgets hinweg; er verspricht, einen bestimmten Posten auf Ihrer Rechnung nicht zu messen, während er alles andere kontrolliert, was tatsächlich bestimmt, ob Ihre Website schnell und erreichbar bleibt. Die praktische Wahrheit ist einfach und ein wenig irritierend: Ihr Tarif mag den monatlichen Transfer nicht messen, aber er wird Sie auf andere Weise absolut messen, sobald Ihre Nutzung ungewöhnlich, sprunghaft oder teuer zu bedienen aussieht.
Ich habe dies oft genug beobachtet, um das Muster vom ersten Support-Thread an zu erkennen. Die Website startet stark, die Rankings steigen, eine Kampagne trifft ein, und dann entwickelt der "unbegrenzte" Tarif eine Persönlichkeit. Anfragen dauern länger. Statische Assets kriechen. Arbeiter stauen sich. Fehler tauchen in Taschen auf, weil der Anbieter beginnt, die gemeinsame Umgebung zu schützen, nicht Ihren Erfolg. Das ist keine Bosheit; es ist eine wirtschaftliche Realität. Anbieter verkaufen "unbegrenzt", um kleine Websites anzuziehen, deren tatsächliche Nutzung winzig und vorhersehbar ist. Die Ausreißer—Video, Downloads, öffentliche APIs, schlecht gecachte Apps—werden zum "Missbrauch" in dem Moment, in dem sich die Grafiken bewegen. Die AGB und die Ressourcenzuteilungen greifen ein. Wenn Sie "unbegrenzt" gekauft haben und erwarten, dass die Startbahn skaliert, werden Sie sich überrumpelt fühlen. Wenn Sie es als auf dem Papier unbegrenzt, aber in der Praxis sehr gemessen betrachten, werden Sie klügere Architekturentscheidungen treffen und die Sperrungs-E-Mail vermeiden, die immer zum ungünstigsten Zeitpunkt eintrifft.
Bandbreite, Übertragung, Durchsatz und Portgeschwindigkeit sind nicht dasselbe
Es ist mir egal, wie oft die Branche die Begriffe verwischt – wenn wir ehrlich darüber sein wollen, was Sie tatsächlich schaffen können, müssen wir das Vokabular trennen. Bandbreite ist die Größe der Leitung zu einem bestimmten Zeitpunkt. Durchsatz ist das, was Sie tatsächlich über diese Leitung erreichen, nachdem Overhead, Konkurrenz und Drosselung berücksichtigt wurden. Datenübertragung ist die Gesamtmenge, die über einen bestimmten Zeitraum, normalerweise einen Monat, bewegt wird. Portgeschwindigkeit ist die harte Obergrenze für den sofortigen Fluss, typischerweise ausgedrückt als 10 Mbit/s, 100 Mbit/s, 1 Gbit/s oder höher.
"Unmetered" ist ein Abrechnungsversprechen über die monatliche Übertragung, nicht über die sofortige Rate, die Ihre Pakete am Montagmittag erhalten. "Unbegrenzt" ist eine Marketingfloskel, die impliziert, dass es keine Obergrenze gibt, aber was Sie wirklich haben, ist ein Plan, der Gigabytes für Überschreitungen nicht zählt, während er Einschränkungen durch alles andere durchsetzt: CPU-Anteile, I/O, Prozessanzahlen, Verbindungskonkurrenz und letztlich der Port, den Ihre Pakete durchlaufen müssen. Ein 1 Gbit/s-Port kann theoretisch eine enorme Menge in einem Monat bewegen, aber wenn der Host Ihren Port nach fünf Minuten konstanten Durchsatzes auf 100 Mbit/s formt – oder Ihnen einfach eine "burstfähige" Spur gibt, die unter Last heruntergestuft wird – verdampft Ihre theoretische Übertragung in reale Wartezeit und fehlgeschlagene Anfragen. Die Leitung, von der Sie dachten, Sie hätten sie gekauft, ist die Leitung, die Sie nur dann belegen, wenn Sie ruhig sind.
Wenn ich einen Plan überprüfe, frage ich nicht: "Ist die Bandbreite unbegrenzt?" Ich stelle eine andere, unschönere Frage: "Was ist der schlechteste sofortige Durchsatz, den ich garantiert bekomme, wenn meine Nachbarn und ich alle beschäftigt sind?" Das ist die Zahl, die verhindert, dass Ihr Checkout stockt, Ihre Bilder kriechen und Ihre Hintergrundaufgaben eine Landebahn von Wiederholungen aufbauen, für die Sie später bezahlen werden.
Wie Shared Hosting darauf ausgelegt ist, grenzenlos auszusehen (bis es das nicht mehr ist)
Shared Hosting ist ein Jahrmarktstrick, der auf Durchschnittswerten basiert. Die meisten Websites sind winzig. Der meiste Traffic ist auf freundliche Weise bursty. Die meisten Seiten werden nach dem ersten Crawl zwischengespeichert. So können Hosts Rechenleistung, Speicher, Speicher-I/O und Netzwerkspuren überbuchen und gleichzeitig fröhliche Dashboards für Tausende von Kunden bereitstellen. Die Maschinerie hinter dieser Illusion ist ein Nest aus Fair-Share-Scheduler und Quotasystemen. CPU-Anteile verhindern, dass ein einziges Konto lange einen vollständigen Kern beansprucht. IOPS-Shaping verhindert, dass laute Nachbarn das SAN ausgehungert lassen. PHP-FPM- und Node-Prozesslimits stellen sicher, dass nur eine Handvoll Anfragen gleichzeitig dynamisch ausgeführt werden können. Inode-Grenzen begrenzen stillschweigend die Anzahl der Dateien, die Sie auf der Festplatte behalten können, und ersticken medienlastige Websites, bevor der Transfer jemals in einem Diagramm erscheint.
Das Entscheidende, was zu beachten ist, ist, dass keines dieser Systeme die „Bandbreite“ berührt. Diese bleibt ungemessen, sodass der Anspruch technisch ehrlich bleibt. Sobald Ihre Anwendung mehr als einen Moment lang geschäftig aussieht, erzwingen die Fair-Share-Regeln die „typische Nutzung“, indem sie die Teile Ihres Stacks drosseln, die sie kontrollieren. Sie werden sehen, dass dynamische Anfragen in die Warteschlange gestellt werden, während statische Assets in Ordnung erscheinen. Dann verlangsamen sich statische Assets, weil der Ursprung zum Engpass wird, den ein CDN nicht vollständig maskieren kann. Der Host berechnet Ihnen immer noch nicht den Transfer. Sie sorgen einfach dafür, dass Sie weniger davon nutzen, indem sie reduzieren, wie schnell Sie ihn bereitstellen können.
Ich denke nicht, dass Shared Hosts deswegen Bösewichte sind. Das Modell funktioniert für die überwiegende Mehrheit der Websites und hat das Web für kleine Publisher kostengünstig gehalten. Aber der Ausdruck „unbegrenzte Bandbreite“ vermittelt das falsche mentale Modell. Es lädt Sie ein, zu entwerfen, als hätten Sie eine eigene Spur, und das haben Sie nicht. Sie haben die Erlaubnis, Wasser in einen Eimer zu gießen, ohne pro Liter zu bezahlen, aber Sie teilen sich immer noch den Wasserhahn.
Das Kleingedruckte, das tatsächlich Ihre Nutzung regelt
Wenn Sie die Wahrheit wissen wollen, lesen Sie nicht die Preistabelle; lesen Sie die Richtlinie zur akzeptablen Nutzung. Sie werden zuckersüße Formulierungen wie „typische Websites“ und „fairer Gebrauch“ finden, die übersetzen zu „wenn Sie anfangen, wie ein Filesharing-Knoten, eine Streaming-Site, ein Medien-Spiegel oder ein Download-Hub auszusehen, behalten wir uns das Recht vor, Sie zu drosseln, zu migrieren oder zu sperren.“ Sie werden Verbote für Audio- und Videostreaming aus dem Ursprung, Dateiübertragungen im großen Maßstab, auf Webspace gespeicherte Sicherungsarchive, öffentlich zugängliche ZIP-Sammlungen und „ressourcenintensive“ Skripte finden, die jeweils länger als ein paar Sekunden laufen. Sie werden tägliche CPU-Sekundenbeschränkungen, Datenbankabfrageobergrenzen und Verbindungszählungen finden, die Ihren bevorzugten asynchronen Crawler wie einen Angriff aussehen lassen.
Eintrittsprozesslimits sind besonders heimtückisch. In cPanel-Umgebungen bedeutet ein „Eintrittsprozess“ oft „die Anzahl der gleichzeitigen dynamischen Anfragen, die gestartet werden dürfen.“ Erreichen Sie diese Grenze, wird der nächste Besucher nicht in die Warteschlange gestellt; sie erhalten Fehler. I/O-Grenzen und IOPS-Zahlen tun dasselbe mit der Festplatte. Inode-Grenzen schneiden Sie ab, wenn Sie „zu viele Dateien“ haben, was ehrgeizige Medienbibliotheken auslöst, bevor sie den Durchsatz berühren. Keine dieser Dinge verletzt „unbegrenzte Bandbreite.“ Sie stellen nur sicher, dass Sie sehr wenig davon nutzen, wenn Ihre Website zu wachsen beginnt.
Ich habe die Anzahl der Pläne aus den Augen verloren, die „unbegrenzt“ behaupten, während sie stillschweigend die CPU auf „100% eines Kerns für ein paar Sekunden“ setzen, I/O auf „einige Megabyte pro Sekunde anhaltend“ und Prozesse auf „eine Handvoll gleichzeitig.“ Das ist ein Gürtel, Hosenträger und ein Seil. Wenn Sie alle drei erreichen, laufen Sie nicht; Sie schlurfen.
Wie „unbegrenzt“ an einem geschäftigen Montag aussieht
Stellen Sie sich einen normalen Montag vor, nachdem eine Erwähnung am Wochenende Ihnen frische Aufmerksamkeit verschafft hat. Ihr HTML ist relativ leicht, Ihre Bilder sind in Ordnung, Sie verlassen sich auf ein CDN für statische Ressourcen und Ihr Ursprung verarbeitet die dynamischen Teile. Der Verkehr steigt um das Fünffache. Zunächst ist alles in Ordnung, da die Caches warm sind und das CDN die meisten Bildanfragen abfängt. Dann fallen Ihre dynamischen Endpunkte zurück. Die Prozessgrenze des Hosts hält nur eine kleine Anzahl gleichzeitiger PHP- oder Node-Worker aktiv. Das Warten beginnt, und die Antwortzeiten verlängern sich so weit, dass die Zeitlimits zwischen den Diensten überschritten werden. Das CDN hilft weiterhin, aber Cache-Misses bei HTML beginnen zu schmerzen. Ihre Datenbank wird gesprächiger, und der I/O-Planer zieht eine weitere Scheibe ab, da Sie jetzt als „ressourcenintensiv“ gelten. Ihre Kunden klicken mit perfektem Timing auf Bilder, die nicht im CDN heiß waren, und ziehen so Burst-Anfragen vom Ursprung an, die mit langsamer dynamischer Arbeit kollidieren.
Was als nächstes passiert, hängt vom Host ab. Einige Hosts drosseln Sie schrittweise, bis die Leistung so schlecht ist, dass die Besucher aufgeben und Ihr „Durchschnitt“ wieder normal wird. Andere lösen automatisierte Missbrauchsregeln aus und verschieben Ihr Konto in einen niedrigeren Pool oder ein Quarantäne-VLAN. Einige werfen immer noch die klassische 509-Antwort, „Bandbreitenlimit überschritten“, obwohl sie keine Bytes zählen – 509 ist nur ein nützliches Stoppschild, um Zeit zu gewinnen, während sie überprüfen. Das Ergebnis fühlt sich identisch an: Das Versprechen von „unbegrenzt“ verdampft genau dann, wenn Sie es am dringendsten benötigen.
Eine Seite, die hauptsächlich zwischengespeichertes HTML und statische Ressourcen bereitstellt, könnte mit verärgerten Besuchern durchkommen. Ein einkaufswagenlastiger Shop oder eine suchlastige App werden stark getroffen. Der Schmerz zeigt sich selten als saubere, einzelne Kennzahl. Es ist ein Mosaik aus kleinen Verzögerungen, die sich zu fehlgeschlagenen Checkouts und steigender Abwanderung summieren.
Bevor wir tiefer gehen, möchte ich etwas Konkretes und Wiederverwendbares schaffen, damit Sie die praktische Obergrenze sehen können, auch wenn ein Plan behauptet, sie existiere nicht.
Ich werde für ein paar Minuten in harte Zahlen eintauchen. Dies ist ein Premium-Abschnitt, der sich ausschließlich auf die Mathematik konzentriert, die Sie auf einem Bierdeckel machen können, um die Portgeschwindigkeit in monatlichen Transfer und dann in Seitenaufrufe zu übersetzen. Wenn Sie jemals Schwierigkeiten hatten, „1 Gbit/s ungemessen“ in „Wie viele Besuche kann ich tatsächlich bedienen?“ zu übersetzen, wird hier der Fokus klarer.
Premium content
Melde dich an, um fortzufahren
Die stillen Killer: CPU-Drosselung, IOPS-Formung und Prozessbeschränkungen
Wenn Sie jemals das Gefühl hatten, dass eine Website langsamer wird, während die Grafiken „normal“ aussehen, haben Sie die stillen Killer getroffen. Die CPU-Drosselung ist am sichtbarsten, wenn man weiß, wo man hinschauen muss. Geteilte Hosts weisen einen Teil eines Kerns für Auslastungsspitzen zu und drosseln Sie dann bei anhaltender Belastung. Ihre App stürzt nicht ab; sie wird langsamer. Das reicht aus, um Suchrankings und Konversionsraten zu beeinträchtigen, ohne Alarme auszulösen, die den Support einschalten würden.
IOPS-Formung ist subtiler. Datenbanken leben und sterben durch Speicherlatenz. Dateischwere Apps auch. Hosts verwenden cgroups und Speicher-QoS, um zu verhindern, dass große Nutznießer das Array aushungern. Sie sehen keinen Fehler; Sie sehen, wie eine zwanzig Millisekunden dauernde Festplattenwartezeit zu achtzig wird, was die Anforderungszeiten in eine neue, hässlichere Verteilung zieht. Kombinieren Sie das mit einer niedrigen Prozessgrenze und Sie haben eine perfekte Quetschbox gebaut. Anfragen dauern länger, also sind mehr Anfragen gleichzeitig, was die Grenze schneller erreicht und neue Besucher auf den Boden wirft.
Prozessbeschränkungen sind schließlich das Fallbeil. Viele Pläne begrenzen PHP-FPM oder ähnliche auf eine Handvoll Kinder. Einige fügen eine Begrenzung der insgesamt gleichzeitigen Prozesse pro Benutzer hinzu. Beide lassen einen Host lächeln und „unbegrenzte Bandbreite“ versprechen, während sie sicherstellen, dass Sie praktisch nicht sehr viel senden können. Wenn Sie jemals einem Phantom-Engpass im CDN oder in Ihrem Anwendungscode nachgejagt sind, nur um zu entdecken, dass der Host acht Worker erlaubt und es dabei belässt, haben Sie die Falle gespürt.
Ich setze „unbegrenzte Bandbreite“ nicht als Problem in mein Risikoregister, das behoben werden muss. Ich reduziere meine Abhängigkeit davon. Das Modell, das für die meisten kleinen und mittelgroßen Websites funktioniert, ist langweilig und effektiv. Cachen Sie HTML am Rand so lange, wie es Ihr Inhalt zulässt. Schieben Sie Bilder, CSS und JS zu einem CDN, das Sie tatsächlich in der Produktion mit einer hohen Trefferquote validieren, nicht nur ein Logo. Laden Sie schwere Medien in den Objektspeicher aus und richten Sie Ihr CDN dorthin, sodass das Original es nie sieht. Konzentrieren Sie das Original auf dynamische Lese- und Schreibvorgänge, die wirklich Berechnung erfordern, und machen Sie diese so zustandslos und schnell wie möglich.
Wenn Sie das tun, wird der „unbegrenzte Bandbreiten“-Plan akzeptabel, weil Sie ihn nicht bitten, die Last zu tragen, die er ohne Drama nicht tragen kann. Selbst wenn der Host Ihr Original formt, absorbiert das CDN die zufällige Natur des Datenverkehrs. Ihr p95 stabilisiert sich und Sie gewinnen Zeit, eine Entscheidung zu treffen, wenn das Wachstum real ist, anstatt während eines Ausfalls zu reagieren. Der gesamte Kleingedruckte existiert immer noch, aber Sie treten nicht darauf. Sie haben ein kleines, wendiges Original gebaut, anstatt ein Lagerhaus.
Ich setze niemals Videostreaming, Dateidownloads, öffentliche Software-Spiegel oder Backup-Verteilung auf einen Plan, der „unbegrenzt“ sagt. Ich sage das als jemand, der versucht hat, sie durchzudrücken und dann nachträglich mit ToS-Sprache verhandelt hat. Diese Workloads sind nicht das, wofür Shared Hosting gebaut ist, und der Host wird Sie im Namen des Schutzes aller anderen herunterfahren. Selbst wenn Sie kurzzeitig damit durchkommen, sind Sie nur eine Erwähnung von Seiten wütender E-Mails und einer Migration um Mitternacht entfernt.
Schwere ZIP-Archive von Produktassets oder Lernmaterialien lösen dieselben Alarme aus. Öffentliche APIs, die Client-Polling fördern, werden das ebenfalls tun. Und alles, was die Benutzer dazu ermutigt, dieselbe mehrmegabyte Datei wiederholt über neue Verbindungen abzurufen, wird schneller als erwartet auf Port-Shaping stoßen. Der Faden, der diese Fälle verbindet, ist einfach: Es handelt sich um Hoch-Ausgangs-, Niedrig-Rechen-Workloads, die die Transitrechnung des Hosts angreifen, ohne die CPU oder I/O zu verbrauchen, die ihre Scheduler messen sollen. Diese Diskrepanz ist genau der Grund, warum „unbegrenzte Bandbreite“ als Ausdruck existiert. Es ist ein weiches Versprechen, das augenblicklich widerrufen wird, sobald Ihre Nutzung aufhört, wie ein kleiner Blog auszusehen.
Ich möchte Ihnen einen Übersetzungsleitfaden von einem Anwalt mit Benchmarks geben, den Sie behalten können. Der nächste Abschnitt ist ein Premium-Abschnitt, in dem ich die gängigsten Klauseln, die Hosts verwenden, in betriebliche Realität übersetze. Wenn Sie sonst nichts lesen, lesen Sie dies, wenn Sie um 1 Uhr morgens einen Plan durchsuchen und sich fragen, ob „unbegrenzt“ Ihren nächsten Start tragen wird.
Premium content
Melde dich an, um fortzufahren
Überwachung dessen, was wichtig ist, damit Sie Bescheid wissen, bevor die Sperr-E-Mail eintrifft
Das Dashboard, das Ihr Host Ihnen zur Verfügung stellt, wird Sie nicht vor dem bevorstehenden Ausfall warnen. Es wird Durchschnitte und Summen melden, während der Schmerz im langen Ende verborgen bleibt. Ich beobachte andere Signale. Der Vergleich von Origin-Egress und CDN-Egress zeigt mir, ob mein Cache seine Arbeit macht. Wenn der Origin-Egress schneller als die Besuche steigt, weiß ich, dass etwas umgangen oder zu aggressiv geleert wird. Die Verbindungskonkurrenz ist der Kanarienvogel für Prozessgrenzen; wenn gleichzeitige Verbindungen eine flache Decke erreichen, erwarte ich sofortige Fehler für neue Besucher. Die 95-Prozent-Bandbreite und die Anforderungszeit sind wichtiger als Durchschnittswerte, weil sie die Tageszeiten vorhersagen, in denen der Host Sie beeinflussen wird und Ihre Benutzer ihre Reise nicht abschließen können.
Die CPU-Steal-Zeit ist ein Geruchstest für die gemeinsame Umgebung. Wenn ich sehe, dass Steal während meiner ruhigen Stunden ansteigt, weiß ich, dass ich mit Nachbarn konkurriere und dass mein Burst auf einem müden Knoten landen wird. Langsame Abfragen lohnen sich immer, auch wenn Sie glauben, keine Zeit zu haben; das Beheben eines schlechten Index kann den Unterschied zwischen dem Überleben einer Erwähnung und einem Tag voller Entschuldigungen ausmachen. Fehlerbudgets—die Anzahl von Fehlern, die Sie in einem Zeitfenster zulassen, bevor Sie die Benutzererfahrung als verschlechtert betrachten—verbinden all dies miteinander. Wenn Ihre Fehler steigen, bevor der Verkehr dies tut, haben Sie unsichtbare Reibung, und "unbegrenzt" wird nichts abfedern.
Folgen Sie dem Geld und die Geschichte hört auf, mysteriös zu sein. Transit ist teuer, wenn Sie keine großartigen Peering-Vereinbarungen aushandeln können und Ihre Benutzer weit von Ihren POPs entfernt sind. Shared Hosting amortisiert diese Kosten über Tausende von Konten, von denen die meisten kaum etwas nutzen. "Unbegrenzt" ist ein Werkzeug zur Kundenakquise. Es reduziert die Reibung und vergleicht sich gut auf einer Tabelle, in der der günstigere Plan "mehr enthält". Der Host geht davon aus, dass Sie klein sind oder dass Sie das Vernünftige tun und Ihren schweren Traffic sofort auf ein CDN und Objektspeicher verschieben, sobald Sie wachsen, was den Egress zu einem Anbieter verschiebt, der nichts anderes als Egress macht.
Clouds kehren das Modell um. Sie messen den Egress, weil es ihr Profitzentrum ist und weil ihre Netzwerke teuer sind, um im globalen Maßstab betrieben zu werden. Sie versprechen nicht "unbegrenzt", weil der Anreiz anders ist; sie möchten, dass Sie durchdacht gestalten und für das bezahlen, was Sie nutzen. Shared Hosts möchten, dass Sie Ihre kleine Website mitbringen und glücklich bleiben, bis Sie nicht mehr klein sind, und dann möchten sie, dass Sie entweder optimieren oder upgraden. Nichts davon ist zynisch; so werden die Rechnungen bezahlt. Aber es erklärt, warum die AGB in samtener Sprache verfasst sind und warum die technischen Grenzen leicht durchgesetzt werden, bis sie es nicht mehr sind.
Entscheidungspunkte: wann „unbegrenzt“ in Ordnung ist, wann es leichtsinnig ist und wie man migriert
Ich werfe „unbegrenzt“ nicht einfach so in den Raum. Für eine kleine Marketing-Website mit überwiegend statischen Seiten und einem bescheidenen Blog ist es völlig in Ordnung, wenn Sie ein CDN davor schalten. Für einen Shop mit geringem Traffic und sinnvollem Caching kann es funktionieren, während Sie das Product-Market-Fit finden. Für eine Publikation, die unvorhersehbare Spitzen aufweist, ist es riskant, es sei denn, Sie cachen aggressiv und prärendern. Für alles, was große Dateien ausgibt, ist es das falsche Werkzeug ab dem Tag der Einführung.
Mein Entscheidungsbaum ist grob. Wenn Ihre p95-Dynamik-Antwortzeit niedrig ist und unter leichtem Stress niedrig bleibt, können Sie einen Shared-Plan länger nutzen, als Sie denken. Wenn Ihre CDN-Trefferquote wirklich hoch ist und Ihr Ursprungs-Egress flach bleibt, wenn sich der Traffic verdoppelt, sind Sie ausreichend sicher. Wenn eine dieser Bedingungen fehlschlägt, planen Sie den Umzug jetzt. Ein kleiner VPS mit zwei vCPUs und genügend Speicher, um Swapping zu vermeiden, ist langweilig und zuverlässig. Er bietet Ihnen vorhersehbare Parallelität, bessere Speicherleistung und eine Netzwerkspur, die Sie tatsächlich verstehen können. Sie können weiterhin dieselbe CDN- und Objektspeicherstrategie verwenden. Wenn Sie darüber hinauswachsen, werden Sie es auf eine Weise spüren, die Sie instrumentieren und planen können, und Sie werden in dedizierte oder verwaltete Cluster übergehen, weil Sie sich dafür entscheiden, nicht weil eine ToS-Klausel Ihre Hand erzwungen hat.
Der Migrationspfad muss nicht dramatisch sein. Halten Sie Ihren Ursprung soweit möglich zustandslos, damit DNS-Umstellungen reibungslos ablaufen. Speichern Sie Sitzungen in einem gemeinsamen Backend, auf das Sie sowohl vom alten als auch vom neuen Ursprung während einer kurzen Überlappung verweisen können. Wärmen Sie Caches auf, bevor Sie den Schalter umlegen, damit der neue Ursprung nicht den gesamten Ansturm abbekommt. Der Punkt ist nicht, perfekt zu sein; es ist, vorhersehbar zu sein. „Unbegrenzt“ lässt Sie unvorhersehbar im Stich. Ihr Ziel ist es, nicht mehr überrascht zu werden.
Ich habe praktische, erlebte Szenarien versprochen, weil dadurch die Ränder dieses Themas offensichtlich werden. Der nächste Abschnitt ist ein Premium-Abschnitt mit drei realen Geschichten, jede beginnt mit „unbegrenzt“, jede trifft auf eine andere Wand und die genauen Änderungen, die sie stabilisierten.
Premium content
Melde dich an, um fortzufahren
Meine Haltung, unverblümt: Es ist ungemessen, nicht unbegrenzt — behandelt es so
Ich habe nichts gegen „unbegrenzte Bandbreite“, solange wir uns einig sind, dass es bedeutet „wir zählen keine Bytes“ und nicht mehr. Es ist ungemessen, nicht unendlich. Die Steuerungen, die Ihre Erfahrung prägen, liegen in CPU-Anteilen, I/O-Grenzen, Prozessbeschränkungen, Gleichzeitigkeitsschwellen und der Formung von temporären Ports, wenn Sie beschäftigt werden. Wenn Sie wie ein Erwachsener architektonisch vorgehen—CDN vorne, Assets ausgelagert, dynamische Arbeit minimiert und schnell—können Sie auf einem Plan, der „unbegrenzt“ vermarktet, glücklich leben, weil Sie es selten auf die Probe stellen müssen. Wenn Sie so architektonisch vorgehen, als ob Sie eine eigene Spur gekauft hätten, werden Sie die Bedeutung von „fair use“ beim ersten Mal lernen, wenn jemand sich um Ihre Seite kümmert.
So gehe ich vor. Ich behandle den Ursprung wie eine kleine API, die Respekt verdient. Ich verschiebe schwere Bytes an Orte, die für den Datenabgang gebaut sind, und ich bezahle für diesen Abgang, weil es die Kosten des Wachstums sind. Ich achte auf p95, nicht auf Durchschnittswerte. Ich habe ein Auge auf Gleichzeitigkeit und ein anderes auf das lange Ende der Anforderungszeiten. Ich lese die ToS, als wäre es ein technisches Dokument, und übersetze jeden Euphemismus in eine Zahl. Ich akzeptiere, dass Shared Hosting eine überbuchte Umgebung ist mit einem brillanten Wertversprechen für kleine Seiten und einem Satz harter Grenzen für alles Ehrgeizige. Wenn der Ehrgeiz kommt, bewege ich mich, weil ich es wähle, nicht weil eine samtige Klausel mir sagt, dass ich muss.
Wenn Sie von „unbegrenzt“ verbrannt wurden, machen Sie sich keine Vorwürfe. Die Formulierung soll beruhigend wirken und das tut sie auch. Bauen Sie den kleinen, widerstandsfähigen Ursprung. Setzen Sie ein CDN davor. Lagern Sie die schweren Sachen aus. Kennen Sie Ihre Zahlen und Engpässe. Wenn der Tag kommt, an dem Sie einen VPS oder etwas Größeres benötigen, machen Sie den Schritt mit einem warmen Cache und einem kühlen Kopf. Sie werden „unbegrenzte Bandbreite“ nie wieder auf die gleiche Weise betrachten, und das ist der Punkt. Es war kein Versprechen. Es war eine Einladung, die richtige Arbeit zu leisten.
