nicht angemeldet
die ganze site basiert auf asp / sql-server 7
Iiih. ;-)
die literatur schweigt sich leider über details zu "aus gründen
der performance" aus.
Bei Verwendung von Session-Variablen bzw. Erzeugung von Content,
der nur für einen User bestimmt ist, besteht in erster Linie das
Problem, daß man die Seiten nicht mehr cachen kann. Ob es bei .asp
noch weitere Probleme gibt, weiß ich nicht. Bei einer vernünftigen
Anzahl gleichzeitiger Nutzer (bestehender Sessions) ist das aber z.B. bei JSP/Servlets kein Problem. Bei sehr vielen gleichzeitig bestehenden Sessions könnte es sein, daß die Speicherung der Session-Informationen im Server zuviele Ressourcen benötigt.
wenn man cookies vermeiden kann, um infos zwischen seiten weiterzugeben, dann wäre das natürlich gut (alte "cookie/user-problematik"). und nur durch den einsatz von cookies lässt sich ja auch kein vernünftiger schutz gewährleisten. man kann zwar abfragen, ob eine id berechtigt ist - aber letztlich kann das cookie ja vom anwender geändert werden..
I.d.R. verwendet man entweder ID+Paßwort im Cookie, oder einen
temporären Key, der für eine Session erzeugt wird und halbwegs fälschungssicher ist (z.B. ein langer Zufalls-String).
oder verwendet man doch session-variablen?
Ist eigentlich dasselbe - Sessions werden auch meistens über einen Session-Key in einem Cookie identifiziert, ID und Paßwort werden dann im User-Context im Server für diese Session gespeichert. JSP/Servlets erlauben auch Sessions ohne Cookies, mit speziellen URLs (die Session-Identifikation ist in die URL codiert), was aber IMHO noch unsicherer ist.
- was ist eine sinnvolle vorgehensweise für diese problematik?
Eigene cookies, Sessions oder auch normale HTTP-Authentication (geschütztes Unterverzeichnis am Webserver). Falls möglich, gleich per SSL.
- worauf muss man achten, um eine vernünftige performance zu erhalten.
Die richtige Software verwenden und nur die Seiten schützen bzw. personalisieren, bei denen das auch nötig ist.
- und wie ist die hardware-ausstattung in relation zur anzahl online-user zu setzen
(so 32MB am server werden ja wohl doch für 10.000 user ausreichen, oder *grins*)
Das hängt zu stark von der Software und der Implementierung ab, um das pauschal beantworten zu können. Am ehesten kannst du das noch anhand anderer Websites abschätzen - so hat uboot.com z.B. bei derzeit etwa 135.000 registrierten Usern ein ca. 3m breites Rack mit mehreren Linux-Kisten, davon mind. eine mit SMP.
gibt es sowas wie ein richtlinie (xxx prozessor mit yyy ram reicht sauber programmiert für zzz sessions - oder sowas in der art)?
Eher nicht. Meistens kann man aber durch effiziente Programmierung noch einiges aus der Hardware herausholen - d.h. wenn es eng wird, kaufst du entweder teure neue Hardware, oder du setzt dich 1 Woche hin und optimierst alles für Faktor 10 ;-).
wo liegen performance-killer? besonders was den chat betrifft - der soll ebenfalls asp-basierend sein.
Das merkst du schon noch beim Testen...
freue mich schon auf antworten und rege diskussion
Was wird es denn?
MfG,
-mjy