Was ist der typische Engpass bei der Entwicklung einer CRUD-Webanwendung?

Question

Aktualisierung: Eine präzisere Formulierung könnte sein: "Was ist der typische Leistungs-Engpass bei der Entwicklung einer CRUD-Webanwendung?

Ich denke an Webanwendungen wie:

• Weblog CMS
• Vokabeltrainer
• URL-Verkürzer
• Internetforum

Ich denke an Programmiersprachen wie:

• Ruby
• Scala
• Clojure

Ich denke an Datenbanksysteme wie:

• PostgreSQL
• MongoDB
• CouchDB

Ich denke an Betriebssysteme wie:

• Mac OS X
• Linux

Ich denke an typische Hardwarekonfigurationen von der Stange:

http://english.keyweb.de/dedicated/index.shtml

Mögliche Softwareengpässe, die mir in den Sinn kommen, sind:

• Programmiersprache
• Datenbanksystem
• Betriebssystem

Mögliche Hardwareengpässe, die mir in den Sinn kommen, sind:

• CPU
• RAM
• Festplatte
• Netzwerk

Answer 1

Wenn Sie Webanwendungen für maximale Skalierbarkeit gestalten, dann wird Ihr Engpass letztendlich auf die Verwaltung koordinierter veränderlicher Zustände (d.h. die Teile Ihrer Datenbank, die eine Form von transaktionaler Semantik erfordern) zurückzuführen sein

Einige Punkte zum Nachdenken:

• Statische oder nicht synchronisierte/daten transaktionsdaten können günstig auf vielen kleinen handelsüblichen Servern repliziert werden. Ihre NoSQL-Lösungen (CouchDB usw.) sollten dies gut handhaben, kombiniert mit einer der vielen großartigen Cache-Lösungen für statische Webdaten.

• Lokale CPU-Verarbeitungskapazität (z.B. Verarbeitung einzelner Webanfragen) lässt sich einfach horizontal skalieren, indem Sie mehr Webserver-Knoten hinzufügen. Die CPU-Geschwindigkeit wird wahrscheinlich ohnehin nicht Ihr Engpass sein, angesichts der modernen Prozessorgeschwindigkeiten - die meisten Webanwendungen benötigen nicht wirklich viel CPU-Leistung.

• Die transaktionale Aktualisierung von Daten ist jedoch ein sehr komplexes Problem. Lesen Sie über das Problem der byzantinischen Generäle, wenn Sie die theoretische Erklärung wissen möchten, aber im Grunde genommen ist es unmöglich, Transaktionen in einem verteilten System zuverlässig zu koordinieren. Sie müssen einige Kompromisse eingehen, basierend darauf, was Ihnen am wichtigsten ist (Datenintegrität? Leistung? Skalierbarkeit? Ausfallsicherheit? Kosten? Latenz?).

• Betriebssysteme usw. machen nicht wirklich einen großen Unterschied - der Overhead ist so gering und es beeinträchtigt nicht wirklich die Skalierbarkeitsüberlegungen. Verwenden Sie, worin Sie Fähigkeiten haben und/oder was Sie am einfachsten zu verwalten finden. Persönlich verwende ich Ubuntu auf Amazon EC2.

Angesichts der Art von Anwendungen, mit denen Sie es zu tun haben, würde ich wahrscheinlich mehr zu den NoSQL-Lösungen tendieren, da es wichtiger zu sein scheint, große Volumina effizient zu verarbeiten als viele transaktionsbezogene Daten zu haben. Sie können immer eine PostgreSQL-Box für die begrenzte Teilmenge von Daten behalten, die eine transaktionale Semantik erfordern (Benutzerkonten? Master-Referenzdaten? bestimmte Workflow-Zustände?)

Der andere (klassischere) Ansatz wäre, eine typische große Datenbank (z.B. Oracle, DB2) zu verwenden und einen teuren Cluster von High-End-Datenbank-Maschinen zu kaufen. Haben Sie dann viele günstige, replizierte Webserver, die den größten Teil der Arbeit erledigen und bei Bedarf auf den Datenbank-Cluster zugreifen, wenn sie Transaktionen ausführen müssen. Dies kann bis zu dem Punkt extrem gut funktionieren, an dem der Datenbank-Cluster überlastet wird, was dann zu einem teuren Engpass werden kann… aber wenn Sie so viel Last bekommen, können Sie es sich wahrscheinlich leisten. Ich würde diesen Weg gehen, wenn Sie z.B. eine Finanzdienstleistungs-App erstellen.

Wenn Sie nur einen Prototyp erstellen oder anfangs mit kleineren Lasten rechnen, können Sie anstelle eines teuren Datenbank-Clusters eine einzelne handelsübliche PostgreSQL-Maschine verwenden. Dies ist wahrscheinlich die einfachste / günstigste Option zur Einrichtung. Und wenn Sie den Datenbankzugriff auf ein Minimum beschränken (viel Caching, sorgfältiges Abfragedesign), kann dies tatsächlich ziemlich weit führen. Seien Sie sich einfach bewusst, dass es letztendlich Ihr Engpass wird, wenn Sie weiter wachsen.

p.s. Sie haben erwähnt, dass Sie sich Clojure ansehen, falls Sie dies noch nicht getan haben, empfehle ich dringend, dieses Video anzusehen: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey - eine sehr einzigartige Perspektive auf Nebenläufigkeit, die auch einige Einblicke in die Probleme der Verwaltung transaktionaler Daten in Nebenläufigen Umgebungen gibt.

Answer 2

Es kommt darauf an (tm). Zählen Sie sich glücklich, wenn Ihre App genug Traffic hat, um sich darum zu kümmern.

Answer 3

Persönlich, der Umfangszuwachs. Halten Sie es einfach und versenden Sie es solide mit weniger Funktionen.

Keines der aufgeführten 'möglichen Engpässe' sind Probleme für eine einfache App. Wenn Sie einen komplexen Funktionsumfang entwickeln, stoßen Sie wahrscheinlich auf Prozessor-/Speicherbeschränkungen, abhängig vom Server, den Sie gewählt haben. Der beste Weg, dies herauszufinden, besteht darin, Ihre App zu erstellen und zu sehen, was passiert. Wenn eine bestimmte Kombination von Hardware nicht ausreicht für Ihre App, seien Sie dankbar, dass es eine Million Optionen zum Wechseln gibt.

Für Details, wenn Sie eine Rails-App entwickeln, starten Sie mit Heroku und wechseln Sie zu einer EC2-Instanz, sobald es zu teuer wird. Sie werden keine Serverprobleme haben und mehr Zeit haben, sich auf wichtige Dinge zu konzentrieren, wie die Optimierung Ihrer App.

Answer 4

In den meisten typischen Fällen ist es höchst unwahrscheinlich, dass Sie einen Engpass haben werden, der nicht die Produktivität der Entwickler betrifft, es sei denn, Sie machen etwas komplett falsch.

Wenn Sie andere Engpässe haben, werden Sie wahrscheinlich genug Benutzer und Mittel haben, um sie zu beseitigen.