> > Die angesprochenen Performanceverbesserungen sind mir > > wohlbekannt. Aber > > Welche Verbesserungen? Ich sprach von Verschlechterungen. >
Du hast einige Verbesserungsm�glichkeiten angesprochen wie zwischenspeichern von Werten in Applikation Variablen oder Textfiles. > Jeder Provider, der seinen Job ernst nimmt wird wenn M�glich > connection-Pooling einstellen, denn es bringt auch ihm Vorteile... > Weniger starke Auslastung der Server bedeutet, dass er mehr Sites pro > Server hosten kann... > F�r SQL Server stimme ich dir generell mal zu, aber vorsicht bei Access. Wenn du das Connection Pooling f�r Access aktivierst hast du ein Problem, das wir bislang noch garnicht angesprochen haben, es wird je nachdem extrem Schwierig die Connections zu Wartungszwecken zu trennen (zB. DB Komprimierung). �ber solche Anspr�che kann sich ein Provider doch nicht einfach hinwegsetzen. > �brigens gelten Deine Argumente auch gegen Dich... > Du nutzt ODBC, aber bei den meisten Providern kostet das > Einrichten von > ODBC DSNs Geld... Es wird doch eine DSN lose Connection Benutzt? > Ja, aber was ist den �berhaupt der Vorteil, den mann sich mit > Performance-Verlust durch Dein System erkauft? > Einfache Konfiguration, Downloads von meiner Seite laufen in einer gemeinsamen Umgebung was eine Interaktion erlaubt, ohne zu bedingen, das alles installiert ist. Einfacheres verst�ndniss der Vorg�nge im Quellcode, weil nicht alles mit Standartvorg�ngen zugekleistert ist. Cookiefreies Sessionhandling, hohe felxibilit�t bei einfacher installation. Ich f�rchte, du hast eine wichtigen Punkt missverstanden: Ich will hier keine Umgebung schaffen die nachher jeder nutzen soll, weil das dann meinem Ego gefallen w�rde. V�lliger Schmarrn. Aber Ich hab diesen Chat geschrieben und ich habe noch ein Glossar zum Download auf der Page. Beiden fehlt beispielsweise eine Benutzerverwaltung. Als n�chstes bastle ich an einem Forum, da der Chat sicher viele Fragen aufwerfen wird. Das werde ich dann nat�rlich auch im Quellcode ver�ffnetlichen. Auch hier ist wieder eine Verwaltung gefragt. Also war meine �berlegung, erst einmal eine Basis zu schaffen, die all diese Applikationen gemeinsam nutzen k�nnen und die so leicht wie m�glich konfigurierbar und nutzbar ist, auch f�r jene, die nicht wissen. Gru�, Andreas. PS: Wir haben hier 2 St�hle, eine Meinung. Wir stehen hier nicht Grunds�tzlich gegeneinander -------------------------------------- [EMAIL PROTECTED] *jetzt mit Chat* http://www.EuphoriasChild.DarkTech.org -------------------------------------- > -----Urspr�ngliche Nachricht----- > Von: Claudius Ceteras [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 4. Januar 2002 12:37 > An: ASP Datenbankprogrammierung > Betreff: [aspdedatabase] RE: AW: RE: AW: RE: AW: RE: AW: RE: Nur eine > Access C onnectio n? > > > > > > > Insgesamt wirst Du die Situation eher verschlechtern... > > > Bei wenigen Anfragen wird es zwar funktionieren, aber > > gerade der Fall > > > den Du verbessern willst, n�mlich bei hoher DB-Belastung wird sich > > > verschlechtern... > > > > > > > Insgesamt geht es mir nicht um Performancegewinn, sondern > > darum, dass man > > bei h�herer Belastung nicht in Probleme mit der Anzahl der > ge�ffneten > > Connections l�uft. Das ist der eigentliche Punkt den ich > > vermeiden will. > > Dann muss man eigentlich nur am Connection-String drehen und nicht ein > Pooling programmieren... > Wenn Du nicht mehr als eine gleichzeitige Connection > hinbekommst kannst > Du das pooling sowieso vergessen, wenn Du es aber hinbekommst ist das > Problem doch schon gel�st und muss nicht noch �ber ein pooling wieder > eingeschr�nkt werden.. > > > gr�stenteils ungeeignet f�r dass, wa sich im moment plane. > > Selbiges ist sozusagen eine Umgebung f�r die ASP-Software, > die ich auf > > meiner Homepage zum Download anbieten werde. Es regelt > > Datenbankzugriff, > > Sessionhandling und Benutzerverwaltung und wird �ber eine einfache > > Textedatei im root konfiguriert. Ziel ist es, dass das ganze > > direkt nach dem > > entpacken l�uft (Standartm�ssig werden Connections auf der Seite > > geschlossen), und dass man dann im Rahmen seiner M�glichkeiten dann > > anpassungen vornehmen kann. So erinnere ich mich an einen > > Provider, der > > unbedingt Datenbank Verbindungen in Sesionvariablen haben > > wollte. Auch das > > wird unterst�tzt, wenngleich ich das nicht empfehle. > > Schreibzugriff f�r den > > I_Usr ist auch selten vom Provider gegeben (wg. > > Textdateien).MS Connection > > Damit hatte ich eigentlich noch nie Probleme... Ohne > Schreibzugriff kann > man Access-DBs ja gar nicht richtig nutzen... > > > Pooling stellt man f�r ASP nunmal in der Registry ein, auf die ein > > Standart-Nutzer meist kaum Einfluss nehmen kann. > > Jeder Provider, der seinen Job ernst nimmt wird wenn M�glich > connection-Pooling einstellen, denn es bringt auch ihm Vorteile... > Weniger starke Auslastung der Server bedeutet, dass er mehr Sites pro > Server hosten kann... > > Da ODBC neben den Kosten auch noch langsamer ist als direkter Zugriff > �ber OLEDB bzw. entsprechenden nativen DB-Treiber wird es kaum > eingesetzt, sondern meist DSN-less Connectionstrings verwendet... > > > Hier gilt es, weitaus mehr zu beachten als reinen > > Performancegewinn/-maximierung. Das ganze muss vor allem > > einfach zu nutzen > > sein. > > > > Claudius > > > | [aspdedatabase] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp > | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
