Verzögerung bei API-Calls nach exakt 2 Minuten
vor einem Jahr
Hallo,
ich arbeite gerade an einer Lösung, bei der ich alle 1-2 Sekunden auf dem Server nachfrage, welchen Zustand ein bestimmtes System hat. Die Rechnerei auf dem Server selbst (PHP-Script) ist marginal. Und die Information, die zurück kommt, ist auch nicht groß (ca. 2 - max. 2000 Bytes) aber meiste Zeit wird nur 0 zurückgegeben, weil in der Regel keine Updates vorliegen.
Mein Problem:
Das funktioniert einwandfrei auf meinem lokalen Test-Server (ebenfalls Apache). Aber bei Telekom-Webhosting wird exakt nach 2 Minuten ein "Throttling" gestartet, was bedeutet, dass die API-Calls ab der 2. Minute verzögert werden. Ich habe eine Zeitmessung implementiert und erhalte in der Regel nach 145 ms eine Antwort. Aber der Ablauf nach der 2. Minute ist wie folgt:
. . .
109. Anfrage = 144 ms
110. Anfrage = 146 ms
111. Anfrage = 142 ms
112. Anfrage = 1012 ms ------> Ab hier gehts los, jede Anfrage
112. Anfrage = 1985 ms ------> dauert immer länger
113. Anfrage = 2780 ms
114. Anfrage = 4131 ms
115. Anfrage = 6338 ms
...
Das geht dann so weiter, bis der Api-Call sogar über 15 Sekunden dauert und ein Time-Out-Error folgt.
Hat da jemand Erfahrung, ob es Alternativen gibt? Ist da ein übereifriger Telekom-IT-Mann drangewesen, der es zu gut gemeint hat? Weil Hacker-Angriffe sehen anders aus. Ich meine, würde ich den Telekom-Server überlasten wollten, dann gäbe es Wege andere Wege.
Oder muss ich da etwas in meiner httpd.conf Datei beachten?
215
0
15
Das könnte Ihnen auch weiterhelfen
vor 12 Jahren
18281
0
8
41434
0
5
124
0
3
617
0
7
vor 2 Jahren
331
0
7
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.

Angebote anzeigen
Informieren Sie sich über unsere aktuellen Website-Angebote.

vor einem Jahr
Ganz ohne Kenntnis des Hintergrunds, frage ich mich eher, warum der Server den Zustandswechsel des überwachten Systems nicht deinem Client meldet. Sekündliches Nachfragen scheint mir "schräg".
0
14
von
vor 17 Stunden
Hallo @Rocrail,
ich habe deine neuen Informationen bei unserer Anfrage an den Fachbereich ergänzt - sobald wir von dort eine Rückmeldung mit möglichen nächsten Schritten vorliegen haben, melden wir uns bei dir.
Hab noch einen schönen Sonntag!
Lieben Gruß aus Kiel
^Daniela T.
0
von
vor 16 Stunden
@Rocrail , erst einmal ein herzliches Beileid für dein Problem. Es ist schon schlimm, dass man im Jahre 2026 die einfachsten Dinge nicht lösen oder zumindest verstehen kann. Die Menschheit entwickelt sich zurück. Je mehr Technologie sie hat, umso weniger weiß sie, wie es wirklich funktioniert. Jeder munkelt nur was vor sich her aber keiner blickt richtig durch.
Erst einmal, du hast zur Antwort von DMSE geschrieben, nicht direkt auf meine Frage. Eigentlich müsste ER sich angesprochen fühlen. Aber dieses Forum ist auch nicht gerade das Beste. Telekom generell hat keine schönen Tools. Die sind eher auf Business-Lösungen spezialisiert, statt auf den kleinen Kunden. Du musst dir selber helfen. Aber hier irgend ein Beispiel zu nehmen zur Diskussion, das mit deinem Problem nur 1% zu tun hat, klingt schon sehr verzweifelt. Dieser Thread dreht sich um etwas ganz Anderes.
Und damit wären wir schon bei meinem Punkt. Telekom hat scheinbar gerade nicht die passenden Leute, um solche Probleme zu lösen. Und die haben es auch nicht gelöst. Scheinbar haben die keinen Programmierer, der den Server so konfigurieren kann, dass man Hacker-Angriffe/nervige Bots abwehrt, ohne den Otto-Normal-Kunden einzuschränken. Es ist scheinbar deren bewusste Ideologie, solche Mechanismen einzubauen, die Angriffe/Missbrauch erschweren sollen. An einer Alternative arbeiten die nicht. Muss man respektieren.
Um deine Frage zu beantworten. Ich bin zu Strato. Das hat funktioniert und tut es immer noch. Dass es bei dir auch bei Strato zu Problemen geführt hat, sollte dir zu denken geben. Und ein paar Denkhinweisen gebe ich dir, weil mehr kann ich dazu nicht sagen:
Mit deiner Wiki-Seite ladest du Bots/Hacker förmlich ein. Hacker sind meist auch keine einfachen Leute. Das kann Konkurrenz sein oder User, die dich nicht ausstehen können. Die Liste an Feinden ist lang, wenn man halbwegs etwas Ordentliches gebastelt hat. Und wenn ich "Ordentlich" schreibe, dann betone ich das auch bewusst, weil du musst zuerst vor deiner eigenen Haustür kehren: Wenn du selbst schon sagst, dass du tausende Session Files auf deinem Root hast, dann gibst du dir ja schon selbst die Antwort. Strato ignoriert das eine Zeit lang aber Telekom scheint damit gleich ein Problem zu haben. Deine Wiki-Seite erstellt wahrscheinlich viel zu früh Session-Objekte. Da PHP für jede Sessions eine Session-Datei anlegt, wäre das dann bei Millionen Aufrufen (Hacker/Bots) pro Tag ergo Million von Session Files. Kannst du dir wenigstens ein wenig vorstellen, wie schwierig das für ein System ist, so viele Files zu handeln?
Der Garbage-Collector von Telekom könnte der Grund sein, dass es bei Strato schneller gelaufen ist. Telekom lässt den "Müll" bewußt auf der Platte und überlässt dir die Arbeit (von der du scheinbar nichts weißt). Und dieser "Müll", den deine Seite hinterlässt ist wahrscheinlich der Grund warum es bei Telekom immer langsamer wird und warum Strato dich rausgeworfen hat. Also nochmal: Kehr vor deiner Haustür. Schau, dass du nicht so schnell Sessions erzeugst. Vielleicht ist es nicht das Problem. Aber bei der Info die du gibst, ist es für mich das Plausibelste. Viel Glück.
0
von
vor 15 Stunden
Hallo,
danke für dein Kommentar.
Strato kann man nur Telefonisch erreichen und wenn man dann drei Personen gesprochen hat dat gibt es keine Lösung sondern nur 3 Ahnungslose Meinungen, und blockieren bis Heute kommentarlos mein WEB Auftritt.
Ahnungslose Kunden werden auch bei Strato für Hacker und MetaBots nicht geschützt, höchstens blockiert.
Der Telekom bittet ein Forum, Email und Telefon Support, und bis jetzt bin ich damit sehr zufrieden und fühle mich wie eine Kunde behandelt. (Bei Strato fühle ich mich überflüßig und bekomme da auch Bemerkungen wie "Was erwarten sie für 5 Euro im Monat?"...)
DokuWiki, was mein WEB Auftritt umsetzt, ist ein einfaches PHP Projekt was ständig gewartet wird, und benutze es schon sehr lange.
Ob der IONOS Webserver von Telekom verantwortlich ist für diese temp/sess_* Dateien oder DokuWiki, das weiß ich nicht.
Naja, warten wir mal ab wie es weiter geht.
Nochmals ein Provider Wechsel kommt nicht im Frage.
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von