Hoster Webgo

[WG2000]

Bei mir besteht das Problem immer noch.
Wie ist die Situation bei den anderen betroffenen?

[mlweb]

Ich hab aus Zeitgründen bisher nur eins meiner Pakete getestet. Da war Imagick da. Alle anderen kommen demnächst dran. Sind nicht so besonders bildlastig, da ist die Hauptsache alles wird angezeigt egal ob gdlib oder imagemagick.

[tab]

Bei meinem eigenen Paket und dem Kundenpaket ist imagick jetzt in der Konsole wieder vorhanden.

[daSilva]

Bei mir besteht das Problem immer noch.
Wie ist die Situation bei den anderen betroffenen?

Das Problem wurde eigentlich auf allen angepassten Systemen durch einen Systemcheck aller Benutzer behoben.

Sollte das Problem bei dir weiterhin auftreten kann du mir gerne weitere Infos per PM zukommen lassen, ich schaue mir das dann einmal genauer an.

[WG2000]

Sites fuktionieren wieder.
Danke adSilva

[tblumrich]

Ich hatte das Problem auch nur kurz. Hatte kurz Kontakt mit dem Support und wurde sofort gefixt.

Aber kann es sein, das die Performance stark eingebrochen ist?
Ich kann den Manager quasi ohne Memory Fehler nicht mehr nutzen... das ging bis vor kurzen einwandfrei mit meinem Paket (Platin).

Error: "Out of memory (allocated 1046487040) (tried to allocate 4096 bytes)" in phar:///home/www/***/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/Solver.php on 220


mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory


Process terminated with exit code 255
Reason: Unknown error

Kommt quasi egal bei welcher Erweiterung. Der Manager-Check sagt alles i.O.

Hat da jemand ähnliche Erfahrungen?

[mlweb]

Ja die Erfahrung, dass bei einem Platin Paket plötzlich keine Updates mehr funktionieren habe ich auch gemacht. Dabei ist es egal ob Manager oder Konsole. Ich bin da schon seit einiger Zeit in Kontakt mit Webgo bisher aber leider noch ohne Ergebnis.

[tab]

Das wäre schade, passt allerdings irgendwie auch mit meiner Beobachtung zusammen, dass bereits seit längerer Zeit Googles durchschnittliche Ladezeiten für Seiten deutlich höher sind als ursprünglich. Circa 200ms mehr pro Seite. Hatte das ursprünglich auf die durchgeführte Umstellung auf https mit Let's Encrypt geschoben, weil das in etwa zeitgleich passiert war.

[daSilva]

Dies spiegelt sich leider nicht mit unseren Beobachtungen im Bezug auf die Ladezeit. Stichprobenartig konnten wir eine Verbesserung der Ladezeiten von bis zu 150% beobachten, in keinem Test gab es höhere Ladezeiten als vor dem Update. Wir haben ca. 200 Webseiten auf verschiedenen Servern getestet.

Ebenfalls ist apc/apcu hinzu gekommen, welches aktiviert ist und direkt verwendet werden kann.

Im Bezug auf das Memory Problem sind derzeit noch interne Tests nötig um definitiv sagen zu können woher das Problem kommt.

[tblumrich]

Ja die Erfahrung, dass bei einem Platin Paket plötzlich keine Updates mehr funktionieren habe ich auch gemacht. Dabei ist es egal ob Manager oder Konsole. Ich bin da schon seit einiger Zeit in Kontakt mit Webgo bisher aber leider noch ohne Ergebnis.

Das klingt nicht sehr erbaulich, leider.
Dabei war ich sehr zufrieden und am Überlegen dauerhaft bei WebGo anzusiedeln.

Gefühlt muss ich das von tab geschilderte auch bestätigen... seit geraumer Zeit gibts immer mal sehr verzögerte Antwortzeiten.

[tab]

Ich kann das Problem auch nicht eindeutig zuordnen. Sonst hätte ich schon länger mal nachgefragt. Es hat mit der jetzigen Änderung auch sicher nichts zu tun, denn die Änderung der Ladezeiten ist jetzt schon fast 3 Monate her. Es war eben auffällig, dass plötzlich statt Ladezeiten von meist unter 200ms in der Crawling-Statistik praktisch von einem Tag zum anderen 350-450ms angezeigt wurde und auch die dort angezeigte durchschnittliche Ladezeit entsprechend höher wurde. In etwa zu der Zeit habe ich aber ein Contao-Update gemacht und auch auf https umgestellt. Vielleicht liegt es ja daran - oder Google misst jetzt einfach irgendwie anders. Nachdem Google Pagespeed immer noch jenseits der 95 liegt, kann es eigentlich auch nicht so furchtbar schlimm sein. Deshalb habe ich da bisher nichts unternommen. Werde jetzt aber doch nochmals genauer in die Installationen reinschauen, ob ich dabei vielleicht irgendwas verbogen habe.

[mlweb]

Das klingt nicht sehr erbaulich, leider.

Ich habe für meine Kunden mehrfach Platinpakete im Einsatz. Das Problem tritt bei mir nur bei einem einzigen Paket auf. Insofern bin ich da noch relativ gelassen und arbeite im Moment mit lokalem Update und Übertragung der composer.lock. Der Aufwand dafür hält sich ja Gott sei Dank in Grenzen.

[tblumrich]

Ich habe für meine Kunden mehrfach Platinpakete im Einsatz. Das Problem tritt bei mir nur bei einem einzigen Paket auf. Insofern bin ich da noch relativ gelassen und arbeite im Moment mit lokalem Update und Übertragung der composer.lock. Der Aufwand dafür hält sich ja Gott sei Dank in Grenzen.

Kannst du mal kurz skizzieren, wie der Weg konkret aussieht oder gibts dafür irgendwo eine Anleitung oder was wissenswertes...? Lokal entwickle ich nämlich garnicht.
Das wäre vielleicht für brennende Upgrades eine Variante.

Danke!

PS: Die Konsole hat bei meinem Paket wohl scheinbar nur 5.6.30 als PHP Version. Kann das ein möglicher Grund sein?

[mlweb]

Kannst du mal kurz skizzieren, wie der Weg konkret aussieht oder gibts dafür irgendwo eine Anleitung oder was wissenswertes...? Lokal entwickle ich nämlich garnicht.

lokal arbeite ich mit XAMPP unter Windows 10. Da unter Windows der Manager noch nicht funktioniert läuft dort alles über die Konsole. Wie man bei wenig RAM dann alles auf den Server bekommt hat @Spooky einige Male erklärt u.a. in diesem Post

PS: Die Konsole hat bei meinem Paket wohl scheinbar nur 5.6.30 als PHP Version.

Ist mir bei den Platin-Paketen noch nicht untergekommen. Ich hatte immer auch 7.0 und 7.1 auf der Konsole und im Paket zur Verfügung.
Fakt ist dass der Speicherbedarf bei 5.6 höher ist.

[mlweb]

Hallo liebes Webgo-Team,
ich habe mir heute ein CMS Power zugelegt.

Gehe ich auf die Konsole steigen mir schon wieder leicht die Nackenhaare zu Berge. Egal ob ich PHP 7.1 oder 7.2 benutze, es kommt die Warnmeldung

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/readline.so' - /usr/lib/php/20160303/readline.so: undefined symbol: rl_on_new_line in Unknown on line 0

Ich dachte das sollte auf allen Paketen der Vergangenheit angehören.
Auch ein Zertifikats-Problem besteht dort scheinbar.
Eure Composer Version ist inzwischen so alt, dass ich damit nicht mehr arbeiten möchte, weil ich nicht weiß ob einige Probleme daher kommen. Eine aktuelle krieg ich aber nicht zu fassen.

wget https://getcomposer.org/download/1.6.3/composer.phar
--2018-02-13 14:09:03--  https://getcomposer.org/download/1.6.3/composer.phar
Resolving getcomposer.org (getcomposer.org)... 54.36.53.46, 2001:41d0:302:1100::8:104f
Connecting to getcomposer.org (getcomposer.org)|54.36.53.46|:443... connected.
ERROR: The certificate of 'getcomposer.org' is not trusted.
ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer.

Versuche ich es dann doch mit eurer composer-Version 1.4.2 habe ich natürlich erwartungsgemäß das Zertifikatsproblem:

PHP Warning:  PHP Startup: Unable to load dynamic library 'readline.so' (tried: /usr/lib/php/20170718/readline.so (/usr/lib/php/20170718/readline.so: undefined symbol: rl_on_new_line), /usr/lib/php/20170718/readline.so.so (/usr/lib/php/20170718/readline.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
 
 
  [Composer\Downloader\TransportException]
  The "https://packagist.org/packages.json" file could not be downloaded: SSL
   operation failed with code 1. OpenSSL Error messages:
  error:1416F086:SSL routines:tls_process_server_certificate:certificate veri
  fy failed
  Failed to enable crypto
  failed to open stream: operation failed
 
 
create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--no-install] [--ignore-platform-reqs] [--] [<package>] [<directory>] [<version>]

Ich bin etwas angesäuert.
Wie gesagt ich bin kein Entwickler und auch kein Serveradministrator. Normalerweise mag ich mich mit diesem Bereich nicht rumschlagen und mir fehlt dazu auch das nötige Wissen, sonst würde ich einen eigenen Server administrieren. Ihr zwingt mich allerdings derzeit gerade dazu mich viel intensiver mit der Problematik zu befassen, als das eigentlich bei einem Shared Hosting Paket erforderlich sein sollte
Gerade nach dem letzten Wirbel hier im Forum habe ich anderes erwartet.