Ankündigung

Einklappen
Keine Ankündigung bisher.

Dienstplan statt Dienste/Cronjobs?

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Zitat von tr0y Beitrag anzeigen
    Das was du suchst sind keine cronjobs, sondern ein deamon. Der "just-in-time" und "terminiert" Dinge tun kann. Sowas kannst du auch mit PHP bauen. Anbieten würde sich zur Prozess-Kommunikation ZeroMQ.
    Es wären schon welche gewesen, aber ich möchte keine zusätzlichen Tools benutzen, dann halt kleinere Brötchen backen... ist auch zur Zeit noch nicht so wichtig, da es zur Zeit 1 und 1/2 Aufgaben gäbe die auf diese Funktion zurückgreifen würden (1 wäre die temporären Ordner von Plugins leeren, das 1/2 wäre das anlegen/updaten von einem Suchindex).

    Es sei den Woltlab Community Framework hat eine andere Definition von Cronjobs meine ich schon Cronjobs, aber ich wüsste jetzt auch nicht ob die auf erweiterte Module in Linux/Apache setzen und diese als Voraussetzung nehmen. Also mit pcntl_fork würde ich evtl. weit genug kommen aber mir würde auch die Kontrolle im Interface z.B. fehlen oder zu umständlich ausfallen.

    Daher fällt mir die Definition selbst schwer, in Windows wäre es jedenfalls eine an Dienste angelehnte Infrastruktur. Da wir uns aber im Web befinden wird es halt eine ToDo Liste die halt beim Adminpanel sich bei Handlungsbedarf meldet und die als OneClick Lösung auch locker durchgehen kann.

    Ist halt momentan alles ziemlich komplex, hab etwas mit emscripten rumgebastelt und kompiliert, lerne auch immer dazu, aber es ändert auch nichts daran das ich mir damit was antue!

    Ich mag zwar viel gemacht haben, aber es hackt manchmal auch an den basics ^^

    Kommentar


    • #17
      Ist ja kein Beinbruch. Du kannst durchaus auch Deamons bauen ohne Stand-alone MessageQueue / MessageQueue-Extension. Du musst dann halt nur einen Weg finden wie A ( Webseite ) mit B ( Daemon ) kommunizieren kann.

      Cronjobs ist halt was, was auf jedem dritten "Fussel"-Webspace zur Verfügung steht. Daemons einrichten ( und starten ) kannst du nur über die shell.

      Überleg doch lieber wie du deine 1 1/2 Aufgaben umschiffst. Deine Plugin Temp-Dirs kannst du doch beispielsweise mit einer kleveren Cache-Lösung umgehen ( APC(u), Memcache(d), was-weiß-ich )..
      [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

      Kommentar


      • #18
        Hallo,

        also generell gibt es dafür mehrere Möglichkeiten (ja, ich weiß, ich antworte auf ein gelöstes Thema, möchte aber das auch noch einmal erwähnt haben):
        1. Einen weiteren Prozess starten, also eine PHP Datei mittels Prozess-Start-Befehl. Damit ist man auch außenvor von der max execution time. Denn das ist dann ein Systemprozess und keiner, der unterm Webserver läuft.
        2. Mittels Ajax-Calls. Ist aber denke für deine Problematik eher uninteressant, weil dafür immer ein Client verbunden sein muss und in dessen Browser irgendwas im Hintergrund laufen muss.
        3. Erstelle einen eigenen Dienst mit einer anderen Programmiersprache. Das geht leider mit PHP nicht, weil man damit keine richtigen Serverprogramme machen kann. Würde dir hier eher zu Java oder C# raten. Der Server muss im Endeffekt nur auf eingehende Nachrichten warten und pro eingehende Nachricht einen eigenen Thread starten, damit man auch mehrfach gleichzeitig darauf zugreifen kann. Dieser Server läuft dann als Dienst im Hintergrund und kann mittels Sockets von PHP aus angesprochen werden, um so z. B. Prozesse anzustoßen.

        In dieser Angelegenheit muss man selbst etwas kreativ werden, weil es mit PHP Bordmitteln keine Möglichkeit gibt, soetwas umzusetzen. PHP kann nunmal leider nicht ständig laufen und nur Scheduler Zeit beanspruchen, wenn auf einem ServerSocket eine neue Nachricht eingeht.


        MFG derwunner

        Kommentar


        • #19
          Warum sollte PHP das nicht können ?
          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

          Kommentar


          • #20
            Zitat von derwunner
            pro eingehende Nachricht einen eigenen Thread
            Auch wenn threads nicht so viel kosten wie Prozesse, ist das mit Kanonen auf Spatzen geschossen. Ich hab zwar keine Ahnung von Java oder C#, aber mit einem thread kriegste unter nodejs schon einen gewaltigen Durchsatz und du musst dich nicht um Nebenläufigkeit kümmern. Wenn threads, dann als Faustregel 1 Thread pro CPU, damit der Scheduler das auch sinnvoll verteilen kann. Und nicht ein thread pro Nachricht.

            Zitat von theredox
            Der Punkt dabei ist, keineswegs darf beim Client angezeigt werden das die Website weiter lädt, und die max_execution_time muss ebenfalls künstlich mit vom Server aus verlängert werden, so dass dieses Script in Ruhe die Arbeit verrichten kann.
            Insofern fallen include und so ein Kram flach da diese im Browser ein weiterer Ladevorgang sind.
            Für die Schmalspurlösung:
            http://php.net/manual/de/function.re...n-function.php
            http://php.net/manual/de/function.ignore-user-abort.php

            Ob du einen Daemon, einen Cronjob oder ein kleines shutdown-Script verwendest, hängt davon ab, wieviel Rechenleistung du brauchst, wie schnell dein System reagieren soll und wie lange die einzelnen Tasks laufen. Pauschal kann man das nicht beantworten.

            Daemon:
            + ständig verfügbar
            + schnelles Abarbeiten der Job-Queue
            + kein process locking notwendig
            - läuft immer, kostet Rechenleistung
            - läuft außerhalb deines Projekts => externe Abhängigkeit
            - kann Memory leaken
            - Deadlocks und co => aufwändigeres monitoring notwendig
            - muss überwacht werden und falls der Daemon stoppt, automatisch neu gestartet werden
            - init script notwendig

            Die letzten 2 Punkte sind dank systemd nicht mehr allzu tragisch.

            Cron:
            + einfach eingerichtet
            + memory leak nicht so tragisch, da Prozess nach Ausführung beendet und RAM freigegeben wird.
            + im Vgl. zum Daemon leichter zu handhaben/umzusetzen
            + wenn das Ausführungsintervall groß genug gewählt ist, musst du dich nicht/kaum ums process locking kümmern
            - Monitoring
            - läuft außerhalb deines Projekts => externe Abhängigkeit
            - arbeitet die Job Queue nur zu definierten Zeiten ab

            Shutdown-Skript:
            + sehr einfach zu handhaben
            + Code transparent im Projekt, nicht als externe Abhängigkeit
            + im Monitoring
            - nur verfügbar, wenn jemand die Seite aufruft
            - du musst dich ums process locking kümmern, um race conditions zu vermeiden, gerade, wenn du dateibasiert arbeitest
            - Nur bedingt geeignet, da die Ausführung nicht garantiert ist (ein exit im Code sorgt dafür, dass alle nachfolgenden, registrierten shutdown scripts nicht mehr ausgeführt werden)
            - Unerwarteter hook

            In den meisten Fällen genügt für periodische Aufgaben ein Cronjob. Um externe Projekt-Abhängigkeiten aufzulösen, würde ich - da du Debian benutzt - Aktualisierungen als deb-Paket einspielen, bspw. per fpm: https://www.digitalocean.com/communi...ltiple-formats
            Das ist auch ohne externe Abhängigkeiten sinnvoll (Transaktionssicherheit, einfachere Versionsverwaltung, einfacher Rollback, du kannst keine Dateien vergessen, ..). Kurz - dein Admin wirds dir danken.

            Viele Grüße


            Basti
            I like cooking my family and my pets.
            Use commas. Don't be a psycho.
            Blog - CoverflowJS

            Kommentar


            • #21
              Zitat von rudygotya Beitrag anzeigen
              Auch wenn threads nicht so viel kosten wie Prozesse, ist das mit Kanonen auf Spatzen geschossen. Ich hab zwar keine Ahnung von Java oder C#, aber mit einem thread kriegste unter nodejs schon einen gewaltigen Durchsatz und du musst dich nicht um Nebenläufigkeit kümmern. Wenn threads, dann als Faustregel 1 Thread pro CPU, damit der Scheduler das auch sinnvoll verteilen kann. Und nicht ein thread pro Nachricht.
              Wo hast Du denn das her? Ein Thread pro CPU ist völliger Blödsinn, dann wären wir ja wieder in der Steinzeit. Selbst der Windows Kernel hat schon mehr Threads als der CPU Kerne. Auch der Apache Webserver erstellt pro Seitenaufruf einen Thread (das heißt pro Client bzw. Ausführung). Threads sind auch nicht rechenintensiv. Sie brauchen auch null Scheduler Zeit, wenn Sie im wartenden/schlafenden Zustand sich befinden. Und das ist der Worker Thread eines Servers auf dem ServerSocket, wenn sich niemand verbindet. Also im Idealfall kommt dem Server nur Scheduler zu, wenn ein Client sich verbinden will.


              PS: Kann sein, dass ich PHP auch als Server Software Grundlage eignet. Wäre dann aber meines Wissens schon umständlich, oder? Schließlich ist ja PHP dafür ausgelegt, eine gewisse Zeit zu laufen um etwas abzuarbeiten und dann zu sterben oder etwa nicht?!

              Kommentar


              • #22
                Ok - aneinander vorbeigeredet. Ich dache, wir reden hier von unix und process forks (php pctnl_fork). Da habe ich mich auch echt schei** ausgedrückt. Das erzeugt jeweils einen neuen Subprozess, um exakter zu sein.
                I like cooking my family and my pets.
                Use commas. Don't be a psycho.
                Blog - CoverflowJS

                Kommentar


                • #23
                  öhm rudygotya, welcher Admin wirds mir denn danken? Momentan bin ich laut §5 TMG für alles zuständig

                  Meine Linuxkenntnisse reichen grade mal um mit copy und paste Anleitungen auf der Konsole zu erledigen 'Auf gut Glück' sozusagen... und ich muss sogar sagen, das ich ziemlich happy mit Plesk bin, auch wenns nicht umbedingt die beste Lösung ist.
                  Debian habe ich mir ausgesucht weil ich glaube das es von der Philosophie her die beste Distribution ist für den jeweiligen Zweck, Ubuntu LTS wäre zwar auch eine Option gewesen aber ich muss sagen mir hat nie gefallen was Canotical so anstellt, langsam oder sicher fällt es auch den anderen ja auch langsam auf. Auch wenn ich mit emscripten darauf angewiesen war in der VM Ubuntu laufen zu lassen... war schon ziemlich kritisch...

                  Wie soll ich das jetzt mit dem shutdown Script verstehen? Race conditions, hooks und ... process locking und angewiesen darauf das die Seite aufgerufen wird oO
                  Das es ausgeführt wird wenn ein jemand die Seite aufruft geht ja an sich schonmal in die Richtung die ich denke/gedacht hab.

                  Grüße theredox

                  Kommentar


                  • #24
                    Hm, naja, ich bin mit Ubuntu LTS sehr zufrieden. Natürlich ohne Plesk und dergleichen. Ich weiß nicht, ob das hier schon genannt wurde, aber MessageQueues sind in diesem Zusammenhang sinnvoll. Aber ich glaube, wenn es schon cronjobs nicht sein dürfen...
                    Standards - Best Practices - AwesomePHP - Guideline für WebApps

                    Kommentar

                    Lädt...
                    X