nächstes »

[ProfiHost - Technik]

Hallo!

Da es leider immer wieder vorkommt, dass Kundenseiten sehr plötzlich stark besucht werden und darunter andere Kunden leiden müssen bzw. es in extremen Fällen zum Ausfall kommt, haben wir an diversen Lösungsansätzen gearbeitet.

Wir möchten Ihnen hiermit unsere Ergebnisse präsentieren und würden uns über Kommentare, Meinungen, Anregungen/Verbesserungsvorschläge freuen.

1.) die max_user_mysql Connections (parallele Scriptverbindungen zum SQL Server) wird erhöht auf 30

2.) dafür werden die Scriptaufrufe (Anzahl der Aufrufe pro 10 Minuten) limitiert (genaue Höhe steht nicht fest wird aber vermutlich bei ca. 1000 liegen)

3.) die genutzten CPU Sekunden / 10 Minuten werden ausgewertet (maximale Höhe steht noch nicht fest)

Wir versprechen uns hiervon weniger Wartungsarbeiten an den Servern, da sich diese quasi selbst überwachen / regulieren und keine Ausfälle mehr, die durch andere Kunden verursacht werden. Der Server deaktiviert dann die entsprechende Domain automatisch und es erscheint eine entsprechende Meldung für den Besucher.

[Michael]

Hallo,
dann mach ich mal den Anfang:
Zunächst einmal begrüße ich es sehr, wenn Maßnahmen getroffen werden sollen, die die Erreichbarkeit aller auf einem Server gehosteten Seiten erhöhen.

Wenn ich mal die momentanen Zahlen aus Punkt 2) nehme, komme ich auf max.  1,67 Scriptaufrufe / Sekunde. Irgendwie paßt da für mich das Verhältnis zu 30 parallelen MySQL-Connections nicht.
Gehe ich mal von größeren Scripten aus, die 3 Sekunden laufen, so kann ich während dieser Laufzeit 5 Aufrufe starten. Um diese 30 Connections auszunutzen, müßten diese Scripte also jeweils 6 parallele Verbindungen aufbauen.
Bei kürzer laufenden Scripten verschiebt sich das Verhältnis durch die Begrenzung 1,67 Aufrufe / Sekunde noch weiter

Ich habe leider keinerlei Erfahrungen mit CMS à la Typo oder Shopsystemen und weiß daher nicht, ob diese derart verschwenderisch mit DB-Connections umgehen. Wenn dem aber nicht so ist, erscheint es mir sinnvoller, die Anzahl der Scriptaufrufe zu Lasten der parallelen Connections zu erhöhen.

Kleine Frage noch zur automatischen Deaktivierung: Nach welcher Zeitspanne soll diese wieder aufgehoben werden?
Soll während dieser Zeit der komplette Zugriff über Port 80 auf diese Domain gesperrt werden und werden nur die DB-Connections gesperrt?

Gruß
Michael

[ProfiHost - Technik]

Hallo Michael!

Erstmal schön, dass sich jemand meldet :-)

Wenn ich mal die momentanen Zahlen aus Punkt 2) nehme, komme ich auf max. 1,67 Scriptaufrufe / Sekunde.

Korrekt - dies ist als Durchschnittswert bei 10 Minuten schon extrem hoch. Vermutlich werden wir das ganze auf 800 legen - dies werden aber die Auswertungen der nächsten zwei Tage ergeben (alle Kunden werden zur Zeit gemessen).

Irgendwie paßt da für mich das Verhältnis zu 30 parallelen MySQL-Connections nicht.

Was heißt in diesem Sinne Verhältnis? Die MySQL Connections stehen ja in keinerlei direktem Zusammenhang mit den Scriptaufrufen / 10 Minuten.

Gehe ich mal von größeren Scripten aus, die 3 Sekunden laufen, so kann ich während dieser Laufzeit 5 Aufrufe starten. Um diese 30 Connections auszunutzen, müßten diese Scripte also jeweils 6 parallele Verbindungen aufbauen.

Korrekt. An sich reichen 10 Connections vollkommen aus - dennoch scheint es bei einigen größeren Shops zu Engpässen zu kommen (in Spitzenzeiten) siehe http://forum.profihost.com/phpBB2/viewtopic.php?t=340 In wie fern man nun sagen müßte, dass diese User vermutlich eh eher einen eigenen Server brauchen kann man so pauschal nicht sagen, da dies mehr von der Scriptlaufzeit abhängt. Unsere ersten Messungen haben z.B. ergeben, dass 95% der Scripte nicht einmal 100 Millisekunden laufen - da sieht die Situation bzgl. Connections schon ganz anders aus.

Wenn dem aber nicht so ist, erscheint es mir sinnvoller, die Anzahl der Scriptaufrufe zu Lasten der parallelen Connections zu erhöhen.

Konkret? Parallele Connections senken - Scriptaufrufe erhöhen? Macht aber keinen Sinn, da dies nicht die eigentliche CPU Auslastung verändert um die es hier primär geht. Es geht ja darum, dass ein User alleine nicht den ganzen Server lahmlegen kann - damit haben die Connections erstmal nichts zu tun.

Kleine Frage noch zur automatischen Deaktivierung: Nach welcher Zeitspanne soll diese wieder aufgehoben werden?
Soll während dieser Zeit der komplette Zugriff über Port 80 auf diese Domain gesperrt werden und werden nur die DB-Connections gesperrt?

Es wird Port 80 / WWW auf eine spezielle Seite geleitet. Bzgl. Aktivierung variieren hier die Vorschläge von 10 Min bis 45 Min.

[Martina]

Hallo,

auch ich habe in letzter Zeit ein paar mal erlebt, dass unsere Domain zeitweise nicht verfügbar war. Meist wurde uns dann auch bestätigt, dass es Serverprobleme gab bzw. RZ-Ausfall.

Nur, wenn ich dann von Ihnen höre, dass es mit dem Server keine Probleme gab und in dieser Zeit unsere Domain nicht ansprechbar war bzw. kein Login mit SSL möglich war, dann frage ich mich woran das liegen kann.

Möglicherweise an hohem Aufkommen an sich auf dem Server?

Zu den aufgeführten Punkten:

1.) die max_user_mysql Connections (parallele Scriptverbindungen zum SQL Server) wird erhöht auf 30

Haben wir uns drüber gefreut, allerdings nachdem wir das mit den 10 Connections gelesen haben, werden wir an den Scripts noch etwas umstellen (sicher ist sicher).

2.) dafür werden die Scriptaufrufe (Anzahl der Aufrufe pro 10 Minuten) limitiert (genaue Höhe steht nicht fest wird aber vermutlich bei ca. 1000 liegen)

Reaktion: Schreck!
Da die Scripte meist sehr kurz laufen und etliche Includes haben und eins ständige nen weiteres aufruft, könnte ich mir vorstellen, dass 1000 in 10 Minuten eine zu starke Limitierung sein könnte.
Es beruhigt mich, dass Sie Messungen durchführen bevor Sie das limitieren. Und rechnen Sie Puffer ein, bitte.

Zu CPU-Auslastung kann ich jetzt nur sagen:
Sicher darf es nicht sein, dass ein Kunde alles blockiert, allerdings muss es hier Konzepte geben, wie man damit umgeht.
Geht es nicht anders, dann muss man wohl den Service hier vorrübergehend einstellen, da ja sonst gar nichts mehr läuft.
Abhilfe muss allerdings dann schnell auch seitens des Kundens und Ihnen machbar sein. Damit meine ich, wenn unser Internetangebot betroffen wäre, dass ich dann als Kunde so schnell wie möglich eine Erweiterung meines Servicepakets / Webspaces / Webservers bekomme (vorausgesetzt ich beauftrage das bei Profihost).
Und da ja dann der Internetauftritt kaltgestellt wird, muss das dann schnell gehen.

Geben Sie also Ihren Kunden die Chance flexibel zu wachsen.
Rechnen Sie Puffer ein für kurzfristige Spitzenzeiten, in dem sie dem Kunden dann auch entgegenkommen können.

Und nun zum Abschluss möchte ich Ihnen sagen, dass wir wirklich sehr zufrieden mit Profihost sind und ganz besonders auch mit Ihrem Support. Probleme werden schnell gelöst und man erhält schnell Antworten.
Bis auf nur wirkliche wenige Ausfälle waren unsere Domains gut erreichbar und die Performance stimmte und ich hoffe, dass das weiterhin so bleibt (auch im RZ Hannover!).

Martina

[jan k.]

Hallo Profihost-Team!
Ich habe in letzter Zeit ebenfalls grosse Probleme mit der Verfuegbarkeit gehabt, was ist da bei ihnen los? DDOS kann doch nicht der einzige Grund fuer Wochen sein...

Ich finde weiterhin die Beschraenkung der Scriptaufrufe nicht gut, da ich ein Onlinespiel betreibe. Zwar heisse ich die Aenderungen prinzipiell willkommen, aber bitte richten Sie es so ein, dass die Besucheranzahl stark steigen darf, ohne dass Beeintraechtigungen auftreten.

Danke,
~Jan

[ProfiHost - Technik]

@Martina

Was für einen Login mit SSL meinen Sie? In diesem Thread soll es um Lösungen gehen nicht darum was nun wann wie konkret war das kann ich Ihnen nicht sagen - dazu müßten Sie dann eine Mail an den Support mit entsprechendem Datum und Uhrzeit schicken.

Haben wir uns drüber gefreut, allerdings nachdem wir das mit den 10 Connections gelesen haben, werden wir an den Scripts noch etwas umstellen (sicher ist sicher).

Bisher hat dies noch nie jemand bis auf zwei oder drei Shop Betreiber geschafft auszunutzen. Denn alles andere wäre der helle Wahnsinn - wie soll ein Server 300 Prozesse o.ä. gleichzeitig bearbeiten - maximal 7 oder 8 sind drin. Real sogar logischerweise nur 4 bei einem Dual Xeon mit Hyperthreading - dies geht dann aber zu weit in die Technik.

Reaktion: Schreck!
Da die Scripte meist sehr kurz laufen und etliche Includes haben und eins ständige nen weiteres aufruft, könnte ich mir vorstellen, dass 1000 in 10 Minuten eine zu starke Limitierung sein könnte.

Includes werden nicht mit einbezogen es sei denn Sie laufen via http:// includes und das sollte man so oder so nicht tun. Ansonsten stellt die Zahl absolut kein Problem dar. Nur mal als Richtwert Ihr Shop verbraucht in Spitzenzeiten gerade einmal 1000 / Stunde nicht pro 10 Minuten (gerade geprüft). Spitzenwert bei Ihnen pro 10 Minuten liegt bei 244 - Durchschnitt bei 50. Sie müssen sich also absolut keine Sorgen machen.

Sicher darf es nicht sein, dass ein Kunde alles blockiert, allerdings muss es hier Konzepte geben, wie man damit umgeht.
Geht es nicht anders, dann muss man wohl den Service hier vorrübergehend einstellen, da ja sonst gar nichts mehr läuft.
Abhilfe muss allerdings dann schnell auch seitens des Kundens und Ihnen machbar sein.

Diesem Text kann ich leider nicht folgen. Es geht hierbei ja nicht darum, dass ein Shop o.ä. zu viele Besucher hat - sondern es geht hierbei um Extreme. z.B. gestern hatte ein User durch einen Programmierfehler 16000 Scriptaufrufe - dies legt dann einen Server lahm - ohne unseren manuellen Eingriff und dass dieser Nachts nicht gerade mal eben innerhalb von 10Sekunden erfolgt, ohne dass ein anderer Kunde dies merkt, sollte verständlich sein.

Und nun zum Abschluss möchte ich Ihnen sagen, dass wir wirklich sehr zufrieden mit Profihost sind und ganz besonders auch mit Ihrem Support. Probleme werden schnell gelöst und man erhält schnell Antworten.
Bis auf nur wirkliche wenige Ausfälle waren unsere Domains gut erreichbar und die Performance stimmte und ich hoffe, dass das weiterhin so bleibt (auch im RZ Hannover!).

Vielen Dank! Ich hoffe ich konnte Sie bzgl. der Limitierungen beruhigen. Sie liegen wirklich weit davon entfernt.


@jan k.

Ich habe in letzter Zeit ebenfalls grosse Probleme mit der Verfuegbarkeit gehabt, was ist da bei ihnen los? DDOS kann doch nicht der einzige Grund fuer Wochen sein...

Sekunde - nicht irgendetwas durcheinander bringen. Es gab zwei DDOS auf das RZ Hannover - dies lag außerhalb unseres Einflußbereiches. Was ansonsten los ist können Sie zum entsprechenden Zeitpunkt via E-Mail, Telefon oder  LiveSupport erfragen - dazu ist dieser Thread nicht gedacht.

Ich finde weiterhin die Beschraenkung der Scriptaufrufe nicht gut, da ich ein Onlinespiel betreibe. Zwar heisse ich die Aenderungen prinzipiell willkommen, aber bitte richten Sie es so ein, dass die Besucheranzahl stark steigen darf, ohne dass Beeintraechtigungen auftreten.

Wenn Sie möchten, nenne ich Ihnen auch Ihre Werte. Dazu bitte eine PM mit Domainnamen.

[Michael]

Irgendwie paßt da für mich das Verhältnis zu 30 parallelen MySQL-Connections nicht.

Was heißt in diesem Sinne Verhältnis? Die MySQL Connections stehen ja in keinerlei direktem Zusammenhang mit den Scriptaufrufen / 10 Minuten.

Nun ja, wer macht schon DB-Connections auf, wenn nicht Scripte? So gesehen gibt's schon einen Zusammenhang. Ich wollte damit auch nur deutlich machen, daß meiner Meinung nach die 30 Connections bei gleichzeitiger Beschränkung der Scriptaufrufe eigentlich niemals erreicht werden können und diese Grenze daher eher weniger Sinn macht. Aber ich sehe das halt, wie gesagt, aus Sicht von jemanden, der seine Scripte selbst schreibt und keine vorgefertigten CMS oder Shopsysteme verwendet.

Korrekt. An sich reichen 10 Connections vollkommen aus - dennoch scheint es bei einigen größeren Shops zu Engpässen zu kommen (in Spitzenzeiten) siehe http://forum.profihost.com/phpBB2/viewtopic.php?t=340 In wie fern man nun sagen müßte, dass diese User vermutlich eh eher einen eigenen Server brauchen kann man so pauschal nicht sagen, da dies mehr von der Scriptlaufzeit abhängt.

Sehe ich genauso. Wenn 10 Connections nicht reichen, ist meiner Meinung nach zuerst eher ein schlampig aufgesetztes Shopsystem verantwortlich als zu geringe MaxConnections.
Davon abgesehen würde ich, wenn ich mit einer Webpräsenz mein Einkommen bestreiten will, ohnehin auf einen Dedi-Server wechseln. Auch bei einem zuverlässigen Provider wie PH, denn irgendein Kunde kann immer mit seinen Scripten querschießen. Oder es läuft eine DOS-Attacke auf eine Domain, die zwar mit der eigenen nicht in Verbindung steht, aber dummerweise auf dem selben Server läuft.

Unsere ersten Messungen haben z.B. ergeben, dass 95% der Scripte nicht einmal 100 Millisekunden laufen - da sieht die Situation bzgl. Connections schon ganz anders aus.

Inwieweit anders? Eigentlich doch eher nochmehr so, wie ich es oben schon angesprochen habe. Nicht die Anzahl der Connections werden der Flaschenhals, sondern die Anzahl Aufrufe. Auch wenn ich zugeben muß, daß sich 1,67 Aufrufe / Sekunde kritischer anhören, als die entsprechende Anzahl / 10 Minuten.

Konkret? Parallele Connections senken - Scriptaufrufe erhöhen? Macht aber keinen Sinn, da dies nicht die eigentliche CPU Auslastung verändert um die es hier primär geht. Es geht ja darum, dass ein User alleine nicht den ganzen Server lahmlegen kann - damit haben die Connections erstmal nichts zu tun.

Wenn die Connections die CPU-Auslastung nicht beeinflussen, dann weiß ich ehrlich gesagt nicht so ganz, warum diese überhaupt in diese Diskussion eingebracht wurden.
Durch die Beschränkung der Scriptaufrufe sollen ja vermutlich primär irregulär laufende Scripts abgebrochen werden. Vielleicht wäre es möglich bei der Zählung der Scriptaufrufe, statt nur auf Domain-Ebene zu gruppieren auf Skript-Ebene zu gruppieren? Oder die Einbeziehung des aufrufenden Hosts (der nur im Fehlerfall gleich bleiben sollte)? Ich weiß allerdings nicht, ob sich diese Information ohne zusätzliche CPU-Belastung einfach verarbeiten läßt.

Es wird Port 80 / WWW auf eine spezielle Seite geleitet. Bzgl. Aktivierung variieren hier die Vorschläge von 10 Min bis 45 Min.

Wenn 10 Minuten das Auslösefenster sind, sollte die selbe Zeitspanne meiner Meinung nach auch zur (zumindest ersten) Deaktivierung führen.
Ggfls. könnte bei einer sofortigen Neuauslösung ja die Sperre zunehmend länger aktiv bleiben.

[Martina]

Includes werden nicht mit einbezogen es sei denn Sie laufen via http:// includes und das sollte man so oder so nicht tun. Ansonsten stellt die Zahl absolut kein Problem dar. Nur mal als Richtwert Ihr Shop verbraucht in Spitzenzeiten gerade einmal 1000 / Stunde nicht pro 10 Minuten (gerade geprüft). Spitzenwert bei Ihnen pro 10 Minuten liegt bei 244 - Durchschnitt bei 50. Sie müssen sich also absolut keine Sorgen machen.

Woher wissen Sie was Sie prüfen mussten? Domain hatte ich doch gar nicht angegeben? Verwechseln Sie mich auch nicht? Martina ist nur mein Nickname hier im Forum. Vielleicht bin ich nicht weiblich? Obwohl das ja keinen Unterschied machen SOLLTE.
 :?:

[ProfiHost - Technik]

Davon abgesehen würde ich, wenn ich mit einer Webpräsenz mein Einkommen bestreiten will, ohnehin auf einen Dedi-Server wechseln. Auch bei einem zuverlässigen Provider wie PH, denn irgendein Kunde kann immer mit seinen Scripten querschießen. Oder es läuft eine DOS-Attacke auf eine Domain, die zwar mit der eigenen nicht in Verbindung steht, aber dummerweise auf dem selben Server läuft.

naja, dass muß eben jeder für sich selber entscheiden (sehe das genau so - wobei auch das Volumen stimmen muß). Sicherer ist es auf jeden Fall - dennoch können wir ja niemanden Zwingen - es sei denn er verursacht zu viel Last.

Inwieweit anders? Eigentlich doch eher nochmehr so, wie ich es oben schon angesprochen habe. Nicht die Anzahl der Connections werden der Flaschenhals, sondern die Anzahl Aufrufe. Auch wenn ich zugeben muß, daß sich 1,67 Aufrufe / Sekunde kritischer anhören, als die entsprechende Anzahl / 10 Minuten.

OK - habe mich vertan - so ist es natürlich richtig. Dennoch sind die Werte ausgesprochen hoch und nicht alle Scripte benötigen DB Connections.

Wenn die Connections die CPU-Auslastung nicht beeinflussen, dann weiß ich ehrlich gesagt nicht so ganz, warum diese überhaupt in diese Diskussion eingebracht wurden.

Jain - also primär beeinflussen diese die CPU nicht. Dadurch dass wir bisher aber nicht die Scriptaufrufe o.ä. gemessen haben haben wir versucht dies durch die DB Connections zu begrenzen - generell begrenzt sein müssen Sie natürlich dennoch da MySQL nicht unendlich viele Connections handeln kann und sonst ein User den MySQL lahmlegen kann.

Durch die Beschränkung der Scriptaufrufe sollen ja vermutlich primär irregulär laufende Scripts abgebrochen werden. Vielleicht wäre es möglich bei der Zählung der Scriptaufrufe, statt nur auf Domain-Ebene zu gruppieren auf Skript-Ebene zu gruppieren?

Nicht nur - Beispiel eine Site wird im TV erwähnt hat 50 verschiedene Scripte - dann würde alles stehen wenn pro Script oder pro aufrufendem Host gemessen wird - und es nie zu einer Abschaltung kommen.

@Martina
Dann schicken Sie mir doch bitte eine PM mit dem Domainnamen - dann sehen wir ob ich richtig lag :-)

[Michael]

Dennoch sind die Werte ausgesprochen hoch und nicht alle Scripte benötigen DB Connections.

Stimmt, aber umgekehrt meistens ;-)
Davon abgesehen scheint wohl merkwürdigerweise mittlerweile niemand mehr ohne ein CMS leben zu können.

Durch die Beschränkung der Scriptaufrufe sollen ja vermutlich primär irregulär laufende Scripts abgebrochen werden. Vielleicht wäre es möglich bei der Zählung der Scriptaufrufe, statt nur auf Domain-Ebene zu gruppieren auf Skript-Ebene zu gruppieren?

Nicht nur - Beispiel eine Site wird im TV erwähnt hat 50 verschiedene Scripte - dann würde alles stehen wenn pro Script oder pro aufrufendem Host gemessen wird - und es nie zu einer Abschaltung kommen.

Den Einwand bzgl. Messung/Script sehe ich ein. Sofern's nicht gerade ein Proxy eines großen Providers ist, sollte ein Host alleine es aber im (manuellen) Betrieb doch eigentlich nicht schaffen, den Server in die Knie zu zwingen. Würde meiner Meinung nach natürlich auch bedeuten, daß man bei einer Messung pro Host die Anzahl Scriptaufrufe deutlich runtersetzten könnte (100-200/10 Minuten?)
Würde im erwähnten Bespiel "TV Nennung der URL" natürlich auch nicht helfen. Aber dann wäre die Bandbreite wahrscheinlich ebenfalls ein Problem angesichts vieler Bandbreitenintensiver Angebote und vieler Besucher mit Breitbandanschlüssen.
Schwieriges Thema halt, weil grundsätzlich kompromiss-verpflichtend.

[flux]

Hallo!

Da es leider immer wieder vorkommt, dass Kundenseiten sehr plötzlich stark besucht werden und darunter andere Kunden leiden müssen bzw. es in extremen Fällen zum Ausfall kommt, haben wir an diversen Lösungsansätzen gearbeitet.

Wir möchten Ihnen hiermit unsere Ergebnisse präsentieren und würden uns über Kommentare, Meinungen, Anregungen/Verbesserungsvorschläge freuen.

1.) die max_user_mysql Connections (parallele Scriptverbindungen zum SQL Server) wird erhöht auf 30

2.) dafür werden die Scriptaufrufe (Anzahl der Aufrufe pro 10 Minuten) limitiert (genaue Höhe steht nicht fest wird aber vermutlich bei ca. 1000 liegen)

3.) die genutzten CPU Sekunden / 10 Minuten werden ausgewertet (maximale Höhe steht noch nicht fest)

Wir versprechen uns hiervon weniger Wartungsarbeiten an den Servern, da sich diese quasi selbst überwachen / regulieren und keine Ausfälle mehr, die durch andere Kunden verursacht werden. Der Server deaktiviert dann die entsprechende Domain automatisch und es erscheint eine entsprechende Meldung für den Besucher.

Schön, dass derartige Überlegungen zur Diskussion gebracht werden. Allerdings bleibt für den nicht "Sachverständigen", unbedarften der mit den Ausführungen nicht unbedingt was anfangen kann und deshalb keine Chance hat was zu beeinflussen unter dem Strich übrig, dass etwas eingeschränkt werden soll/muß, um etwas zu verhindern, was u.U. andere verursachen.
Meine Präsenzen hier werden kaum einen Supergau verursachen, weil es sich um Standardanwendungen handelt. Weshalb ich (technisch) auch nur eingeschränkt verstehe um was es hier konkret geht.

Ist es nicht ein besserer Ansatz "kritische" Anwendungen/Anwender auf entsprechende leistungsfähige(gere) Server zu verlagern und dann derartige Experimente zu verfolgen, zum Ziele der Vermeidung von Ausfällen. Auch könnte die Lösung aussehen, weniger User auf einen Server. Mit Einschränkungen habe ich so meine Probleme, weil schlechte Erfahrungen, bei anderen Hostern. Um das zu vermeiden, Einschränkungen, bin ich eigentlich hier bei Profihost gelandet.......

[Michael]

Hallo Flux

Allerdings bleibt für den nicht "Sachverständigen", unbedarften der mit den Ausführungen nicht unbedingt was anfangen kann und deshalb keine Chance hat was zu beeinflussen unter dem Strich übrig, dass etwas eingeschränkt werden soll/muß, um etwas zu verhindern, was u.U. andere verursachen.

Ohne Dir zu Nahe treten zu wollen, aber Du kannst kaum anderen vorwerfen, daß Du Dich nicht an der Diskussion beteiligen kannst, weil Dir der Sachverstand fehlt.
Allgemein fällt mir in letzter Zeit auf, daß verstärkt Techniken (z.B. CMS=Content Management Systeme à la Typo) eingesetzt werden, weil es ja so schick ist, die Leute aber überhaupt nicht das entsprechende Wissen mitbringen und es sich auch nicht von Grund auf aneignen wollen. Aber das ist jetzt ein anderes Thema.

Meine Präsenzen hier werden kaum einen Supergau verursachen, weil es sich um Standardanwendungen handelt. Weshalb ich (technisch) auch nur eingeschränkt verstehe um was es hier konkret geht.

Ich gehe mal davon aus, daß Du mit Standardanwendungen statische HTML-Seiten meinst?! Dann betreffen Dich die Auswirkungen der hier diskutierten Einschränkungen sowieso nicht. Es geht ausschließlich um Serverseitige Scriptaufrufe und Datenbank-Anbindungen

Ist es nicht ein besserer Ansatz "kritische" Anwendungen/Anwender auf entsprechende leistungsfähige(gere) Server zu verlagern ...

1. Wie willst Du die Einteilung vornehmen? Egal wonach, es wird immer eine statische Einteilung sein. Die schon in diesem Thread genannten Probleme "Fehlerhaftes Script" oder "Plötzlicher sprunghafter Anstieg der Besucherzahlen" bekommst Du damit nicht in den Griff
2. Profihost ist ein gewinnorientiertes Unternehmen. Leistungsfähigere Server kosten mehr Geld. Ergo würden die Kosten für die Kunden steigen. Womit wir wieder bei dem Problem aus 1. landen. Wer woll dann gezwungen werden, mehr zu zahlen?

Auch könnte die Lösung aussehen, weniger User auf einen Server.

Siehe voriger Abschnitt unter 2.

Mit Einschränkungen habe ich so meine Probleme, weil schlechte Erfahrungen, bei anderen Hostern.

Um mehr oder minder keine Einschränkungen zu haben, solltest Du vielleicht einen Dedizierten Server in Betracht ziehen. Auf einem Shared Server wird jeder vernünftige Provider Beschränkungen vornehmen. Alles andere wäre fahrlässig (Erfahrungen mit einem solchen Provider mußte ich leider auch schon machen, kann ich gerne drauf verzichten)
Solange Einschränkungen nicht willkürlich vorgenommen, und wie in diesem Fall sogar mit den Kunden ausdiskutiert werden, habe ich nichts gegen sie einzuwenden.

Gruß
Michael

[flux]

@michael
In Kürze ein paar Anmerkungen zu deinen Ausführungen:

Du kannst mir nicht zu nahe treten, da ich niemandem etwas vorgeworfen habe, ich mir auch den Schuh nicht anziehe mich mit einer Technik zu beschäftigen, die ich nicht beherrsche.

Meine "Standardanwendungen" beziehen sich in der Tat auf html, php, Datenbankanbindung.

Das Profihost ein gewinnorientiertes Unternehmen ist, ist auch mir nicht entgangen, allerdings solltest du nicht vergessen, dass Kunden auch schließlich für Leistungen bezahlen und keine kostenlosen Zugaben erwarten/verlangen. Einteilungen, wenn sie denn vorgenommen werden, können nach den Kriterien erfolgen: wer erzeugt mit was große CPU-Last und wie oft.

Wenn ich einen dezidierten Server wirklich brauchen würde, dann hätte ich bereits einen.

Auch ich bin der Meinung, dass es positiv von einem Provider ist, wenn etwas mit Kunden dikutiert wird, aber wie schon gesagt, man muß auch was von der Materie verstehen, um sachlich/kompetent mitzudiskutieren.
Wenn ich dazu kompetent wäre, dann wäre ich sicher nicht auf einem shared Server, (entsprechende Anwendungen, die den Einsatz eines "eigenen" Servers rechtfertigen würden vorausgesetzt).

[Michael]

@michael
Meine "Standardanwendungen" beziehen sich in der Tat auf html, php, Datenbankanbindung.

Wieso "in der Tat"? PHP und DB war nicht meine Annahme. Denn dann betrifft Dich diese Diskussion sehr wohl und DB-Connections und Scriptaufrufe sollten (zumindest in den Grundzügen) daher meiner Meinung nach schon zu Deinem Wissensstand gehören.

Das Profihost ein gewinnorientiertes Unternehmen ist, ist auch mir nicht entgangen, allerdings solltest du nicht vergessen, dass Kunden auch schließlich für Leistungen bezahlen und keine kostenlosen Zugaben erwarten/verlangen.

An den Leistungen, für die Du bezahlst, ändert sich IMHO nichts. Oder bezahlst Du für das Recht, eine übermäßige Last zu erzeugen, die andere Kundenpräsenzen u.U. unerreichbar macht und somit zu eingeschränkten Leistungserbringung gegenüber diesen Kunden führt? Hier geht es doch nicht darum, willkürlich jemanden etwas wegzunehmen, sondern den Server für alle verfügbar zu halten.

Einteilungen, wenn sie denn vorgenommen werden, können nach den Kriterien erfolgen: wer erzeugt mit was große CPU-Last und wie oft.

Nochmal, diese Kriterien sind nicht statisch, sondern u.U. hoch dynamisch. Es gab schon genug Fälle, in denen Webseiten ohne Vorwarnung hochgradig bekannt wurden, weil z.B. ein Stefan Raab die URL nannte.
Solchen dynamischen Prozessen kann man nur mit dynamischen Maßnahmen entgegentreten.

Wenn ich dazu kompetent wäre, dann wäre ich sicher nicht auf einem shared Server, (entsprechende Anwendungen, die den Einsatz eines "eigenen" Servers rechtfertigen würden vorausgesetzt).

Och, es gibt auch managed Dedi-Server. Wie so vieles nur eine Preisfrage.

[flux]

@Michael
belassen wir es dabei, zumindest was mich betrifft. Jede weitere Diskussion zwischen uns beiden ist imho haarspalterei und bringt das Problem an sich nicht weiter. Ich weiß wie du darüber denkst und du weißt was ich zu diesem Thema denke.........