mediengestalter.info
FAQ :: Mitgliederliste :: MGi Team

Willkommen auf dem Portal für Mediengestalter

Aktuelles Datum und Uhrzeit: Fr 29.03.2024 12:25 Benutzername: Passwort: Auto-Login

Thema: Internet Application Server - CFMX feat. ASP, .NET und PHP vom 11.09.2004


Neues Thema eröffnen   Neue Antwort erstellen MGi Foren-Übersicht -> Web-Hosting und Internetzugang -> Internet Application Server - CFMX feat. ASP, .NET und PHP
Seite: Zurück  1, 2, 3
Autor Nachricht
kapetanov

Dabei seit: 17.08.2003
Ort: -
Alter: -
Geschlecht: -
Verfasst Mo 13.09.2004 10:01
Titel

Antworten mit Zitat Zum Seitenanfang

Zitat:

1. Keine Registrierung erforderlich. Es ist keine Registrierung erforderlich, um eine Assembly für Seiten in einer Anwendung verfügbar zu machen. Sie ist aufgrund ihrer Position im Verzeichnis /bin verfügbar. Kompilierter Code kann durch Kopieren oder durch FTP-Transfer an diese Position weitergegeben werden.
2. Es ist kein Serverneustart erforderlich. Wenn Teile einer ASP.NET Framework-Anwendung geändert werden, beispielsweise beim Ersetzen einer DLL in /bin, werden neue Anforderungen sofort mit den geänderten Dateien ausgeführt.Gegenwärtig ausgeführte Anforderungen werden beendet, bevor die bisherige Anwendung deaktiviert wird. Der Webserver muss nicht neu gestartet werden, wenn Sie die Anwendung ändern, selbst wenn Sie kompilierten Code ersetzen.
3. Keine Namespacekonflikte. Eine Assembly, die aus /bin geladen wird, ist auf den Gültigkeitsbereich der Anwendung beschränkt, die gerade ausgeführt wird. Dies bedeutet, dass mehrere Anwendungen verschiedene Assemblies mit den gleichen Klassen- oder Namespacenamen verwenden können, ohne dass Konflikte entstehen.
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
Waschbequen
Account gelöscht Threadersteller


Ort: -

Verfasst Mo 13.09.2004 10:04
Titel

Antworten mit Zitat Zum Seitenanfang

Gut, und jetzt lies nochmal das was ich geschrieben habe. * Ich bin ja schon still... * * Applaus, Applaus *
 
Anzeige
Anzeige
kapetanov

Dabei seit: 17.08.2003
Ort: -
Alter: -
Geschlecht: -
Verfasst Mo 13.09.2004 11:14
Titel

Antworten mit Zitat Zum Seitenanfang

Zitat:
...Das heißt auch, dass durch eben diese Kompilierung der Source in DLL's eben keine direkten Änderungen an der Business-Logik während der Laufzeit möglich sind


das hast du doch geschrieben, oder?

Zitat:
...und anschließend nach der Kompilierung nur noch die entsprechenden DLL's hochspielen. Der Nachteil: macht man sowas eben während des Betriebes, so wird die komplette Applikation neu gestartet - was dann zum Beispiel auch bedeuten würde, dass sämtliche User aus dem System fliegen würden, weil auch deren Sessions etc. verloren gehen.


und das hast du auch geschrieben, oder?

es gibt da ein /bin verzeichnis, dort kannste deine dll's während der laufzeit austauschen. und mußt die dll's nicht registrieren, den server neu starten und die daten gehen auch nicht flöten.....
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
Waschbequen
Account gelöscht Threadersteller


Ort: -

Verfasst Mo 13.09.2004 11:46
Titel

Antworten mit Zitat Zum Seitenanfang

Oh je... ich denke du arbeitest seit einem Jahr damit? Haste schonmal während des laufenden Betriebs ne DLL ausgetauscht?

Natürlich musst du den Server nicht neu starten - aber die Applikation wird beim nächsten Aufruf neu erstellt. D.h. z.B. das sämtliche Sessions flöten gehen. Das Problem hast du bei interpreterbasierten Technologien nunmal nicht.
 
kapetanov

Dabei seit: 17.08.2003
Ort: -
Alter: -
Geschlecht: -
Verfasst Mo 13.09.2004 12:34
Titel

Antworten mit Zitat Zum Seitenanfang

es gibt vier methoden wie du ne session bei asp.net speichern kannst. üblicherweise wird die session im arbeitsspeicher des webserver (mode="inproc") gespeichert und ist dort über eine gewisse zeit verfügbar (mit oder ohne dll - natürlich spreche ich hier von cookieless session). der nachteil ist hier natürlich das nach ablauf des timeout die session flöten geht. wie der timeout geändert wird wirste ja sicher wissen. den die standard 2 min. sind einfach zu kurz....

methode 2 (mode="sqlserver") ist da schon besser. du speicherst die daten auf nem sql server. und damit bleibt das ganze natürlich auch ohne timeout erhalten. bei unternehmenskritischen anwendungen ist das wohl die richtige methode.
auch hier spielt der austausch der dll keine rolle.

bei methode 3 (mode="stateserver") kannste die session in den arbeitsspeicher eines eigenen/zweiten server ablegen. dadurch die klannste die last des eigentlichen webservers gering halten (bei größeren webseiten sinnvoll). auch hier macht der austausch der dll eigentlich keine probleme.

methode 4 ist einfach nur dazu da um das ganze sessionmanagement zu deaktivieren (mode="off"). der austausch der dll ist auch in dieser methode kein problem.

ich habe das auch schon öfters auf stark frequentierten webseiten während der laufzeit gemacht und habe nie probleme damit gehabt. sicher brauchst du immer dein entwicklungssystem um die dll's zu erstellen. die dll's selbst machen aber bei den session's keinen ärger wenn du sie während der laufzeit auswechselst. kann natürlich sein das es probleme wegen dem session.timeout gibt. wenn du allerdings unternehmenskritische daten hast. bzw. daten die für den geschäftsprozess wichtig sind würde ich sowieso mit methode 2 (mode="sqlserver") arbeiten.

bei welcher methode hattes du da ärger?
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
Waschbequen
Account gelöscht Threadersteller


Ort: -

Verfasst Mo 13.09.2004 12:53
Titel

Antworten mit Zitat Zum Seitenanfang

kapetanov hat geschrieben:
es gibt vier methoden wie du ne session bei asp.net speichern kannst. üblicherweise wird die session im arbeitsspeicher des webserver (mode="inproc") gespeichert und ist dort über eine gewisse zeit verfügbar (mit oder ohne dll - natürlich spreche ich hier von cookieless session). der nachteil ist hier natürlich das nach ablauf des timeout die session flöten geht. wie der timeout geändert wird wirste ja sicher wissen. den die standard 2 min. sind einfach zu kurz....

Standard sind sowohl am IIS als auch in neuen Studio-Projekten 20 Minuten, nicht 2 - und das ist absolut ausreichend.

kapetanov hat geschrieben:
methode 2 (mode="sqlserver") ist da schon besser. du speicherst die daten auf nem sql server. und damit bleibt das ganze natürlich auch ohne timeout erhalten. bei unternehmenskritischen anwendungen ist das wohl die richtige methode.

Das ist nie die richtige Methode, da der größte Performance-Killer überhaupt. Langsamer geht's nicht mehr.

Zum Thema: immer, wenn du die DLL in /bin austauscht, wird die Applikation beim nächsten Aufruf komplett neu gestartet - d.h. die CLR wird angeschmissen und der "echte" ByteCode wird erneut erzeugt. Bei der normalen Variante des Session-Handlings, sprich wenn die Sessions am lokalen Webserver gehalten werden, gehen hiermit auch sämtliche Sessions flöten - da die nette Garbage Collection alles ausm Speicher räumt.

Probier's aus: schreib dir ne Session mit ner Uhrzeit, ruf die Seite auf und merk dir die, kompiliere neu, rufe neu auf... und siehe da.

Und mal davon abgesehen hatte ich ne andere Intention: bei PHP-Scripten kannste locker per Remote oder FTP draufgehen und Dinge on the fly ändern, dass geht bei diesem Konzept nicht mehr.
 
 
Ähnliche Themen Virtual Server, Windows Server, Root Server hääää
[Hosting] Server & Virtueller Server
FTP-Server
Domain Name Server
Server anbieten - wie?
Root-Server.
Neues Thema eröffnen   Neue Antwort erstellen Seite: Zurück  1, 2, 3
MGi Foren-Übersicht -> Web-Hosting und Internetzugang


Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst an Umfragen in diesem Forum nicht mitmachen.