Hallo!
Unsere Kunden setzen z.B. Typo3 ein. Ich kenne aber eigentlich kaum Kunden davon, die das mit der GDlib machen. Stattdessen kommt ImageMagick (bei uns GraphicsMagick) zum Einsatz. IM / GM werden aber per exec() in der Shell ausgeführt und damit ein separater Prozess gestartet, der meine Meinung nach eigentlich nicht zum PHP memory_limit zählt. Wir haben hier einige tausend Kunden mit Shared Webhosting, aber ich muss sagen, es war bis auf 1 (!) noch keiner dabei, der wirklich nicht mit den 16 MB ausgekommen ist. Der Wert ist meiner Meinung nach eh nur für den Installer von Relevanz - bei Veyton lautet vielleicht die Devise: Viel hilft viel und erspart uns so manche Supportanfrage. ;-)
Weil es nicht ein exklusiver Rootserver ist, wo 1 Kunde tun und lassen kann, was er will, sondern Shared Webhosting. Andere Kunden (und seien es nur 19 wie beim Business 20) werden es sicherlich nicht für gut heißen, wenn der Server auf Grund übermäßiger Scriptresourcen (Speicher/CPU/ I/O) eines einzelnen Kunden sagen wir pauschal langsamer läuft. Es sagt ja keiner etwas, wenn ein Script mal richtig Resourcen verbraucht (z.B. Galerie Vorschaubilder berechnen), aber doch bitte (wissentlich) nicht den ganzen Tag lang. Man kann doch nicht spiegel.de auf Shared-Webhosting betreiben, sieht denke ich jeder ein, warum sollte das z.B. bei einer Party-Community mit umfangreicher Bildergalerie dann auf einmal kein Problem sein? Ich finde Limits hilfreich, um bei Shared-Webhosting Kunden vor solchen Resourcenfressern einzelner Kunden zu schützen. Anpassen kann man individuell immer noch!
Wenn bei uns ein Kunde z.B. wegen einer umfangenreichen Party-Community anfrägt, dann kriegt er garantiert kein Webhosting "Web L" mit "unlimitiert Kunden pro Server" empfohlen, sondern eher ein Business 20 / Business 5 oder einen VServer oder einen Rootserver. "Wer spiegel.de bei uns für 99c hosten will, der ist bei uns definitiv falsch aufgehoben."
Ein Kunde mit einer privaten Homepage mit Galerie kann freilich auch ein günstiges Paket nehmen und kriegt trotzdem das memory_limit angepaßt - aber wir gehen halt nicht davon aus, dass eine Privatperson 10* am Tag tausende von neuen Bildern hochlädt. ;-) Wir behalten halt solche Homepages im Auge und verschieben diese ggf. auf "ruhigere" Server. Ich halte nichts von im nachhinein den Scherbenhaufen korrigieren.
Der Meinung bin ich nicht, jedenfalls nicht so pauschal ausgedrückt; abgesehen davon dass es keinen zugesicherten Speicher a la VServer bei Shared Webhosting gibt. Ich halte unsere 16 MB memory_limit als Standardwert auf Grund von tausenden von Shared-Webhosting Kunden nach wie vor als praxisnah. Das da mal eine Webseite mehr Resourcen benötigt als andere ist normal und wir verweigern ja auch keinem ein höheres memory_limit - der Kunde aus diesem Thread hat es ja auch bekommen.
Ich würde eher sagen, unsere Business Paket Kunden wollen ihre Ruhe von den ganzen Scriptkiddies, die bei anderen Hostern machen dürfen, was Sie wollen. Deutlich höhere Resourcen kann ich zumindest bei unseren meisten Business Kunden gegenüber den Privatkunden nicht feststellen, die wollen eher Stabilität und "garantierte" hohe Performance.
Ich weiß nicht, ob das aus dem ursprünglichen Zitat rauskommt: Wir haben dem Kunden das Limit von 32 MB sang und klanglos eingestellt. Der Kunde regte sich einzig (maslos) darüber auf, dass er den Wert nicht von Anfang an hatte. Er wollte wissen, was uns nur einfällt, einen kleineren Wert standardmäßig einzustellen.
Viele Grüße,
Ingo Fritz
ECS-Webhosting
@ecswebhosting: 16 MB memory_limit ist schon ziemlich wenig. Die meisten Webapps im Businessumfeld machen irgendwas mit Bildern oder haben Im-/Exportfunktionen, die viel Speicher benötigen. Wie viele eurer Kunden laufen wirklich mit 16 MB?
Ein Skript ist nicht schlecht, weil es 64 MB RAM braucht. Und selbst wenn? Warum soll der Kunde nicht auch schlechte Skripte benutzen dürfen?
Wenn bei uns ein Kunde z.B. wegen einer umfangenreichen Party-Community anfrägt, dann kriegt er garantiert kein Webhosting "Web L" mit "unlimitiert Kunden pro Server" empfohlen, sondern eher ein Business 20 / Business 5 oder einen VServer oder einen Rootserver. "Wer spiegel.de bei uns für 99c hosten will, der ist bei uns definitiv falsch aufgehoben."
Ein Kunde mit einer privaten Homepage mit Galerie kann freilich auch ein günstiges Paket nehmen und kriegt trotzdem das memory_limit angepaßt - aber wir gehen halt nicht davon aus, dass eine Privatperson 10* am Tag tausende von neuen Bildern hochlädt. ;-) Wir behalten halt solche Homepages im Auge und verschieben diese ggf. auf "ruhigere" Server. Ich halte nichts von im nachhinein den Scherbenhaufen korrigieren.
Wieso behaltet ihr euch das Recht vor, zu entscheiden welche Skripte benutzt werden dürfen? Wenn der Kunde den ihm zustehenden Speicher komplett für nur einen PHP-Prozess verbraten will, sollte er das auch dürfen.
Es sind Businesskunden, die wissen was sie tun. Davon sollte man jedenfalls ausgehen.
Insofern gängelt ihr eure (kräftig zahlenden) Kunden imho zu Unrecht mit fadenscheinigen Argumenten. Dann muss man sich nicht wundern, wenn man solche Kunden wie den TO geradezu anlockt.
Viele Grüße,
Ingo Fritz
ECS-Webhosting
Kommentar