Bugs mit Google Chrome behoben [W1-14]

[itgchris]

Apache ist bekannt dafür nicht der schnellste Webserver zu sein und etwas featureüberladen zu sein.

Totaler Quatsch.

Ja Apache ist langsamer im Umgang mit static files was aber eher an der asynchronous i/o liegt, als an allem anderen. jeder der sich mit apache beschäftigt weiß ihn zu konfigurieren. und dann spielt es keine rolle was man davor macht. ob nginx, HAProxy oder w/e.

und nein keep-alive macht das polling nicht angenehmer. und eine 10+ Mbit/s connection macht alles auch nicht besser. Page Loads werden nur um 5% besser wenn man eine Internet Verbindung von 5 Mbit/s auf 10 mbit/s erhöht. glücklicherweiße hat freewar keep-alive weshalb der round-trip hier deutlich verkleinert wird (syn, rwnd, cwnd, ack fällt weg). trotzdem ist ein socket, deutlich effizienter.

außerdem geht es hier auch darum das ein polling immer unnötigen load verursacht, weil es nicht interrupt gesteuert ist.

ist ja auch scheiß egal, wird wahrscehinlich nicht geändert, eher kriegen wir neue schwerter.

Es würde ja schon reichen wenn Sotrax nach und nach ne FreewarAPI baut womit man dann eigene Clients entwickeln kann. Falls man sich dafür bewirbt.

[bwoebi]

Richtig. Aber vergleiche doch vllt. mal einmal die Performance von Apache gegenüber einem selbst geschriebenen, nur auf die nötigen Elemente reduzierten Webserver. Bspw. wenn man das in PHP schreibt, hat man, liefert man damit ausschließlich PHP content aus, eher einen Geschwindigkeitsvorteil (alleine dadurch dass PHP keine RINIT und RSHUTDOWN bei jedem Request durchmachen muss).

das wichtige ist hier auch der ping bei kleinen Datenmengen, ja.

Man kann bei Polling eigentlich auch erst etwas schreiben wenn neue Daten vorhanden sind, und nicht wie in Fw jede Sekunde abbrechen.

[itgchris]

Richtig. Aber vergleiche doch vllt. mal einmal die Performance von Apache gegenüber einem selbst geschriebenen, nur auf die nötigen Elemente reduzierten Webserver. Bspw. wenn man das in PHP schreibt, hat man, liefert man damit ausschließlich PHP content aus, eher einen Geschwindigkeitsvorteil (alleine dadurch dass PHP keine RINIT und RSHUTDOWN bei jedem Request durchmachen muss).

das wichtige ist hier auch der ping bei kleinen Datenmengen, ja.

Man kann bei Polling eigentlich auch erst etwas schreiben wenn neue Daten vorhanden sind, und nicht wie in Fw jede Sekunde abbrechen.

Ich wette das du keinen Performanteren Webserver in PHP schreiben kannst, bzw. ich bezweifle das es keinen besseren Webserver für diverse Applikationen die mit fcgid, wsgi, etc. laufen als Apache gibt. Und nein nginx oder lighttpd oder cheroke sind nicht besser. Apache ist in dem gut, worin er gut ist. Dynamische Seiten ausliefern.
Nginx ist dafür gut wofür er geschaffen wurde, statischer Content.

Ist auch alles total egal.

[bwoebi]

Wie wäre es mit einem Event Loop in PHP? (libevent) Ist doch sehr performant… (nicht von mir), aber sehr interessantes Beispiel: https://github.com/rdlowrey/Amp

[Sotrax]

An sich gibt es derzeit eigentlich kein Performance-Problem bei der Auslieferung. Dazu kommt, dass auch Apache+PHP am allerwenigsten der Flaschenhals ist. Die meiste Rechenzeit und I/O Last kommt nur von der Datenbank.

Websockets sind definitiv ne schöne Sache, habe ja selbst bereits viel mit Websockets (und NodeJS) gemacht. PHP traue ich aber stabile Websockets noch nicht zu. Eine Mischung von NodeJS und PHP will ich gerade aber aus Gründen der Übersicht noch nicht.

Auch ist die Notwendigkeit da nicht so groß, das Polling funktioniert für FW ziemlich gut und braucht praktisch 0 Traffic und Last auf dem Apache.

Das Flackern im Chrome ist auch kein Speedproblem, es scheint ein Bug in Iframes/Frames zu sein und tritt nur da auf, ganz egal mit welchem Speed man da Seiten neulädt. Das Frames nicht mehr gut unterstützt werden, ist verständlich, da sie nicht mehr im HTML5 Standard sind. Das Iframes aber genauso Probleme haben ist eher unverständlich, da diese im Standard sind und sehr massiv verwendet werden (zwar meist für Online-Werbung, aber dennoch).

Ärgerlich ist vor Allem, dass ein JS Scrollen in einem Iframe dafür sorgt, dass alle Menüs geschlossen werden, die auch nicht im Iframe liegen. Ich muss da wohl noch einen Bug Report zu aufmachen, was dann helfen könnte, wenn möglichst viele im Bugtracker von Google bestätigen, dass sie diesen Bug auch haben. Meist erhöht das die Aufmerksamkeit.

Ich muss hier auch mal testen, ob es irgendeinen Workaround gibt, der sich schnell umsetzen lassen würde.

[bwoebi]

Also mit PHP und socket_select() kriege ich bis zu 200 sicher stabile WebSockets hin (also es können auch tausende Connections sein, aber nur so 200 sollten gleichzeitig senden).
Mit PHP und libevent konnte ich 5000 Connections, die auch noch alle gleichzeitig senden, verwalten.

Insofern man den RFC 6455 richtig implementiert gibt es da keine Probleme (gibt auch eine Reihe funktionnierender WebSocket-Implementierungen; man muss nur aufpassen, denn es gibt auch noch hybi-* Implementierungen, die jetzt nicht mehr funktionnieren usw.)

Auch wenn die iframes noch immer im Standard sind, so langsam würde ich auch davon weg gehen. Sonderlich beliebt sind die nicht außer eben für Werbung. Das ist nichts was ich jetzt von heute auf morgen ändern würde aber auf Dauer in einem bis zwei Jahre so fertig stellen....

[itgchris]

An sich gibt es derzeit eigentlich kein Performance-Problem bei der Auslieferung. Dazu kommt, dass auch Apache+PHP am allerwenigsten der Flaschenhals ist. Die meiste Rechenzeit und I/O Last kommt nur von der Datenbank.

Websockets sind definitiv ne schöne Sache, habe ja selbst bereits viel mit Websockets (und NodeJS) gemacht. PHP traue ich aber stabile Websockets noch nicht zu. Eine Mischung von NodeJS und PHP will ich gerade aber aus Gründen der Übersicht noch nicht.

Auch ist die Notwendigkeit da nicht so groß, das Polling funktioniert für FW ziemlich gut und braucht praktisch 0 Traffic und Last auf dem Apache.

Das Flackern im Chrome ist auch kein Speedproblem, es scheint ein Bug in Iframes/Frames zu sein und tritt nur da auf, ganz egal mit welchem Speed man da Seiten neulädt. Das Frames nicht mehr gut unterstützt werden, ist verständlich, da sie nicht mehr im HTML5 Standard sind. Das Iframes aber genauso Probleme haben ist eher unverständlich, da diese im Standard sind und sehr massiv verwendet werden (zwar meist für Online-Werbung, aber dennoch).

Ärgerlich ist vor Allem, dass ein JS Scrollen in einem Iframe dafür sorgt, dass alle Menüs geschlossen werden, die auch nicht im Iframe liegen. Ich muss da wohl noch einen Bug Report zu aufmachen, was dann helfen könnte, wenn möglichst viele im Bugtracker von Google bestätigen, dass sie diesen Bug auch haben. Meist erhöht das die Aufmerksamkeit.

Ich muss hier auch mal testen, ob es irgendeinen Workaround gibt, der sich schnell umsetzen lassen würde.

Du kannst den Chrome Entwickler schreiben und Ihnen einen dev account geben, ist zwar doof das es nur Deutsch ist, aber vielleicht nehmen Sie sich dem Problem an.
Sie lösen manchmal Probleme und erklären, was bei manchen Websites zu Problemen führt, wie z.b. blur effekte in CSS, etc.

[schaufelchen]

BUG -Meldung
Wenn ich in google chrome mit einer Zoomstufe > 100 % bei den afk Tätigkeiten das mega sinnfreie Anti-Bot Rätsel [hierfür unabhängig davon übrigens einen besonderen Dank...so einen Schwachsinn in Zeiten von Smartphones und Tablets einzubauen ] löse, zeigt es mir an, dass ich einen Fehler gemacht habe, obwohl es stimmt...mehrmals wiederholt und immer das gleiche...

[Sotrax]

@schaufelchen: Hmm, das kann sein, dass es da dann skalierungsprobleme gibt, das sollte man also auf 100% lösen.

Sinnlos ist das Rätsel allerdings nicht, es verhindert effektiv eben Bots. Ich meine ich könnte es auch rausnehmen wenn die Leute das so wollen, aber dann müsst ihr auch damit leben, dass es deutlich mehr Bots gibt. Eine bessere Lösung ist mir leider gerade nicht bekannt

[itgchris]

Implementiere doch einfach CSRF und CORS?
Damit machst du es Bots schonmal schwerer.

[Sotrax]

@itgchris: Naja, gegen Ingerium Bots würde das aber nix bringen.

Das ist halt immer das Problem, wenn man es den Bots schwerer macht, wird es auch für die Menschen schwerer, man muss da durchaus einen guten Mittelweg finden.

[itgchris]

Nun da ich Bots nicht kenne kann ich leider auch nicht viel dazu sagen.
Wenns so AutoIt Geschichten sind wirds schwer, aber in 90% aller fällen hilft ne gute Heuristik und Log Analyzing.

Und nach kurzem Googlen kann ich sagen, dass du einfach JavaScript/CSS Honeypots nehmen kannst, denn 90% aller Freewar Bots implementieren einen HTML Browser der nicht CSS und JavaScript kann.

[Caludoi]

Nun da ich Bots nicht kenne kann ich leider auch nicht viel dazu sagen.
Wenns so AutoIt Geschichten sind wirds schwer, aber in 90% aller fällen hilft ne gute Heuristik und Log Analyzing.

Pfft, auch AutoIt-Scripsts müßten da schon halbwegs gut konstruiert sein, damit sich keine zeitlichen Muster ergeben.

[Sotrax]

Wenn wir einen Verdacht haben ist es zum Glück ziemlich einfach einen Bot zu erkennen. Allerdings machen wir meist nur Stichproben, früher oder später fällt dann der Botuser aber auf. Aber auf jegliches Captcha zu verzichten würde es den Bots dann doch wieder sehr leicht machen.

[Cord]

Um das Problem mit den Menüs (bei mir fällt es hauptsächlich bei der Zauberkugel auf) könntest du doch einfach die Orte als Links untereinander ausgeben.