Laden...

Webanwendungen - mit mehreren Servern (?)

Erstellt von reloop vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.085 Views
reloop Themenstarter:in
139 Beiträge seit 2010
vor 11 Jahren
Webanwendungen - mit mehreren Servern (?)

Hallo und ein frohes neues Jahr, liebe Community.

Und zwar habe ich folgende Frage:

Ich plane Mitte 2013 eine Webanwendung zu veröffentlichen. Diese ist öffentlich für jedermann zugänglich. Nun zu meinem Problem:

Angenommen die Seite läuft und findet Beispielsweise einen Zuwachs von 2000 Usern. Jeder dieser Benutzer hat die Möglichkeit, in seinem Account Dateien zu verwalten.

Welches ist die sinnvollste Lösung, die Dateien zu verwalten? Da der Server ja sicherlich auch mal an seine Grenzen stößt. Ich hoffe ihr versteht mein Problem. Ich habe schon überlegt, mehrere Server einzuplanen, wo die Dateien hochgeladen werden.

Dann wäre ja der Korrekte weg, dass ich in einer Tabelle mir mitführe, auf welchem Server die Datei letztendlich gelandet ist, oder?

Entschuldigt für die vll. verwirrende Fragestellung.

Ich hoffe, ihr konntet mir einigermaßen folgende.

Beste Grüße und danke für die Hilfe,
reloop

16.806 Beiträge seit 2008
vor 11 Jahren

Sinnvoll für Webanwendungen

  • Web-Server und Content-Server (sogenannte CDN-Server) trennen
  • Session-Sharing (meistens über ne Datenbank)
  • SQL-Server abschaffen und auf dafür optimierte Datenbanken wechseln -> MongoDB

Ansonsten musst nicht viel beachten.
Ansonsten ja: speichern, auf welchem CDN die Datei liegt und dann kannst ja den Rest des PFads zusammen bauen.

2000 User ist jetzt aber nicht unbedingt viel, was die Last der Webanwendung betrifft (wenn Du auf die Performance bei der Entwicklung geachtet hast).

reloop Themenstarter:in
139 Beiträge seit 2010
vor 11 Jahren

Danke Abt, die Tipps haben mir bisher unglaublich weitergeholfen. Ich habe mich jetzt mit MongoDB auseinander gesetzt, als auch mit der Planung der Server. Werde es jetzt wie von dir vorgeschlagen trennen, die Webanwendung auf dem einen und den Content auf einem separaten Server.

Noch eine frage bzgl. MongoDB: Weshalb genau ist es deines Erachtens nach geeignet? Weil es möglich ist in einem Datensatz quasi eine Collection bzw ein Array zu speichern? Und man somit an Perfomance gewinnt, da auf überflüssige Joins verzichtet werden kann?

Desweiteren wollte ich dich noch fragen, was genau es mit Session-Sharing auf sich hat. Geht es hier um Serverübergreifende Sessiosn? Für welches Szenario sollte das angewandt werden, wenn die Anwendung als solche sich nur auf einem Server befindet?

Und meine letzte Frage: Verwalte ich den Rest meiner Anwendung dann auch über MongoDB oder lohnt sich ein paralleler Einsatz von MySQL und Mongo?

Vielen, vielen Dank für deine Hilfe.

Beste Grüße

16.806 Beiträge seit 2008
vor 11 Jahren

(Solangsam fühl ich mich als Werbe-Pate für MongoDB 😃)

MongoDB ist quasi komplett für die Web-Geschichten optimiert bzw. aufgrund der Nachteile der anderen dafür erst entwickelt worden, was zum Beispiel ein SQL Server nicht ist. MongoDB gehört zur Kategorie NoSQL (Not Only SQL) und speichert seine Daten nicht in Tabellen, sondern in Dokumente - KeyValue-Prinzip.
Dieses Prinzip ist so das ziemlich performanteste, was man überhaupt an Datenhaltung erreichen kann.
MongoDB ist in optimaler Haltung 1000-fach schneller als MSSQL. Selbst mit einfachsten Objekten.

MongoDB hat nicht nur den Vorteil, dass es aufgrund seiner Art so unheimlich performant ist (Achtung: natürlich müssen auch hier gewisse Regeln eingehalten werden!), sonder es wurde vor allem mit dem Fokus, dass es für Web-Anwendungen gedacht ist, entwickelt.
Also der Fokus, dass es eben verteilte Anwendungen sind und diese jederzeit erweitert werden können - im Handumdrehen ist das möglich, OHNE, dass Daten angepasst werden müssen (Auto Sharding).

Must See: 5 Steps To Scaling MongoDB (Or Any DB) In 8 Minutes
Scaling with MongoDB
MongoDB Manual: Sharding
MongoDB Manual: Replication

Sofern Deine Datenbank-Performance nicht mehr ausreicht: schau nach, ob Du wirklich alles beachtet hast!*Verwende kein LINQ, auch wenn es nett ist, sondern IMongoQuery *Verwende wenn möglich Konstanten zur Abfrage der Felder - > bedenke aber die Nachteile von Magic Strings (Avoid Magic Strings) *Verwende erst MongoDB Funktionen, DANN C# Funktionen (SetSortOrder statt OrderBy) *Verwende SetFields um nur die Felder zu laden, die Du auch wirklich brauchst! *Verwende nicht den Serializer des MongoDB Drivers, sondern serialisiere selbst (wenn möglich zusammen mit TPL und auch nur die Felder, die Du brauchst (Projektionen))!

  • Beachte: Collections werden gelockt. Das heißt: je mehr in einer Collection gespeichert wird, desto geringer ist der zeitgleiche Zugriff. Gewollte und gut überlegte Fragmentierungen bieten sich also an!
    Beispiel: Entity User mit Collection Adressen.
    Adressen könnte nun eine Property sein, oder eine eigene Collection mit einem FK auf den User.

Allgemein noch für MVC Performance:*Verwende Caching! *Dynamic + Static Compression (IIS) *Benutze Bundles (MVC 4) oder wenigstens Chirpy (MVC1-3) *Route Caching ASP.NET MVC Route Caching! *Vermeide die Session, wenn Du sie nicht brauchst *Verwende in Views oft PartialView, damit nicht alles doppelt gerendert werden muss und verwende so wenig C# Code in Views wie möglich (unperformant).
Lass Dir bestimmte Inhalt lieber direkt in der Action bauen statt in der View (zB Schleifen, um Tabellen zu generieren)

*Gib dem Application Pool einen eigenen User und vermeide Impersonation innerhalb der Anwendung

Wenn Du das alles befolgt hast, und es dann nicht ausreicht: Replica Sets
MongoDB hat einen Nachteil: ist das ACID-Prinzip erforderlich eignet es sich nicht. Ansonsten sehe ich keinen Grund, dass parallel noch MySQL laufen muss.

--
Zum Thema Session: man kann die Session-Gegenstücke lokal speichern (dann sind sie auch nur für den lokalen Server verfügbar, oder man Speichert seine Session in der Datenbank. Stichwort wäre der "ASP.NET Session State" oder Du schreibst Dir was eigenes (was sich im Sinne der MongoDB anbieten würde, evtl. gibts auch was bei NuGet).