Serverabschaltung durch Provider ohne Vorwarnung da zu viel HD Last???
- Thread starter Muenzenwert
- Start date
D
Deleted member 11740
Guest
Ich gehe mal von aus, dass der Betreiber irgendwelche Probleme hat. Du wirst mit deiner Seite wahrscheinlich eins der Probleme des Betreibers sein. Geh so schnell wie möglich von denen weg.
Unabhängig davon solltest du dein Seite modernisieren. Das würde ich aber nicht beim aktuellen Dienstleister machen.
Sonst suchst du deine eigenen Fehler und die des Providers und ich schätze mal, dass da Providerseitig einiges schief läuft.
Unabhängig davon solltest du dein Seite modernisieren. Das würde ich aber nicht beim aktuellen Dienstleister machen.
Sonst suchst du deine eigenen Fehler und die des Providers und ich schätze mal, dass da Providerseitig einiges schief läuft.
Muenzenwert
New Member
Antwort vom Provider auf die Frage ob die Daten auf die Festplatte am Web oder am DB Server geschrieben wurden:
Guten Tag Herr XXXXXXXXX,
> wie bitte sollte ich in ein paar Minuten Programme ändern?
Es ist klar, daß Sie das nicht in ein paar Minuten schaffen werden! Sie hätten die Scripte bereits seit Jahren eigentlich ändern müssen!
Daher sollten Sie jetzt die Umstellungen angehen! Erfahrungsgemäß gehen Sie wie folgt vor:
Ändern Sie NUR PHP zu MySQL in allen Scripten, wo dies notwendig ist!
Dazu gehören im Regelfall die Befehle, die Sie in allen Scripten suchen müssen - Identifizieren Sie also zuerst die Scripte
mysql_connect zu mysqli_connect - entsprechend dem gültigen Syntax!
Suchen Sie nach Suchwort: query
Suchen Sie nach Suchwort: error
Suchen Sie nach Suchwort: row
Suchen Sie nach Suchwort: fetch
Sie sollten damit alle Scripte finden! Schauen Sie sich die Stellen an und schauen Sie sich den zusammen hängenden Syntax in
Verbindung an! Es sind lediglich Anpassungen notwendig, damit es wieder funktionert!
Wenn alle Scripte laufen mit überarbeiteter PHP->MySQL Struktur, suchen Sie nach den anderen Fehlern die PHP meldet, wie
z.B. Variablen nicht definiert oder deprecated!
Zuletzt wird dann auf php7.1 umgeschaltet!
Nein, daß Sie auf eine neuere PHP-Version umstellen müssen, daß sollte Ihnen wirklich sehr sehr lang bekannt sein! Es ist doch
sämtliche Pressen gegangen! Wenn Sie das alles ignoriert haben, haben Sie einfach fahrlässig gehandelt und mußten sogar mit
einem Einbruch und einem Folgeschaden rechnen!
Wenn Sie jetzt damit beginnen die Umstellung zu machen, sollten Sie diese in ein paar Tagen fertig haben!
---------------------------------------------------------------------------------------------------------------------------------------
So langsam bekomme ich das Gefühl, dass ich keine Antwort bekommen werde welcher Server so viele Daten auf eine Festplatte geschrieben hat - der angebliche Grund für die Server Abschaltung.
Je mehr ich mir diese Mails vom Provider ansehe desto mehr bekomme ich das Gefühl er hat den Server abgeschaltet um mich zur PHP Umstellung zu motivieren...
Ihm scheinen Festplattenzugriffe nicht mehr zu interessieren... keine einzige Antwort hat etwas mit der Festplatte zu tun - kann das sein????
@DeaD_EyE
Ja sehe ich im Moment auch so, ich suche mir einen neuen Provider, bringe Alles wieder zum laufen und stelle innerhalb der Testversion danach in Ruhe PHP um..
Die Suche nach dem Problem kann ich wohl aufgeben.. ohne Idee oder Hinweis kann und will ich an den Scripten nichts ändern was sinnvoll wäre um Festplattenzugriffe / Daten HD zu minimieren..
Ich schaue mir nun noch die Logfiles vor der Abschaltung an, mache Backups und werde auch noch die Daten und Bilder vom Server downloaden über Nacht.. zumindest habe ich dann die aktuellen Daten hier.. nicht nur in Backups beim Provider..
Guten Tag Herr XXXXXXXXX,
> wie bitte sollte ich in ein paar Minuten Programme ändern?
Es ist klar, daß Sie das nicht in ein paar Minuten schaffen werden! Sie hätten die Scripte bereits seit Jahren eigentlich ändern müssen!
Daher sollten Sie jetzt die Umstellungen angehen! Erfahrungsgemäß gehen Sie wie folgt vor:
Ändern Sie NUR PHP zu MySQL in allen Scripten, wo dies notwendig ist!
Dazu gehören im Regelfall die Befehle, die Sie in allen Scripten suchen müssen - Identifizieren Sie also zuerst die Scripte
mysql_connect zu mysqli_connect - entsprechend dem gültigen Syntax!
Suchen Sie nach Suchwort: query
Suchen Sie nach Suchwort: error
Suchen Sie nach Suchwort: row
Suchen Sie nach Suchwort: fetch
Sie sollten damit alle Scripte finden! Schauen Sie sich die Stellen an und schauen Sie sich den zusammen hängenden Syntax in
Verbindung an! Es sind lediglich Anpassungen notwendig, damit es wieder funktionert!
Wenn alle Scripte laufen mit überarbeiteter PHP->MySQL Struktur, suchen Sie nach den anderen Fehlern die PHP meldet, wie
z.B. Variablen nicht definiert oder deprecated!
Zuletzt wird dann auf php7.1 umgeschaltet!
Nein, daß Sie auf eine neuere PHP-Version umstellen müssen, daß sollte Ihnen wirklich sehr sehr lang bekannt sein! Es ist doch
sämtliche Pressen gegangen! Wenn Sie das alles ignoriert haben, haben Sie einfach fahrlässig gehandelt und mußten sogar mit
einem Einbruch und einem Folgeschaden rechnen!
Wenn Sie jetzt damit beginnen die Umstellung zu machen, sollten Sie diese in ein paar Tagen fertig haben!
---------------------------------------------------------------------------------------------------------------------------------------
So langsam bekomme ich das Gefühl, dass ich keine Antwort bekommen werde welcher Server so viele Daten auf eine Festplatte geschrieben hat - der angebliche Grund für die Server Abschaltung.
Je mehr ich mir diese Mails vom Provider ansehe desto mehr bekomme ich das Gefühl er hat den Server abgeschaltet um mich zur PHP Umstellung zu motivieren...
Ihm scheinen Festplattenzugriffe nicht mehr zu interessieren... keine einzige Antwort hat etwas mit der Festplatte zu tun - kann das sein????
@DeaD_EyE
Ja sehe ich im Moment auch so, ich suche mir einen neuen Provider, bringe Alles wieder zum laufen und stelle innerhalb der Testversion danach in Ruhe PHP um..
Die Suche nach dem Problem kann ich wohl aufgeben.. ohne Idee oder Hinweis kann und will ich an den Scripten nichts ändern was sinnvoll wäre um Festplattenzugriffe / Daten HD zu minimieren..
Ich schaue mir nun noch die Logfiles vor der Abschaltung an, mache Backups und werde auch noch die Daten und Bilder vom Server downloaden über Nacht.. zumindest habe ich dann die aktuellen Daten hier.. nicht nur in Backups beim Provider..
Last edited:
Muenzenwert
New Member
@mr_brain
ich habe keinen Zugriff auf Shell, nur auf Plesk.. denke ich, sonst hätte ich nun iostat am laufen... iotop kenne ich bisher nicht..
Logfiles:
Ich habe mir nun die Logfiles vor Abschaltung angesehen, hier ist nichts zu erkennen, eingesehen habe ich Errors und Apache Log... vor Abschaltung waren eher weniger Fehler Einträge als heute... Traffic hielt sich in Grenzen.. nichts ungewöhnliches gesehen..
Files habe ich angesehen.. kein neues Datum, Dateigrößen wie gehabt, eher kein Code Injection
FTP-Download ist nun am laufen um Bilder usw. hier zu haben
DB immer noch kein Swap, Server scheint sehr wenig von der HD nachzuladen
CPU nun bei 1.4%
Letzte Stunde 13 Log Einträge, davon dieses Mal sogar 3 PHP Warnings / PHP Notice: Undefined variable
Seit Server wieder am laufen ist kein Timeout... wobei ich nur Frontend am laufen habe, keine Datengenerierung
-> ich habe keine Idee wo ich anfangen kann das Problem zu suchen (Hohes Datenaufkommen HD, TBs in 10 Minuten)
ich habe keinen Zugriff auf Shell, nur auf Plesk.. denke ich, sonst hätte ich nun iostat am laufen... iotop kenne ich bisher nicht..
Logfiles:
Ich habe mir nun die Logfiles vor Abschaltung angesehen, hier ist nichts zu erkennen, eingesehen habe ich Errors und Apache Log... vor Abschaltung waren eher weniger Fehler Einträge als heute... Traffic hielt sich in Grenzen.. nichts ungewöhnliches gesehen..
Files habe ich angesehen.. kein neues Datum, Dateigrößen wie gehabt, eher kein Code Injection
FTP-Download ist nun am laufen um Bilder usw. hier zu haben
DB immer noch kein Swap, Server scheint sehr wenig von der HD nachzuladen
CPU nun bei 1.4%
Letzte Stunde 13 Log Einträge, davon dieses Mal sogar 3 PHP Warnings / PHP Notice: Undefined variable
Seit Server wieder am laufen ist kein Timeout... wobei ich nur Frontend am laufen habe, keine Datengenerierung
-> ich habe keine Idee wo ich anfangen kann das Problem zu suchen (Hohes Datenaufkommen HD, TBs in 10 Minuten)
D
Deleted member 15972
Guest
Ich bezog mich explizit auf Aussagen wie "800 mal schneller als SATA", Logs ohne Fehler (gut, könnte man auf dev null schreiben)...", etc... pp.
Auch finde ich es leicht merkwürdig, wenn der Anbieter keine Möglichkeiten hat, "Problemkunden" zu drosseln, sondern stattdessen gleich den gesamten Server sperrt. Im Kontext zu dem was d4f in den AGB gefunden hat, hat das auch einen üblen Beigeschmack.
Wobei man fairerweise sagen muss, dass der Support zumindest bemüht ist, zu sagen, wie die Skripte angepasst werden sollten. Das würde dann auch nicht jeder machen. Ändert natürlich nichts daran, dass ich persönlich mir einen anderen Hoster suchen würde.
Muenzenwert
New Member
Status:
Server läuft noch, keine Antwort vom Provider die etwas mit Festplatte zu tun hat.. weiterhin nur PHP Update in den Antworten...
Ich habe PHP Friends eine Anfrage für Managed Server geschickt
PHP Warnings habe ich nun die ersten Einträge gefixt, hilft sicher nicht aber wenn das den Provider so wichtig ist.. bis zum Umzug muss Server noch laufen und diese Fixes sind so oder so gut zu machen...
Files / DB Backup bin ich noch am Downloaden - just in case...
Ich habe ein wenig darüber nachgedacht wo und wie ein Script einige TB in 10 Minuten generieren kann... bisher immer noch keine Idee... selbst Swap DB wäre es nicht einfach TBs zu generieren...
Einige TBs -> 3TB oder so
3 TB = 3000 GB
3000 GB / 10 Minuten / 60 Sekunden = 5 GB die Sekunde... DB hat insgesamt 10GB wie soll die DB 10 Minuten lang 5GB pro Sekunde Swappen?
5GB die Sekunde bezweifle ich sogar dass die HD soviel über Minuten schreiben oder lesen kann...
Liege ich da falsch? wie viel können denn solche Server Platten lesen / schreiben die Sekunde über Minuten?
Mit meinem anderen Projekt bin ich auf einem großen eigenen Server mit 1TB SDD Platten im Raid 10 und 320GB RAM plus nette CPUs dort denke ich schaffe ich paar hundert MB die Sekunde wenn die 30 TB DB anfängt zu swappen..
-> ich bezweifle immer mehr, dass mein Projekt wirklich die Platten so belastet hatten...
Server läuft noch, keine Antwort vom Provider die etwas mit Festplatte zu tun hat.. weiterhin nur PHP Update in den Antworten...
Ich habe PHP Friends eine Anfrage für Managed Server geschickt
PHP Warnings habe ich nun die ersten Einträge gefixt, hilft sicher nicht aber wenn das den Provider so wichtig ist.. bis zum Umzug muss Server noch laufen und diese Fixes sind so oder so gut zu machen...
Files / DB Backup bin ich noch am Downloaden - just in case...
Ich habe ein wenig darüber nachgedacht wo und wie ein Script einige TB in 10 Minuten generieren kann... bisher immer noch keine Idee... selbst Swap DB wäre es nicht einfach TBs zu generieren...
Einige TBs -> 3TB oder so
3 TB = 3000 GB
3000 GB / 10 Minuten / 60 Sekunden = 5 GB die Sekunde... DB hat insgesamt 10GB wie soll die DB 10 Minuten lang 5GB pro Sekunde Swappen?
5GB die Sekunde bezweifle ich sogar dass die HD soviel über Minuten schreiben oder lesen kann...
Liege ich da falsch? wie viel können denn solche Server Platten lesen / schreiben die Sekunde über Minuten?
Mit meinem anderen Projekt bin ich auf einem großen eigenen Server mit 1TB SDD Platten im Raid 10 und 320GB RAM plus nette CPUs dort denke ich schaffe ich paar hundert MB die Sekunde wenn die 30 TB DB anfängt zu swappen..
-> ich bezweifle immer mehr, dass mein Projekt wirklich die Platten so belastet hatten...
Last edited:
PHP-Friends
Active Member
Muenzenwert
New Member
Status:
Neuer Server ist nun eingerichtet bei PHP-Friends, Projekt aber noch nicht umgezogen.
Alter Server ist noch am laufen...
Letzte Mails: (wie gehabt..)
Provider:
Guten Tag Herr XXXXX,
Wie weit sind Sie mit der Korrektur der Scripte? Sie verursachen immer noch auf dem Host zu viel Last durch Disk-IO-Aktivitäten!
Sie sollten möglichst schnell auf php 7.1. umstellen können! Es sind dann weitere Arbeiten notwendig, da diverse MySQL-Scripte unsauber
entwickelt sind und grundsätzlich einen Tabellen-Scan verursachen!
Meine Antwort:
Guten Tag Herr xxxxx,
es ist wenig hilfreich zu sagen das Projekt verursacht zu viel IO Last und gleichzeitig jede Frage zur IO Last zu ignorieren.
Soweit ich bisher feststellen konnte swappt DB normalerweise nicht. Programme schreiben keine Files (mit Ausnahme von Bildern nach Upload - size und compression wird gemacht und neue Bild Files erzeugt)
Ich habe bisher keine Idee wo ich bei der IO Last ansetzen kann.
Fragen welcher Server betroffen ist DB oder Web, Fragen nach Tool um IO Last zu sehen, Fragen nach Stats IO haben Sie jedes Mal bisher ignoriert und nur über ein PHP Update geschrieben.
Falls Programme unsauber sind, was hilft dann ein PHP Update? Auch in PHP 7.1 wären die Programme unsauber -> gleiche IO Last.
Wie viel KB IO werden denn von 20 PHP Warnings die Stunde erzeugt? Kann das wirklich ein Grund sein?
Ein Webserver der keine 20 Meldungen die Stunde im Logfile aushält ist wohl viel zu klein dimensioniert - wobei dann die CPU Last weit höher wäre -> Logfile kann auch kein Grund für IO Last in diesem Umfang sein...
Über einen IO Monitor wäre es sehr einfach zu sagen, hier in diesem Verzeichnis oder diese Files belasten die HD -> sehr einfach zu debuggen und zu ändern..
Was ist an einem Table Scan unsauber? Ein Table Scan kann diverse sinnvolle Gründe haben.. und was hat ein Table Scan mit der Platten-Last zu tun? So eine Table liegt im Ram Cache, Scan Anfrage werden über das Cache / Ram beantwortet und nicht über einen Platten Zugriff -> wiederum wenig hilfreich für das Problem - es sei denn ein Test würde zeigen Table X liesst ständig Daten von der Platte.. aber das sehe ich in meiner Glaskugel hier nicht und andere Möglichkeiten habe ich leider nicht um das Problem einzugrenzen.
Falls Scans das Cache zu sehr belasten würde man dies an der CPU Last sehen, das kann ich einsehen - CPU normalerweise bei 1,5% Last -> also eher kein Problem.
Was wurde gemacht:
Ich habe mich eingelesen was zu Problemen führen könnte Update PHP, scheint für das Projekt nicht so problematisch zu sein.
Erste Programme / Scripte vor allem im Admin Bereich sind nun umgestellt auf MySqlI, scheint soweit zu laufen und ich kann kommende Woche nach ein paar weiteren Test scheinbar alle Scripte umstellen - was wohl die größte Anpassung für ein Update PHP im Prokekt ist.
PHP Update bringt aber nichts in Bezug auf IO Last.
Die Frage ist nun wollen wir weiter über ein PHP Update sprechen oder wollen wir nun anfangen das eigentliche Problem zu finden?
Finden kann ich das Problem aber nicht ohne die Möglichkeit zu haben die Plattenlast zu sehen / Monitor starten zu können...
Neuer Server ist nun eingerichtet bei PHP-Friends, Projekt aber noch nicht umgezogen.
Alter Server ist noch am laufen...
Letzte Mails: (wie gehabt..)
Provider:
Guten Tag Herr XXXXX,
Wie weit sind Sie mit der Korrektur der Scripte? Sie verursachen immer noch auf dem Host zu viel Last durch Disk-IO-Aktivitäten!
Sie sollten möglichst schnell auf php 7.1. umstellen können! Es sind dann weitere Arbeiten notwendig, da diverse MySQL-Scripte unsauber
entwickelt sind und grundsätzlich einen Tabellen-Scan verursachen!
Meine Antwort:
Guten Tag Herr xxxxx,
es ist wenig hilfreich zu sagen das Projekt verursacht zu viel IO Last und gleichzeitig jede Frage zur IO Last zu ignorieren.
Soweit ich bisher feststellen konnte swappt DB normalerweise nicht. Programme schreiben keine Files (mit Ausnahme von Bildern nach Upload - size und compression wird gemacht und neue Bild Files erzeugt)
Ich habe bisher keine Idee wo ich bei der IO Last ansetzen kann.
Fragen welcher Server betroffen ist DB oder Web, Fragen nach Tool um IO Last zu sehen, Fragen nach Stats IO haben Sie jedes Mal bisher ignoriert und nur über ein PHP Update geschrieben.
Falls Programme unsauber sind, was hilft dann ein PHP Update? Auch in PHP 7.1 wären die Programme unsauber -> gleiche IO Last.
Wie viel KB IO werden denn von 20 PHP Warnings die Stunde erzeugt? Kann das wirklich ein Grund sein?
Ein Webserver der keine 20 Meldungen die Stunde im Logfile aushält ist wohl viel zu klein dimensioniert - wobei dann die CPU Last weit höher wäre -> Logfile kann auch kein Grund für IO Last in diesem Umfang sein...
Über einen IO Monitor wäre es sehr einfach zu sagen, hier in diesem Verzeichnis oder diese Files belasten die HD -> sehr einfach zu debuggen und zu ändern..
Was ist an einem Table Scan unsauber? Ein Table Scan kann diverse sinnvolle Gründe haben.. und was hat ein Table Scan mit der Platten-Last zu tun? So eine Table liegt im Ram Cache, Scan Anfrage werden über das Cache / Ram beantwortet und nicht über einen Platten Zugriff -> wiederum wenig hilfreich für das Problem - es sei denn ein Test würde zeigen Table X liesst ständig Daten von der Platte.. aber das sehe ich in meiner Glaskugel hier nicht und andere Möglichkeiten habe ich leider nicht um das Problem einzugrenzen.
Falls Scans das Cache zu sehr belasten würde man dies an der CPU Last sehen, das kann ich einsehen - CPU normalerweise bei 1,5% Last -> also eher kein Problem.
Was wurde gemacht:
Ich habe mich eingelesen was zu Problemen führen könnte Update PHP, scheint für das Projekt nicht so problematisch zu sein.
Erste Programme / Scripte vor allem im Admin Bereich sind nun umgestellt auf MySqlI, scheint soweit zu laufen und ich kann kommende Woche nach ein paar weiteren Test scheinbar alle Scripte umstellen - was wohl die größte Anpassung für ein Update PHP im Prokekt ist.
PHP Update bringt aber nichts in Bezug auf IO Last.
Die Frage ist nun wollen wir weiter über ein PHP Update sprechen oder wollen wir nun anfangen das eigentliche Problem zu finden?
Finden kann ich das Problem aber nicht ohne die Möglichkeit zu haben die Plattenlast zu sehen / Monitor starten zu können...
greystone
Active Member
Für den Fall, dass das noch nicht läuft: Ein tägliches Backup(Dateien + Datenbankdump) wäre zu sehr empfehlen, in einer Situation, in dem einem der Hoster schon mal den Saft abgedreht hat und dies wahrscheinlich bald wieder tun wird, wenn er nicht die erwarteten Reaktionen erhält. Und danach sieht es aktuell aus.
d4f
Kaffee? Wo?
Ich liebe es zu sehen wie das Forum mitverantwortlich ist dass aus hilflos-suchenden Antworten an den Anbieter ein kräftiger Gegenbiss wurde.
Insbesondere bei kleineren Anbieter kann es wie @greystone sagt natürlich passieren dass man, Vertrag hin oder her, einfach terminiert wird als Trotzreaktion, falsch war die Antwort aber imho keineswegs.
Insbesondere bei kleineren Anbieter kann es wie @greystone sagt natürlich passieren dass man, Vertrag hin oder her, einfach terminiert wird als Trotzreaktion, falsch war die Antwort aber imho keineswegs.
D
Deleted member 11740
Guest
Die Antwort ist cool.
Ehrlich gesagt, hätte ich den Anbieter gar nichts mehr mitgeteilt.
Er hätte meine Kündigung bekommen, nachdem alles umgezogen ist.
So kann man sich vor Trotzreaktionen den Anbieters schützen.
Ich hätte noch nicht einmal einen Grund angegeben.
Ehrlich gesagt, hätte ich den Anbieter gar nichts mehr mitgeteilt.
Er hätte meine Kündigung bekommen, nachdem alles umgezogen ist.
So kann man sich vor Trotzreaktionen den Anbieters schützen.
Ich hätte noch nicht einmal einen Grund angegeben.
Muenzenwert
New Member
Status:
Frist vom alten Provider das PHP 7.x Update ist gemacht oder er schaltet 18.5. 12 Uhr Server ab.
Mails: Hmmmmm sind nun eher noch unstimmiger und unfreundlicher..
PHP-Friends lobt er nicht so..
Neuer Server:
Leider immer noch Probleme mit .htaccess, bisher nicht verwendbar in der Installation - sollte aber heute laufen hoffe ich mal
PHP 7.x bisher keine Probleme mit den Scripten erkennbar... scheint Alles auch unter 7.X zu laufen.
Programme und DB sind am neuen Server, sobald .htaccess läuft (SEO freundliche URLs) und Domain übertragen ist sollte mein Problem gelöst sein.
(Um der Wahrheit die Ehre zu geben - ein paar Probleme hatte ich verursacht, paar Einstellungen am Server verstellt.. ich kann also bisher nichts Schlechtes von PHP Friends sagen..)
Frist vom alten Provider das PHP 7.x Update ist gemacht oder er schaltet 18.5. 12 Uhr Server ab.
Mails: Hmmmmm sind nun eher noch unstimmiger und unfreundlicher..
PHP-Friends lobt er nicht so..
Neuer Server:
Leider immer noch Probleme mit .htaccess, bisher nicht verwendbar in der Installation - sollte aber heute laufen hoffe ich mal
PHP 7.x bisher keine Probleme mit den Scripten erkennbar... scheint Alles auch unter 7.X zu laufen.
Programme und DB sind am neuen Server, sobald .htaccess läuft (SEO freundliche URLs) und Domain übertragen ist sollte mein Problem gelöst sein.
(Um der Wahrheit die Ehre zu geben - ein paar Probleme hatte ich verursacht, paar Einstellungen am Server verstellt.. ich kann also bisher nichts Schlechtes von PHP Friends sagen..)
nexus
Well-Known Member
Da wird es dir auch in Zukunft sehr schwer fallen, etwas Negatives zu finden...
Zumindest aus meiner persönlichen Erfahrung heraus gehört PHP-Friends zu den wenigen Hostern wirklich uneingeschränkt empfehlen kann.
d4f
Kaffee? Wo?
Was solle man auch erwarten, Lobgesang an die Konkurrenz?Grundlagen der Forschung: man kann nur gleiches mit gleichem vergleichen. Der genannte Test ist wohl der von webhosterwissen, 1awww ist darin aber nicht enthalten so dass man keine Ahnung haben kann wo er enden würde.
Allerdings ist es durchaus möglich dass der Anbieter tatsächlich 65MB/s ermöglicht. Was passiert wenn man diese Leistung auch benutzen willst.... siehe Anfang dieser Geschichte
Um realistisch zu bleiben, als Kunde findet man an jedem Anbieter etwas schlechtes oder etwas was besser sein könnte. Ob Wunsch, Realität und preis/Leistung vereinbar sind ist eine andere Frage. Ich behaupte mal dass man sich schlicht wohl bei einem Anbieter fühlen muss.
Also einen perfekten Hoster wird es sicherlich nicht geben. Denke allerdings, dass du den richtigen Schritt gemacht hast.
Das Thema Festplatten-Auslastung ist scheinbar immer noch nicht geklärt und eine PHP-Umstellung als Hoster zu erzwingen... Würde ja beinahe sagen: "Dann soll er dafür sorgen, dass nur die PHP-Versionen auf dem Server laufen, die er will, dann hat er so ein Problem nicht."
Habe auch meinen Server gewechselt, bin allerdings noch dabei meine Domains mit rüber zu holen, dies scheint allerdings etwas schwerer zu sein, was allerdings am alten Hoster liegt, denn der lässt sich scheinbar gerade besonders viel Zeit, obwohl die Kündigung für den Server bei dem Hoster noch nicht mal eingegangen ist.
Für dich ist ohnehin ja nur wichtig, dass dein Business so läuft, wie es laufen soll. Da ist so ein Hoster ohnehin nicht wirklich interessant, sondern nur ärgerlich.
Was das Thema "Lob für Konkurenz" betrifft, habe ich bei meinem alten Hoster allerdings schon etwas anders erlebt. Da gab es wirklich die Aussage: "Stimmt, da haben Sie mehr Leistung, allerdings zahlen sie dort auch mehr." (was dem Kunden ohnehin bewusst ist, dass mehr Leistung auch mehr kostet)
Das Thema Festplatten-Auslastung ist scheinbar immer noch nicht geklärt und eine PHP-Umstellung als Hoster zu erzwingen... Würde ja beinahe sagen: "Dann soll er dafür sorgen, dass nur die PHP-Versionen auf dem Server laufen, die er will, dann hat er so ein Problem nicht."
Habe auch meinen Server gewechselt, bin allerdings noch dabei meine Domains mit rüber zu holen, dies scheint allerdings etwas schwerer zu sein, was allerdings am alten Hoster liegt, denn der lässt sich scheinbar gerade besonders viel Zeit, obwohl die Kündigung für den Server bei dem Hoster noch nicht mal eingegangen ist.
Für dich ist ohnehin ja nur wichtig, dass dein Business so läuft, wie es laufen soll. Da ist so ein Hoster ohnehin nicht wirklich interessant, sondern nur ärgerlich.
Was das Thema "Lob für Konkurenz" betrifft, habe ich bei meinem alten Hoster allerdings schon etwas anders erlebt. Da gab es wirklich die Aussage: "Stimmt, da haben Sie mehr Leistung, allerdings zahlen sie dort auch mehr." (was dem Kunden ohnehin bewusst ist, dass mehr Leistung auch mehr kostet)
d4f
Kaffee? Wo?
Prozeduren bei Domaintransfers liegen oft ausserhalb der Hand des Anbieters. Bspw nehmen einige Domaingrossanbieter volle 5 Tage bei ICANN Domains (com,net,...) ohne dass man als Anbieter einen ACK vorher durchringen kann.
IP-Projects.de
Active Member
Muenzenwert
New Member
@Guter Service / Guter Provider
Ich sehe das recht einfach - ein Provider der weiß was er tut und Support-Anfragen freundlich und zeitnah bearbeitet ist ein guter Provider. Auch wenn der Provider nicht immer das Problem direkt lösen kann.
Z.B. meine .htaccess ging nicht bzw. wurden alle Anfragen zum alten Server geleitet obwohl ich die Rewrite Rule aus der .htaccess genommen hatte.
-> Support mail geschrieben
-> Antwort gleicher Tag: Liegt vermutlich am Browser, Beschreibung und Hinweise wie Browser Cache geleert werden kann
-> Nicht hilfreich da ich das schon gemacht hatte
-> Mail Provider
-> Support wieder nach paar Stunden geantwortet.. Einstellung Plesk falsch (war ich.. https verwenden)
-> Problem gelöst
Support wäre noch besser gewesen, wenn man Browser getestet hätte ob das die Lösung ist.
Support ist trotzdem gut, da zeitnah geantwortet, Problem gelöst, freundliche Mails... man hat halt erstmal eine Standardantwort gegeben die das Problem normalerweise löst.. -> ist und bleibt ein guter Support, Provider kümmert sich und versucht Problem zu lösen.
Status:
Projekt läuft am neuen Server inkl. Domain
An der Stelle nochmal ein Danke an PHP Friends
PHP 7.x Update
Erstaunlich wenig Probleme in den Skripten.. zwei Stellen Integer Wert nicht gut genug...
Mail vom Provider nach Domain Umzug:
Guten Tag Herr XXXXXXXX,
oh wie langsam doch Ihre Seiten geworden sind!
Sie wussten es ja besser und müssen nun selbst Ihre Erfahrungen machen!
Top20-Münzen und die Seite schläft ein! Ich bin mal gespannt, wann es zum kompletten Ausstieg kommt, weil ein paar Anfragen mehr eintrudeln!
Eigentlich wollte ich das Mail ignorieren, habe aber nun doch geantwortet:
Die Top 20 Seite war einmal ein internes Tool für mich, wurde nie optimiert und ich habe dieses Tool dann Usern zur Verfügung gestellt. Die Seite war auch auf ihren Server langsam.. wird ca. 2 mal am Tag aufgerufen.
Die eigentlichen Fragen sind:
1. Wie kann es sein, dass der Server immer noch funktioniert?
> Der von Ihnen neu ins Auge gefasste Provider, Ihre Mail vom 13.05.2019, schafft im Test nur 6,86 MB / sek und ist in der Leistung somit 10 fach langsamer als unsere Server!
-> Ein Server mit 6,86 MB / sek ist in der Lage meine Dauerlast von 100 MB / sek (bis zu 3-4 GB / Sekude laut ihrer Aussage) ohne Probleme zu schaffen.. der Server scheint zaubern zu können.
2. Wie kann es sein dass die Münzseiten nun immer noch schnell sind?
Münzseiten machen ca. 80% der Useranfragen aus.. (knapp 20000 am Tag)
Z.B. die Top Münze des Münzkatalogs (aus den Top 20) wird mit allen Preisen, Informationen, Charts, Bearbeitungslog, Verkaufstabelle usw. in 0.006 Sekunden am Server generiert!
Z.B. 1 DM der BRD, eine der Aufwendigsten Münzen mit ca. 6000 berechneten Durchschnittspreisen plus Charts usw. wird in 0.008 Sekunden am Server generiert!
www.muenzenwert.de
Wie kann das nur sein? - wenn nun die Festplatte sooooo langsam ist und meine Programme so schlecht und fehlerhaft erstellt wurden? SQL Anfragen schlecht sind?
3. Wie kann es sein, dass z.B. die Münzsuche nun schneller ist?
Auf dem neuen Server werden Suchanfragen in 0.05 bis 0.15 Sekunden beantwortet was ca. 50% schneller ist als vorher?
Suchanfragen machen ca. 10% der Useranfragen aus.
Wie kann dies nur sein? - wenn die Festplatten des Servers nur knapp 7 MB / Sekunde leisten können und meine Programme 100 MB / Sekunde verursachen?
Sehr verwunderlich... zumal am neuen Server nun noch kein DB Cache eingestellt wurde und nur 100KB zur Verfügung stehen - der DB Cache auf ihrem Server hatte 5GB Cache... sollte also DB Abfragen weit besser beantworten können.
By the way.. PHP 5 oder PHP 7 macht noch nicht einmal 1ms aus, CPU ist ca. mit 2% belastet bei PHP 5 und mit ca. 1.5% nun belastet bei PHP 7 -> das macht im Programmlauf der vor allem DB Abfragen generiert nichts aus.
Disk Belastung Problembehebung über PHP 7.x Update knapp daneben als Lösung.. hatte man aber nicht wissen können..
Ich sehe das recht einfach - ein Provider der weiß was er tut und Support-Anfragen freundlich und zeitnah bearbeitet ist ein guter Provider. Auch wenn der Provider nicht immer das Problem direkt lösen kann.
Z.B. meine .htaccess ging nicht bzw. wurden alle Anfragen zum alten Server geleitet obwohl ich die Rewrite Rule aus der .htaccess genommen hatte.
-> Support mail geschrieben
-> Antwort gleicher Tag: Liegt vermutlich am Browser, Beschreibung und Hinweise wie Browser Cache geleert werden kann
-> Nicht hilfreich da ich das schon gemacht hatte
-> Mail Provider
-> Support wieder nach paar Stunden geantwortet.. Einstellung Plesk falsch (war ich.. https verwenden)
-> Problem gelöst
Support wäre noch besser gewesen, wenn man Browser getestet hätte ob das die Lösung ist.
Support ist trotzdem gut, da zeitnah geantwortet, Problem gelöst, freundliche Mails... man hat halt erstmal eine Standardantwort gegeben die das Problem normalerweise löst.. -> ist und bleibt ein guter Support, Provider kümmert sich und versucht Problem zu lösen.
Status:
Projekt läuft am neuen Server inkl. Domain
An der Stelle nochmal ein Danke an PHP Friends
PHP 7.x Update
Erstaunlich wenig Probleme in den Skripten.. zwei Stellen Integer Wert nicht gut genug...
Mail vom Provider nach Domain Umzug:
Guten Tag Herr XXXXXXXX,
oh wie langsam doch Ihre Seiten geworden sind!
Sie wussten es ja besser und müssen nun selbst Ihre Erfahrungen machen!
Top20-Münzen und die Seite schläft ein! Ich bin mal gespannt, wann es zum kompletten Ausstieg kommt, weil ein paar Anfragen mehr eintrudeln!
Eigentlich wollte ich das Mail ignorieren, habe aber nun doch geantwortet:
Die Top 20 Seite war einmal ein internes Tool für mich, wurde nie optimiert und ich habe dieses Tool dann Usern zur Verfügung gestellt. Die Seite war auch auf ihren Server langsam.. wird ca. 2 mal am Tag aufgerufen.
Die eigentlichen Fragen sind:
1. Wie kann es sein, dass der Server immer noch funktioniert?
> Der von Ihnen neu ins Auge gefasste Provider, Ihre Mail vom 13.05.2019, schafft im Test nur 6,86 MB / sek und ist in der Leistung somit 10 fach langsamer als unsere Server!
-> Ein Server mit 6,86 MB / sek ist in der Lage meine Dauerlast von 100 MB / sek (bis zu 3-4 GB / Sekude laut ihrer Aussage) ohne Probleme zu schaffen.. der Server scheint zaubern zu können.
2. Wie kann es sein dass die Münzseiten nun immer noch schnell sind?
Münzseiten machen ca. 80% der Useranfragen aus.. (knapp 20000 am Tag)
Z.B. die Top Münze des Münzkatalogs (aus den Top 20) wird mit allen Preisen, Informationen, Charts, Bearbeitungslog, Verkaufstabelle usw. in 0.006 Sekunden am Server generiert!
Z.B. 1 DM der BRD, eine der Aufwendigsten Münzen mit ca. 6000 berechneten Durchschnittspreisen plus Charts usw. wird in 0.008 Sekunden am Server generiert!
1 DM Münze 1950-2001 BRD Jäger:385
Der Wert / Preis der Münze beträgt 1-4500 Euro (siehe Preis-Tabelle). Die Münze hat 23,5mm und ist 5,5g schwer - Mehr Infos? Einfach klicken!
3. Wie kann es sein, dass z.B. die Münzsuche nun schneller ist?
Auf dem neuen Server werden Suchanfragen in 0.05 bis 0.15 Sekunden beantwortet was ca. 50% schneller ist als vorher?
Suchanfragen machen ca. 10% der Useranfragen aus.
Wie kann dies nur sein? - wenn die Festplatten des Servers nur knapp 7 MB / Sekunde leisten können und meine Programme 100 MB / Sekunde verursachen?
Sehr verwunderlich... zumal am neuen Server nun noch kein DB Cache eingestellt wurde und nur 100KB zur Verfügung stehen - der DB Cache auf ihrem Server hatte 5GB Cache... sollte also DB Abfragen weit besser beantworten können.
By the way.. PHP 5 oder PHP 7 macht noch nicht einmal 1ms aus, CPU ist ca. mit 2% belastet bei PHP 5 und mit ca. 1.5% nun belastet bei PHP 7 -> das macht im Programmlauf der vor allem DB Abfragen generiert nichts aus.
Disk Belastung Problembehebung über PHP 7.x Update knapp daneben als Lösung.. hatte man aber nicht wissen können..
Last edited:
IP-Projects.de
Active Member
Vielleicht einfach mal die Festplatten Performance selbst testen.
dd if=/dev/zero of=/root/testfile bs=1G count=2 oflag=direct
dd if=/dev/zero of=/root/testfile bs=512 count=4000 oflag=direct
hdparm -tT --direct /dev/sda
Mal abgesehen davon ist es wie du sagst. Manche Seiten landen z.B. im Browser Cache oder Cache Systemen die man auf dem Server selbst einsetzt. Diese belasten dann den Server nicht mehr so stark I/O Seitig, da die westenliche Bearbeitung im RAM stattfindet.
Also die Ladezeit als Solches muss nicht primär nur vom Faktor Festplattengeschwindigkeit abhängig sein. Hier spielen mehr Faktoren eine Rolle wie z.B. auch der Content selbst, statisch dynamisch, ...
dd if=/dev/zero of=/root/testfile bs=1G count=2 oflag=direct
dd if=/dev/zero of=/root/testfile bs=512 count=4000 oflag=direct
hdparm -tT --direct /dev/sda
Mal abgesehen davon ist es wie du sagst. Manche Seiten landen z.B. im Browser Cache oder Cache Systemen die man auf dem Server selbst einsetzt. Diese belasten dann den Server nicht mehr so stark I/O Seitig, da die westenliche Bearbeitung im RAM stattfindet.
Also die Ladezeit als Solches muss nicht primär nur vom Faktor Festplattengeschwindigkeit abhängig sein. Hier spielen mehr Faktoren eine Rolle wie z.B. auch der Content selbst, statisch dynamisch, ...