OFFSHORE-VPS / BUILD
Build.
Eine funktionierende App und ihr nächstes Release.
Eine Anwendung mit Hintergrundjobs oder einer kleinen Datenbank. Lassen Sie Speicher für das Betriebssystem und den Bereitstellungsprozess.
Beginnen Sie mit diesen Ressourcen.
- Compute
- 2 vCPU
- Speicher
- 2 GB
- Speicher
- 50 GB
- Transferbudget
- 2 TB
Passen Sie Ressourcen, Image, Netzwerkoptionen und den Servicedienst in der Konfiguration an. Wählen Sie Malaysia, Rumänien oder die Schweiz als Serverstandort, ohne Standortaufschlag. Backup-Länder bleiben unbestätigt.
Planen Sie um die gesamte Arbeitslast herum.
Der Arbeitsspeicher wird von jedem Prozess auf der Instanz gemeinsam genutzt. Beziehen Sie Datenbank-Caches, Jobwarteschlangen und Ihren Bereitstellungsprozess ein und testen Sie zu einer erwarteten Spitzenzeit.
Ein Ressourcenbudget erstellen →Wissen, was Sie besitzen.
Planen Sie Anwendungssicherheit, Updates, Observability und einen unabhängigen Wiederherstellungsprozess. Wenn Sie eine Backup-Option wählen, überprüfen Sie das Wiederherstellungsverfahren und testen Sie es mit Ihrer Anwendung.
Erste Wiederherstellungsübung vorbereiten →Mehr Platz für eine App, Datenbank und Hintergrundaufgabe.
Build ist ein nützlicher Vergleichspunkt für eine API, die auch eine Datenbank oder eine kleine Hintergrundaufgabe ausführt. Betrachten Sie jeden Prozess als Teil desselben Budgets. Eine Webanforderung kann mit einem Berichtsexport konkurrieren, während das nächste Release kurzzeitig eigenen Speicher und Speicherplatz benötigt.
Ein ausgearbeiteter Ausgangspunkt
Eine illustrative Leselisten-API nimmt Einträge an und erstellt einen nächtlichen Export. Beobachten Sie die API während der normalen Nutzung, dann während des Exports und eines Releases. Notieren Sie, ob die Verzögerung von CPU-Arbeit, einer Abfrage oder dem Speicher kommt. Fügen Sie eine spezifische Option nur hinzu, wenn sie die gemessene Einschränkung adressiert.
Wenn dieser Ausgangspunkt schlecht passt
Mehr RAM macht zwei überlappende Jobs nicht sicher, und ein weiterer vCPU kann eine Anfrage, die auf eine externe API wartet, nicht auflösen. Begrenzen Sie die gleichzeitige Arbeit, bevor Sie Ressourcen erhöhen. Erwägen Sie die Trennung von Komponenten, wenn sie unterschiedliche Zugriffs-, Wartungs- oder Wiederherstellungsgrenzen benötigen.
Geben Sie jeder Option eine Aufgabe.
Die Basiskonfiguration enthält 2 vCPU, 2 GB RAM, 50 GB Speicher, ein 2 TB Transferbudget und 1 IPv4-Adresse. IPv6 wird separat angefordert und standardmäßig ist keine Backup-Option ausgewählt. Dies sind Katalogzuweisungen; bestätigen Sie die tatsächliche Hardware, Abrechnung und Wiederherstellungsregeln des Anbieters.
- Speicher: lassen Sie Platz für das Betriebssystem, die Laufzeit, die Datenbank und beobachtete Spitzen. Das Hinzufügen von 1 GB zu Build ergibt einen monatlichen Zwischensumme von $15.50 vor Laufzeitrabatten.
- CPU: vergleichen Sie die Prozesse, die Arbeit leisten, und ihre Parallelität. Es beschreibt kein garantiertes Prozessormodell oder Anfragen pro Sekunde.
- Speicher und Transfer: budgetieren Sie gespeicherte Daten getrennt von den Bytes, die Sie übertragen. Off-Server-Exporte können beides nutzen.
- Backups und Netzwerk: definieren Sie die Daten, die Sie zurückbenötigen, und die Adressen, die Ihre Anwendung verwendet. Die Auswahl einer Option dokumentiert nicht das Betriebsverfahren für Sie.
Machen Sie die erste Überprüfung konkret.
Erfassen Sie einen normalen Betriebszeitraum, eine schwerere Aufgabe und ein Release. Notieren Sie den verfügbaren Speicher, die am stärksten wachsenden Verzeichnisse und das Ergebnis einer lokalen Anwendungsprüfung. Führen Sie ein kleines Änderungsprotokoll, damit ein unerwartetes Ergebnis einen Ausgangspunkt hat. Vergleichen Sie dann die gesamte Vorabsumme des ausgewählten Zeitraums im Konfigurator; eine längere Laufzeit ändert den Preis, nicht die Ressourcen.
Erstes API-Budget durcharbeiten → · Erstellen Sie ein Ressourcen-Arbeitsblatt · Katalogfakten und Servicegrenzen prüfen