nicht angemeldet
Linuchs
Rolf B
Felix Riesterer
Rolf B
Rolf B
Rolf B
Moin,
immer wieder geht die Diskussion, wie man Aufbau und Auslieferung von Webseiten zeitlich optimieren kann.
Meine Aufteilung, die Daten umfangreicher Listen als CSV String innerhalb des HTML-Codes anzugeben, um die Liste per Javascript beim Client aufzubauen, wird hier im Forum stark kritisiert.
Wir tauschen Vermutungen aus, wie viel Zeit der Server benötigt, die Datenübertragung, das Erstellen und Anzeigen der Seite im Browser.
Wie wäre es, wenn wir die Zeiten mal messen, um alternative Programmierkonzepte vergleichen zu können?
Idee: Wir brauchen 5 Zeitpunkte, der Start kommt vom anfordernden Client
Zu 1: Der Anfrage ist die Uhrzeit des Clients mitzusenden Zu 5: Ist das window.addEventListener('DOMContentLoaded', function () {}) ?
Die Zeit zwischen 2 und 3 messe ich seit Jahren und zeige sie unten rechts auf der Webseite an. Die meisten haben 0,1... sec und was über über 5 sec geht, löst eine Meldung per Mail aus. Da muss gehandelt werden. Meistens ist das eine Attacke von dutzenden bis hunderten Anfragen zeitgleich.
Folgendes habe ich mir aus den wiederholten Diskussionen in diesem Forum und zu diesem Themenkreis bereits gemerkt:
Punkte 1, 4, 5:
Punkte 2, 3:
$_SERVER['REQUEST_TIME_FLOAT'] gibt Dir auf „modernen und geeigneten Systemen“ die Unix-Time bis zur Genauigkeit von Millisekunden. Du kannst am Ende des Skriptes diese Zeit von der aktuellen abziehen.
Vorteil: Du hast die Zeit für das Cachesuche (nach dem Skript), Linten, Parsen Interpretieren/Kompilieren mit drin.
Nachteil: Du hast die Zeit für die Cachesuche (nach dem/den kompilierten Skripten), Datei(e)n öffnen, linten, parsen, interpretieren/kompilieren mit drin.
microtime(), oder besser: (ab PHP 7.3) hrtime()
Hallo Linuchs,
um das zu tun, braucht man die gleiche Seite, mit den gleichen Daten, die auf unterschiedliche Art realisiert ist. Andernfalls kommen zu viele Nebeneffekte hinein.
Man muss es auch mit umfangreichen Datenmengen tun, andernfalls ist der Server so fix, dass die Unterschiede im Rauschen des Timers untergehen.
Sicherlich willst Du deine DB und deine Code nicht offenlegen. D.h. man muss sich überlegen, mit welchen öffentlichen Daten man den Test durchführen möchte.
Sodann:
Zu 1: Der Anfrage ist die Uhrzeit des Clients mitzusenden
Das auch, aber vor allem ist die Zeitdifferenz zwischen Client und Server zu bestimmen. Bzw. Client und Server müssen sich mittels NTP an der gleichen Quelle synchronisieren.
Die Differenz zwischen (1) und (2) ist aber eigentlich auch irrelevant. Dieser Teil wird (a) von der gewählten Programmstruktur nicht beeinflusst und dürfte auch nicht durch größere Datenmengen bestimmt werden; es ist nur ein URL Abruf.
- Beginn des Programms auf dem Server
- Ende des Programms auf dem Server (Datenübertragung beginnt)
Diese Identität ist nicht zwingend gegeben. Es ist im Allgemeinen eine gute Architektur, die Datenbeschaffung von der HTML Generierung zu trennen, aber das macht nicht jeder. Gerade, wenn man sehr viele Daten hat und viel HTML ausgibt, kann es der Performance nützen, die Daten zu streamen - also nicht erst alles lesen, sondern so früh wie möglich schreiben, was man hat. Die strukturelle Trennung von Datenbeschaffung und -aufbereitung lässt sich im Programm dann ggf. über Generatoren erreichen (yield-Funktionen). Natürlich geht das nicht immer. Wenn ich vor die Haupt-Datenmenge Informationen schreiben will, die erst nach Ermittlung dieser Datenmenge bekannt sind, muss ich wohl oder übel erstmal lesen.
Hinzu kommt der Effekt einer GZIP Kompression. Ist die eingeschaltet, sendet dein PHP Programm Daten und sie werden vom Server blockweise komprimiert
Letztlich interessiert einen Client
Ersteres kann man dem Netzwerk-Tab des Browsers entnehmen. Letzteres lässt sich über die Performance-Tools des Browsers bestimmen - oder man macht es so wie ich auf meiner Testseite: Man bringt das HTML ins DOM und schickt danach mit setTimeout(..., 0) ein Event in die Queue, um die Dauer der Layout-Phase zu messen.
Man müsste sich für einen validen Vergleich also erstmal einigen auf
Das Ergebnis könnte durchaus interessant sein, der Aufwand wird bei etlichen Wochen liegen. Insbesondere die Konzeptphase.
Rolf
Lieber Linuchs,
so lange nicht klar ist, was Dein PHP wirklich macht und wie Deine Programmarchitektur aufgebaut ist, reden wir hier wie Politiker - faktenbefreit.
Du hantierst mit einer Datenbank. Die Anbindung an den DB-Server und dessen Leistungsfähigkeit ist ebenso ein Thema, wenn man wirklich Fakten sammeln will. Auch die Art von Anfragen spielt eine große Rolle - und die Struktur der DB-Tabellen. Darüber ist hier nichts bekannt, auch nicht, was Deine Zeiten rein für die DB-Requests sind.
Wenn Du die CSV-Daten als gesonderte Datei bereit hältst, dann sind es schon einmal mindestens zwei HTTP-Requests (HTML und CSV), wenn JavaScript ausgelagert ist, dann drei. Dabei ist wohl nur das HTML und das JavaScript sinnvoll zu cachen, die CSV-Daten ändern sich wohl häufiger. Also auch hier die Frage: 1 großes Dokument vom Server mit nur einem HTTP-Request, oder mindestens zwei bis maximal drei Dateien mit mindestens zwei HTTP-Requests und anschließendem clientseitigem Dokument-Generieren?
Liebe Grüße
Felix Riesterer
Hallo Felix,
ich erinnere mich, wie wir vor Jahren über eine effiziente Geosuche diskutiert haben. Was daraus geworden ist, weiß ich nicht mehr.
Und da die OpenGeoDB nicht mehr verfügbar zu sein scheint, kann man da auch nicht so einfach eigene Tests starten; eine DB mit Orten, PLZ und Geokoordinaten zu finden scheint schwierig.
Update: eine lesbare Dokumentation der Spatial Features von MYSQL 8/MariaDB zu finden scheint auch schwierig. Nur Überschriften, keine Inhalte. Müll.
Rolf
Hallo Felix,
so, hab eine Geo-DB gefunden und egal wie blöd ich programmiere, eine Abfrage nach Abstand von PLZ-Koordinaten ist immer in 50ms durch.
Das müsste eigentlich der ärgste Performance-Killer sein. Eine 5s Laufzeit wird immer unerklärlicher.
Rolf
Hallo Felix,
so, hab eine Geo-DB gefunden und egal wie blöd ich programmiere, eine Abfrage nach Abstand von PLZ-Koordinaten ist immer in 50ms durch.
Alle Orte 50km um Überlingen: 206 Orte in 13.4 Millisekunden gefunden (Daten zur Tabelle gemacht, ..., e.t.c.) DB-Server im gleichen Netz. Wenn es mich packt teste ich das gerne auch auf einem Raspi...
ich erinnere mich, wie wir vor Jahren über eine effiziente Geosuche diskutiert haben.
Jepp! Mehrmals.
Was daraus geworden ist, weiß ich nicht mehr.
Ich bin dabei geblieben: Die PHP berechnet das Viereck → Datenbank sucht alle Orte im Viereck → PHP schmeisst alle raus, die nicht im Kreis liegen.
Es gab aber unterschiedliche Ideen. Die direkte Suche mit einem direkten fetten Select mit Sinus, Bruder Cosinus und und den Tangensschwestern ging am Fullscan zu Grunde, geblieben ist das Viereck als Select über die indexierten Spalten, in der fiktiven Ergebnistabelle die schwierige Kreissuche. Ich hab mein Zeug trotzdem nicht umgeschrieben.
Hallo Raketenwilli,
naja, ich hab gestern die freie PLZ/Ort/Koordinaten-Tabelle von Launix gefunden und die schreiben als Tipp, dass man einen Breitengrad mit 111,3km ansetzen kann und einen Längengrad mit 111,3km mal cos(breite). Das entspricht im Wesentlichen dem Erdumfang am Äquator entsprechend der aktuellen Referenzellipsoide (mit r=6378km). Nimmt man den Polradius von 6356km, kommt man auf 110,95km, d.h. der Längengradabstand 111,3km ist hierzulande um ein wenige hundert Meter zu groß. Angesichts der gegebenen Daten ist das irrelevant. Jedenfalls ist diese Rechnung einfacher als ein Orthodrome oder Entfernungsberechnungen auf dem Referenzellipsoid - bei letzterem müsste ich erstmal recherchieren, wie das überhaupt geht.
Damit hab ich dann einen inneren Select gemacht, um den Breiten- und Längenabstand zu Erftstadt zu bestimmen:
MudGuard
Der MartinSET @bmin = 50.7933968978061-25/111.3,
@bmax = 50.7933968978061+25/111.3;
SET @lmin = 6.76938350029545-25/111.3/COS(@bmax),
@lmax = 6.76938350029545+25/111.3/COS(@bmax);
SELECT (Breite - 50.7933968978061)*111.3 AS dy,
(Laenge - 6.76938350029545)*111.3*COS(50.7933968978061) AS dx,
Plz, Ort, Breite, Laenge
FROM koordinaten
WHERE @bmin <= Breite AND Breite <= @bmax
AND @lmin <= Laenge AND Laenge <= @lmax
Die Einschränkung über @bmin & Co liefert ein Hüllentrapez - kein Rechteck. Wegen der Einschränkung über Längengrade ist der Abstand am Südrand etwas größer. Aber das ist ok so.
Und mit diesem SELECT hab ich dann die Distanzabfrage gefüttert:
SELECT Plz, Ort
FROM (
SELECT (Breite - @breite)*@distbreite AS dy,
(Laenge - @laenge)*@distlaenge AS dx,
Plz, Ort, Breite, Laenge
FROM koordinaten
WHERE @bmin <= Breite AND Breite <= @bmax
AND @lmin <= Laenge AND Laenge <= @lmax
) k
WHERE dx*dx+dy*dy < 25*25;
Einen Index auf Breite, Länge hab ich auch noch gesetzt, damit er das Hüllentrapez per Index-Scan anwenden kann. Eine Approximation ist es immer noch, weil @distlaenge auf die Breite des Suchortes bezogen ist. Aber wenn der Abstand nicht zu groß wird, ist das tolerierbar, finde ich.
Ohne das Hüllentrapez lief die Query in drei Ticks, mit Rechteck in einem Tick. Ein Tick ist 1/60s - genauer zeigt mir HeidiSQL das nicht an. Der Index auf BREITE/LAENGE war aber durchaus wichtig, ohne den brachte das Hüllentrapez kaum eine merkliche Beschleunigung.
Achso - die Laufzeit war deshalb im Bereich 50ms, weil ich die PLZ-Tabelle achtmal importiert habe und damit 66000 statt 8200 Zeilen durchsuche. Andernfalls wären meine Laufzeiten zu klein gewesen, um sie zu messen 🤣
Rolf
Achso - die Laufzeit war deshalb im Bereich 50ms, weil ich die PLZ-Tabelle achtmal importiert habe und damit 66000 statt 8200 Zeilen durchsuche.
Oi.
Hallo Raketenwilli,
wow, ganz schöne Unterschiede zu meiner PLZ basierenden DB. Erftstadt - Bornheim, bei mit 13km, bei Dir 17km. Beide Orte haben nur eine PLZ, Orts- und PLZ-Zentrum sollten also identisch sein.
Bei mir:
Bornheim = (50.7687033234414, 6,95590015065646) = (50°46'7.3", 6°57'21,2")
Erftstadt = (50.7933968978061, 6,76938350029545) = (50°47'36.2", 6°46'9.8')
Bei Dir:
Bornheim = ( 50.7666667, 7) = (50°46', 7°0')
Erftstadt = ( 50.8166667, 6.7666667) = (50°49', 6°46')
Dass deine Werte auf Bogenminuten gerundet sind, ist ziemlich egal. Das sind max. 900m und die Städte sind viel größer.
Die Abweichung von 2,8 Winkelminuten bei der Länge von Bornheim machen aber über 5km aus. Wikipedia nennt (50.763611°, 6.984722°) als WGS84 Koordinaten - aber für Bornheim, nicht für die PLZ 53332. Bei Bornheim ist's egal, aber in Berlin…
Ob eine PLZ- oder Ortszentrumbasierende Rechnung sinnvoller ist, ist dann ebenfalls noch eine Frage des Anwendungsfalls.
Fun-Aspect: Auf suche-postleitzahl.de bekommt man dann per Umkreissuche die Entfernung Erftstadt-Bornheim mit 5,9km und Bornheim-Erftstadt mit 7,9km genannt und per Abstandsberechnung sind's 1km. Vermutlich alles nicht falsch - vom Zentrum Bornheim zur nächsten Ecke von Erftstadt ist die Distanz sicherlich anders als vom Zentrum Erftstadt zur nächsten Ecke von Bornheim; und in der Gegend vom Phantasialand sind Erftstadt und Bornheim ziemlich dicht beieinander.
Rolf
wow, ganz schöne Unterschiede zu meiner PLZ basierenden DB. Erftstadt - Bornheim, bei mit 13km, bei Dir 17km. Beide Orte haben nur eine PLZ, Orts- und PLZ-Zentrum sollten also identisch sein.
Ja. „Meine“ Datenbank ist ein Auszug aus der alten OpenGeoDB. Die Angaben sind oft merkwürdig, auch weil die Daten von Freiwilligen (teils mit GPS, teils aus Drittquellen) zusammen getragen wurden, welche - damals war das OK denn es gab auch keine genauen Vorgaben - manchmal sehr willkürlich festgelegt haben, was und wo der „Ortsmittelpunkt“ sei. Wir dürfen nicht vergessen, dass solches Wissen damals (z.b. von der DPAG) wie „Gold“ be- und gehandelt wurde. Aber auch kommerzielle Datenbanken gingen aufgrund ähnlicher Kritikpunkte „den Bach runter“.
Vermutlich alles nicht falsch - vom Zentrum Bornheim zur nächsten Ecke von Erftstadt ist die Distanz sicherlich anders als vom Zentrum Erftstadt zur nächsten Ecke von Bornheim; und in der Gegend vom Phantasialand sind Erftstadt und Bornheim ziemlich dicht beieinander.
Ja. Nicht ohne Grund nimmt man heutzutage etwas wie OpenStreetMap und visialisiert die Gegend mitsamst Verkehrswegen (denken wir an Orte am Rhein, in Hochgebirgen und die „von Brücken befreite“ A45) anstatt die Ergebnisse von Umkreissuchen zu listen. Es gibt ja genug Orte, die liegen kaum 5km von einander entfernt, will man aber von „A“ nach „B“ muss man entweder 50km fahren, Schwimmer oder Bergsteiger sein. Jedenfalls bis die Drohne kommt und uns einfach abholt…
Hallo Rolf,
vom Zentrum Bornheim zur nächsten Ecke von Erftstadt
Bei der Umkreissuche (remso.eu) ermittle ich den Abstand zwischen den Zentren von PLZ/Ortsname. Leider fallen dabei Events raus, die näher dran sind.
Seit Jahren kann man auch die Koordinaten der Treffpunkte speichern, die dienen z.Z. aber nur für die Landkarte.
Das war mal vollkommen anders gedacht, nämlich der Abstand vom User (GPS) bis zu den nächsten Events. Wenn ich mein Bier beim Marktplatz-Cefè ausgetrunken und bezahlt habe, möchte ich wissen, wo und wann die nächsten Events sind.
Aha, in 150m und 35 min eine Stadtführung.
Aber so dicht kamen die Meldungen für Events nie herein, obwohl ein Veranstalter gleichartige Events blitzschnell kopieren kann mit neuem Datum und neuer Uhrzeit.
Hi,
Das war mal vollkommen anders gedacht, nämlich der Abstand vom User (GPS) bis zu den nächsten Events.
Wobei da Luftlinie auch nix sagt. Auf einer Radltour hatte ich mich von Google-Maps zum Quartier leiten lassen.
An der Stelle, wo Maps meinte, daß ich das Ziel erreicht hätte, stand ich auch praktisch auf der Grundstücksgrenze.
Dumm nur, daß der nächste Schritt mich zwar über das Grundstück gebracht hätte, aber halt leider ca. 50m über dem Grund …
3km Fahrstrecke weiter hab ich das Hotel dann auch auf der richtigen Höhe erreicht …
Aber nicht nur Höhenstufen, auch andere Hindernisse können die zurückzulegende Strecke deutlich länger als die Luftlinien-Entfernung machen (Flüsse kann man ja nicht an jeder Stelle queren und ähnliches)
cu,
Andreas a/k/a MudGuard
deutlich länger als die Luftlinien-Entfernung
Das ist klar. Die Luftlinie ist eindeutig, die zurückzulegende Strecke hängt ab vom Geh- oder Fahrzeug. Mit dem Rollator über die Autobahn würde ich nicht empfehlen.
Bei mir sind jede Menge Hindernisse auf der Luftlinie. Nicht nur Flüsse, Eisen- und Autobahnen, auch Serpentinen im Bergland.
Wenn es eine einfache Lösung gibt, nur her damit.
Linuchs
Hallo,
Wobei da Luftlinie auch nix sagt. Auf einer Radltour hatte ich mich von Google-Maps zum Quartier leiten lassen.
An der Stelle, wo Maps meinte, daß ich das Ziel erreicht hätte, stand ich auch praktisch auf der Grundstücksgrenze.
Dumm nur, daß der nächste Schritt mich zwar über das Grundstück gebracht hätte, aber halt leider ca. 50m über dem Grund …
kenne ich auch - oder Google Maps schickt mich schnurstracks durch ein Firmengelände, wo aber am Tor steht "Zutritt für Unbefugte verboten". Ich unterstelle mal, dass Zutritt in diesem Kontext auch die Zufahrt/Durchfahrt einschließen soll.
3km Fahrstrecke weiter hab ich das Hotel dann auch auf der richtigen Höhe erreicht …
Meine Eltern hatten ein ähnliches Erlebnis mal in den Niederlanden. Diesmal nicht mit Google Maps, sondern mit einem reinen Navi-Gerät. Das Navi hat sie direkt bis zur Rückseite des Hotels geführt. Zwischen ihnen und dem Hotel lag dann aber noch ein Kanal. 😉
Aber nicht nur Höhenstufen, auch andere Hindernisse können die zurückzulegende Strecke deutlich länger als die Luftlinien-Entfernung machen (Flüsse kann man ja nicht an jeder Stelle queren und ähnliches)
Genau. Meine eigene Erfahrung ist auch, dass Google Maps gerade für Radfahrer und Fußgänger nicht gut funktioniert. Allein hier in Weinstadt kenne ich drei Stellen, an denen OSM "weiß", dass es einen Fußgängersteg über den Bach gibt (der auch noch für Radfahrer nutzbar ist), während Google meint, man müsse mehrere 100m Umweg machen.
Einen schönen Tag noch
Martin
und die schreiben als Tipp, dass man einen Breitengrad mit 111,3km ansetzen kann und einen Längengrad mit 111,3km ... zu groß
Warum auch nicht? Man sollte die Aufgabe („kleine“ Umkreise, Ungenauigkeiten sind „lässlich“) im Auge behalten.
So liefert das bei jeder 5. Abfrage im ersten, bewusst ungenauen Select vielleicht mal einen Ort zu viel, der im zweiten wieder „mit Mathe“ ausgesiebt wird.
Das kostet über eine „Mehrheit“ von Abfragen hinweg betrachtet weniger Rechenleistung als vorher das Trapez zu berechnen.
So ein Computer ist eigentlich „sackdoof“ - kann aber schnell rechnen. Der Mensch ist den Dingern haushoch überlegen, weil oder soweit er mit Unschärfen und Ungenauigkeiten gut umgehen kann. „Mathelehrer“ machen diesen Vorteil oft zu nichte weil die in unangemessen Situationen einen Fehler in Nachkommastellen rügen, die - von der Aufgabe her betrachtet - „keine Sau interessiert“.
Die PHP berechnet das Viereck → Datenbank sucht alle Orte im Viereck → PHP schmeisst alle raus, die nicht im Kreis liegen.
Jaja, eine Idee der Flacherdler. Ist die auf der Kugel (einigermaßen) überall korrekt?
Jaja, eine Idee der Flacherdler. Ist die auf der Kugel (einigermaßen) überall korrekt?
Bedeckt Deutschland die ganze Kugel? Scheißt der Bär ins Damenklo? Ist der Papst Pole? Im Hinblick darauf, dass die Erde sowieso sehr viel mehr eine „Kartoffel“ als eine „Kugel“ ist wirken sich sogar Höhenunterschiede zwischen zwei nahe gelegenen Orten (bis 100km ist das so: ~1 Grad Krümmung) stärker auf die tatsächliche Entfernung aus als die Erdkrümmung.
Wie schon gesagt: Man sollte die Aufgabe („kleine“ Umkreise, Ungenauigkeiten sind „lässlich“) im Auge behalten.
Oder mal Dir einen Kreis, messe zwei Punkte auf dem Radius mit 1 Grad Abstand aus und dann die Entfernung einmal gerade und einmal dem Radius folgend aus. Tipp: Mach einen großen Kreis, damit mit Deinen Messmitteln überhaupt ein Unterschied erkennbar wird. In Schritt zwei male viele kleine Hügel auf den Radius, die im Verhältnis so 100 bis 600 Höhenmetern und im Anstieg dem Schnitt klassischen Hügel, Berge oder Flusstälern entsprechen. Messe jetzt entlang der gemalten Linie.
Überlege ob Huckel oder die Krümmung von 1 Grad mehr Einfluss auf das Ergebnis haben.
Aufgaben:
Diskutiere die Erkenntnisse aus der Höhenline (unter der Karte) dieser Wegleitung:
Bedeckt Deutschland die ganze Kugel?
Ach so, diese Einschränkung muss ich überlesen haben. Ich lasse die Entfernung Luftlinie auf den Großkreisen berechnen. Sieht kompliziert aus, die gewünschten Orte im vorgegebenen Umkreis sind aber bei 8950 Datensätzen in Millisekunden gefunden:
WHERE ROUND( 6366.19773095 * ACOS( SIN(".$rad_lat1.") *SIN(RADIANS(ort1.geo_breite)) +COS(".$rad_lat1.") *COS(RADIANS(ort1.geo_breite)) *COS(RADIANS(ort1.geo_laenge) -".$rad_lon1." ))) <= '".$arr_in['KM']."'
Bedeckt Deutschland die ganze Kugel? Ach so, diese Einschränkung muss ich überlesen haben. bei 8950 Datensätzen
Also wenn jemand eine „Umkreissuche“ in 8950 Datensätzen macht um zu wissen, welches Chorauftritt man nach einem Bierchen im Marktcafe noch fußläufig erreichen kann, dann liegt es wohl „sehr nahe“, dass er am Nordpol ist und ein Ereignis in ~18500 Km Entfernung sucht (Auftritt des lokalen Eisbären-Chors zum Sommerfest am 21.6. am Südpool…)
Wie witzig ist es eigentlich, für den Radius hoch genaue „6366.19773095“ (In Worten: „6366 Kilometer, 197 Meter, 73 cm und 9,5 Millimeter“) km anzunehmen und die Höhenlage der Orte zu ignorieren, also dieser „hoch genauen, aber leider für wohl keinen einzigen Ort zutreffenden“ Zahl zu rechnen - gleichzeitig andere wegen deren Modellierung als „Flacherdler“ herabzuwürdigen?
Manchmal ist es schwer, derart „widerpruchsfreie Intelligenz“ zu ertragen. Oder sucht hier jemand Streit?
Oder sucht hier jemand Streit?
Was soll das?
Irgendwie ist diese Diskussion vollkommrn daneben unter dieser Faden-Überschrift. Die Umkreissuche macht Millisekunden aus und ist nicht verantwortlich für einen Programmdurchlauf > 5 min
Oder sucht hier jemand Streit?
Was soll das?
Was sollte denn Deine Äußerung „Idee der Flacherdler“, wenn Dein, bis auf den Bruchteil von Millimetern genau gerechnetes Kugelmodell doch eben so wenig zutrifft, und eigene Unschärfen hat, die zwingend zu Fehlern führen?
Hallo,
Die PHP berechnet das Viereck → Datenbank sucht alle Orte im Viereck → PHP schmeisst alle raus, die nicht im Kreis liegen.
Jaja, eine Idee der Flacherdler. Ist die auf der Kugel (einigermaßen) überall korrekt?
hinreichend korrekt, solange du den "Umkreis" klein hältst (wenige 100km) und polnahe Regionen nicht betrachtest.
Einen schönen Tag noch
Martin
Hallo Rolf,
Eine 5s Laufzeit wird immer unerklärlicher.
Einen Grund habe ich erklärt / vermutet: Zu viele Anfragen gleichzeitig. Scheinbar werden viele (alle?) PHPs gestartet und die Startzeit notiert.
Zweiter Grund: Beim falschen Login ist eine Pause programmiert.
Scheinbar werden viele (alle?) PHPs gestartet und die Startzeit notiert.
Man kann das aber feststellen, in dem man mal schaut, „wer“ aus „welchem Anlass“ “was“ und „wo“ notiert und muss sich also nicht auf dumpfe Vermutungen einlassen. Sonst war es am Ende Bill Gates, der mit PHP halt nur überhaupt nichts zu tun hat.