Subtile Gedanken zur Website-Architektur

Wir sind in unserem WIT-e natürlich Ambler. Eigenes ERP-System (hier darüber geschrieben - Wie können wir auf 1C verzichten? ), Eigenes CRM-System, eigenes M2M für die Kommunikation mit Distributoren ("Welche anderen klugen Wörter und Abkürzungen kennen Sie?"). Und natürlich Ihre Herangehensweise an das WWW, um im Rahmen dieses 3-Buchstaben-Paradigmas zu bleiben.

Alles begann mit einer Vorliebe für Microsoft, und einige der frühen Versionen der Website wurden Ende der 90er Jahre mithilfe der ASP-Technologie erstellt. Als Datenbank darunter lag eine reguläre MS Access-Datei. Übrigens bieten Anbieter auch 18 Jahre nach dem Upgrade auf ASP.NET noch Hosting auf dem guten alten ASP an - hier haben Sie Legacy-Systeme in ihrer ganzen Pracht.

Im Allgemeinen ist dies sehr praktisch - da die interne Datenbank auch in MS Access geschrieben ist, war das Verfahren zum Vorbereiten von Daten für die Site sehr einfach, keine erneuten Übersetzungen von einem Datenformat in ein anderes (z. B. MySQL). Access unterstützt eine Erweiterung der SQL-Sprache der Form "IN <Name der externen Datenbank>", die nach beliebigen DML-Anweisungen hinzugefügt werden kann: INSERT, UPDATE, DELETE (hier eine weitere Abkürzung mit drei Buchstaben).

Als dieser Link wuchs, wurde er natürlich schamlos langsamer (und diejenigen, die passieren, sind unklar, wenn die MDB-Datei mit der Datenbank gesperrt wird, wodurch die gesamte Site fest gesperrt wird). Die Übersetzung der Site in ASP.NET löste das Problem nicht grundlegend, und es war auch erforderlich, zu MS SQL Server als Basis zu wechseln, aber dann ging der Prozess in eine andere Richtung. Betrachten wir das Problem der Verbesserung der Website-Leistung aus einer etwas anderen Perspektive.

(Mein 1Gb.ru-Anbieter schreibt übrigens, dass ASP.NET im Durchschnitt schneller ist als das Standard-LAMP-Bundle (Linux / Apache / MySQL / PHP), was für mich zu einer Offenbarung geworden ist. Aber wem kann ich hier vertrauen, da es nicht der Betreiber des Ganzen ist? )

Haftungsausschluss - nachfolgende Ideen stellen einerseits eine theoretische Konstruktion dar, die zum Absoluten erhoben wird, was oft bedeutet, auf Absurdität reduziert zu werden, andererseits eine konkrete Umsetzung, so dass nicht gesagt werden kann, dass der Autor in seinen Fantasien und völlig losgelöst ist Wirklichkeit.

Frage 1. Warum sollte sich unter der Site eine Datenbank befinden?

Wirklich, Sie alle bewundern die Geschwindigkeit von In-Memory-Datenbanken, oder? Warum also weit gehen, machen Sie sich eine direkt unter Ihrer Website. Und noch mehr. Laden Sie bei der anfänglichen Initialisierung alle Daten in Arrays, die auf Site-Ebene als Ganzes verfügbar sind (Anwendungsobjekt in ASP.NET, globale Variablen in PHP, im Folgenden überall), und anstatt Abfragen in die Datenbank zu schreiben, durchlaufen Sie einfach diese Arrays. Alles ist für das anfängliche Laden von Daten geeignet - dieselbe MS Access-Datenbank, aber zumindest CSV-Textdateien! - Die Operation wird selten ausgeführt und ihre Ausführungszeit spielt keine Rolle.

Es gibt Fragen, aber wir haben bereits vorgefertigte Antworten darauf.

  1. , - , ? – ( , -), — ,
  2. ( ) . . – ( ) , ? , – / , – , . . Catalog ( -!) 2 – :



    MinIndex MaxIndex. , - ( ) – Parts ID Catalog, – .

Beachten Sie, dass diese Idee weiter fortgesetzt werden kann. Auf die gleiche Weise, wie Daten von der Datenbank unter der Site in die Datenstruktur der Site selbst übertragen werden, müssen beim Generieren einer Webseite die Daten in ihrer Struktur selbst platziert werden, dh in JavaScript-Arrays. Und es gibt keine AJAXs, Asynchronität, Behandlung von Kommunikationsfehlern und mehr. Und so wurde es auf unserer Website auf Seiten gemacht, die alle Arten von Konfiguratoren enthielten.

Im Gegensatz zu Datenbankdateien haben die Arrays im Speicher des Webservers (und auch des Webbrowsers, wenn auch mit Vorbehalten) eine Größe, die ungefähr ihrer binären Darstellung entspricht, während eine leere Datenbank mit einer einzelnen Tabelle bereits verwendet wird viele hundert Kilobyte.

Frage 2. Warum muss ich Skripte auf einem Webserver verwenden?

Ich bringe das Codefragment in mehreren Zeilen, absichtlich vereinfacht und in der verrücktesten Programmiersprache - VBA (außer 1C)

        Set IE = CreateObject("InternetExplorer.Application")

        IE.Navigate "wit.ru"
        While IE.ReadyState < READYSTATE_COMPLETE
        Wend

        Set str = IE.Document.DocumentElement
        HTML = str.innerhtml

Der Code führt Folgendes aus: Er führt die Seite über den einst sehr beliebten Browser eines bekannten Unternehmens aus und speichert das Ergebnis der Ausarbeitung des Serverskripts als reines HTML. Sie haben es wahrscheinlich erraten, was als nächstes angeboten wird? Ganz richtig - es ist durchaus möglich, eine Site in den alten 90ern als rein HTML-artig zu gestalten.

(Nochmals ab 1 GB.ru: „IIS verarbeitet Anforderungen für statische Dateien sehr schnell und effizient“)

Gleichzeitig müssen Sie sich möglicherweise Gedanken darüber machen, Adressen wie
wit.ru/card.aspx?id=23&prodid=1022985
in statische Webadressen umzuwandeln Webseiten sind auch eine bekannte Web-Server-Optimierungstechnologie, die ursprünglich erfunden wurde, um Suchmaschinen zu täuschen und die Weboptimierung durchzuführen.

Hier ist es wahrscheinlich notwendig, das Grundprinzip zu formulieren, von dem alle anderen abgeleitet sind. Je mehr Zeit und Ressourcen wir für die Vorbereitung von Daten für die Website aufwenden, desto einfacher wird es für ihn, sie anzuzeigen, und desto schneller kann er dies tun. In diesem Fall kann unser Back-End im kontinuierlichen Modus arbeiten und fertige Daten auf der Site mit der von uns benötigten Häufigkeit ausspucken. Und dieser Ansatz funktioniert in allen Fällen, außer natürlich beim Austausch von Zusammenfassungen oder Fenstern von Amazon oder Alibaba, bei denen sich die Daten jede Sekunde ändern.

Fazit


Mir ist bewusst, dass die Probleme in dem Artikel zu deutlich sind und eine nicht standardmäßige Lösung vorgeschlagen wird. Ich wage vorzuschlagen (dies ist überhaupt nicht mein Thema), dass ein solcher Ansatz für alle eingebetteten Systeme funktionieren könnte. Andernfalls müssen Sie auf einem schwachen Computergerät anstelle des einfachsten Webservers (auf Kosten von) eine Mini-Datenbank-Engine und einen Skript-Handler platzieren mehr Speicherverbrauch - betriebsbereit und konstant).

All Articles