Prodej brandové domény světové značky Fred Perry
Zobrazují se odpovědi 1 až 25 z 25

Naplanovanie cronu cez php

  1. Cawko, neviete poradit ako cez php vytvorit a naplanovat cron job?

  2. Co se právě děje na Webtrhu?
  3. Cron se nedělá v PHP. Cron je server funkce = server se stará o spouštění. Ty v cronu nastavíš cestu k souboru / URL, na kterou server pustit request a jee to. Otázka je, co máš za hosting / server.

    Někde máš rozhraní, někde consoli.

  4. ale ja ho potrebujem vytvorit cez php napriklad cez exec

  5. to ale nelze, musí to podporovat server, tj. musí být cron daemon zapnutý a ty jako uživatel musíš mít přístup ke konfiguraci, vzhledem k tomu, že celé php běží pod jedním systémovým uživatelem, tak ve výchozím nastavení není možné přidávat crony.

    Poptej se hostingu, řada z nich má ve své administraci funkci na plánování cronů. Nebo to udělej nepřímo, vytvoř si v php url, která bude vykonávat tebou žádanou akci, kterou má dělat cron a tuhle url se přes nějakou jinou aplikaci provolávej. Můžeš to nechat provolávat třeba i několikrát za minutu a až v php s pomocí databázi si zjišťovat, jestli na ten čas máš nějakou úlohu a tu si sám spouštět.

  6. a co tooto? https://stackoverflow.com/questions/...ZgwhXjzhE3FUc4

    Citace Původně odeslal TomášX Zobrazit příspěvek
    to ale nelze, musí to podporovat server, tj. musí být cron daemon zapnutý a ty jako uživatel musíš mít přístup ke konfiguraci, vzhledem k tomu, že celé php běží pod jedním systémovým uživatelem, tak ve výchozím nastavení není možné přidávat crony.

    Poptej se hostingu, řada z nich má ve své administraci funkci na plánování cronů. Nebo to udělej nepřímo, vytvoř si v php url, která bude vykonávat tebou žádanou akci, kterou má dělat cron a tuhle url se přes nějakou jinou aplikaci provolávej. Můžeš to nechat provolávat třeba i několikrát za minutu a až v php s pomocí databázi si zjišťovat, jestli na ten čas máš nějakou úlohu a tu si sám spouštět.

  7. Však tam také píše “ This requires that the user which PHP is run under has the right to make crontabs”.

    Na vlastním serveru to lze nastavit, předpokládám ale že máš hosting, jinak bys to již dávno měl. Kde hostuješ? Proč to potřebuješ nastavovat z php?

  8. Cronjob je sice technicky lepší řešit nativně přes unix crontab nebo windows scheduled tasks (fuj :) ), ale teoreticky můžeš provozovat pseudo-cron jen na aplikační úrovni např. přes Symfony Console nebo ReactPHP.

    Cron Jobs (SymfonyCloud Docs)
    https://github.com/WyriHaximus/reactphp-cron

  9. ano mam vlastny server potrebujem to spustit nakolko budem potrebovovat vytvorit velke mnozstvo cronu a rucne ich vytvorit by bolo nerealne.... server mam od https://www.vas-hosting.cz/dedikovane-servery

    Citace Původně odeslal TomášX Zobrazit příspěvek
    Však tam také píše “ This requires that the user which PHP is run under has the right to make crontabs”.

    Na vlastním serveru to lze nastavit, předpokládám ale že máš hosting, jinak bys to již dávno měl. Kde hostuješ? Proč to potřebuješ nastavovat z php?

  10. jak moc velké množství? Není dobrý nápad do linuxového cronu dávat více než desítky úloh, vše se spoustí seriově a celé se to pak chová dost nepředvidatelně. Správně bys měl crony sdružit do malého množství klidně velkých úloh.

    A proč ti nefunguje ten příklad ze stackoverflow? Ten vypadal v pořádku.

  11. cca 10 000 cronu ak by som tie ulohy dal do jedneho scriptu tak by sa to vykonavalo dlho a mohlo by to pri vykonavani zmrznut... preto to chcem rozdelit tie scripty do viacerych cronov

    Citace Původně odeslal TomášX Zobrazit příspěvek
    jak moc velké množství? Není dobrý nápad do linuxového cronu dávat více než desítky úloh, vše se spoustí seriově a celé se to pak chová dost nepředvidatelně. Správně bys měl crony sdružit do malého množství klidně velkých úloh.

    A proč ti nefunguje ten příklad ze stackoverflow? Ten vypadal v pořádku.

  12. Proč máš 10k cronů a nesjednotíš to do jedné úlohy?

  13. lebo ta jedna uloha moze zmrznut.....
    Citace Původně odeslal Petr Hejda Zobrazit příspěvek
    Proč máš 10k cronů a nesjednotíš to do jedné úlohy?

  14. Jestli potřebuješ mít 10 tis. cronů, tak je někde něco špatně. Proč by měla zmrznout? K tomu by musel být nějaký důvod, všechno jde ošetřit. Co ty crony mají dělat?

  15. Wild guess: Máš 10k stránek z nějaké sitemapy, zpracováváš je a nakonec posíláš surová data do nějakého koncového eshopu?

    Nebo co je vlastně ten use case?

    Protože zrovna ta sitemapa by šla zpracovávat po jednom kusu sériově a ošetřit nečekané stavy.

  16. Zapisuje udaje do db a cim viacej to rozkuskujem do viacej uloh tym rychlesie tie data spracuje nez ked by to vykonavala jedna uloha

    Citace Původně odeslal tomas505 Zobrazit příspěvek
    Jestli potřebuješ mít 10 tis. cronů, tak je někde něco špatně. Proč by měla zmrznout? K tomu by musel být nějaký důvod, všechno jde ošetřit. Co ty crony mají dělat?

  17. u cronu ti to ale také nebude dobře fungovat, cron není proces management, bude ti to tiše umírat a nebude se to spouštět.

    Paralelizmus je samozřejmě urychlení, ale používej jednotky souběžných úloh, ne 10tis, tak scheduler v linuxu nefunguje a je to kontraproduktivní, stejně tak nebudeš mít tolik spojení na db.

    Udělej si frontu v databázi (tabulka se všemi úlohami a jejich parametry, přidej sloupec s náhodným číslem od 1 do 5, do jendoho sloupce si ukládej datum, kdy byla úloha dokončena. K tomu si udělej php script, který si načte třeba nedokončených úloh 100 úloh, zpracuje, uloží, že je zpracoval a ukončí se. Do cronu si ho dej pětkrát s parametrem od 1 do 5 (podle toho si načte úlohy z db), každou minutu je spušť, použij flock (linuxový příkaz), aby se nespouštěly dokud ještě předchozí běží.

    Každý den si jiným cronem přegeneruj tabulku s frontou a dej tam nové úlohy. Crony ti to pak budou postupně po malých kouskách zpracovávat. Je to spolehlivé, máš nad tím kontrolu, můžeš v db sledovat jak se to postupne odbavuje.

  18. Na to je lepší použít - nainstalovat si nějaký message queing systém např. rabbitMQ nebo Kafka, než tím zatěžovat cron. Pro obojí je potom podpora v PHP.

  19. kafka nebi rabbitmq ti neřeší jak zprávy zpracovat (konzumovat), na to stejně potřebuješ nějaký cron, php neumí dobře běžet jako daemon.

    Nedoporučil bych něco takového použít, kafka bere nemalé prostředky, musíš nějak vyřešit zabezpečení, ve výchozím stavu je vše otevřené do světa a pro tohle použití je to příliš složité.

    Databáze je na tyhle účely dostatečná.

  20. Citace Původně odeslal TomášX Zobrazit příspěvek
    .. php neumí dobře běžet jako daemon.
    Tomáši, proč podle tebe nemůže běžet php jako daemon dobře? Nebo co je to "dobře" v tvém pojetí?

  21. Citace Původně odeslal skorozacatecnik Zobrazit příspěvek
    Tomáši, proč podle tebe nemůže běžet php jako daemon dobře? Nebo co je to "dobře" v tvém pojetí?
    není na to určený, budeš narážet na problémy s memory managementem a memory leaky (frameworky vč. nette nebo doctrine to nezvládají, v php 7.4 udělali velký kus práce, ale pořád to není on), je single thread, takže buď přebírá požadavek z venku nebo něco vykonává, nemůže dělat obojí (např. když budeš parsovat 10MB xml 5s, během té doby ti nebude odpovídat na ping a nepoznáš, jestli script je mrtvý nebo něco dělá, to vede k blbému monitoringu), z řady chyb, které vzniknou se neumí zotavit (registrace error handleru je třeba jednorázová, nelze to tak opakovat donekonečna) atd.

    Někdo se o to pokouší a pokoušel, ale celý php ekosystém je určený na spot run a podle toho se testuje a vyvíjí. Dělat z něho daemona jde proti větru a zbytečně si přiděláváš práci, přitom jiné jazyky ti nedělají bariéry a umí to dobře s pár řádky kódu (node.js, python, go, java/scala). Dělat z konkrétního jazyka univerzální jazyk na vše přináší vždy určité problémy, nechci tím říct, že php je špatný jazyk, jen tohle neumí a není to špatně, od toho tady je apache/nginx/cgi/fpm, která to řeší.

  22. Citace Původně odeslal TomášX Zobrazit příspěvek
    není na to určený, budeš narážet na problémy s memory managementem a memory leaky (frameworky vč. nette nebo doctrine to nezvládají, v php 7.4 udělali velký kus práce, ale pořád to není on), je single thread, takže buď přebírá požadavek z venku nebo něco vykonává, nemůže dělat obojí (např. když budeš parsovat 10MB xml 5s, během té doby ti nebude odpovídat na ping a nepoznáš, jestli script je mrtvý nebo něco dělá, to vede k blbému monitoringu), z řady chyb, které vzniknou se neumí zotavit (registrace error handleru je třeba jednorázová, nelze to tak opakovat donekonečna) atd.

    Někdo se o to pokouší a pokoušel, ale celý php ekosystém je určený na spot run a podle toho se testuje a vyvíjí. Dělat z něho daemona jde proti větru a zbytečně si přiděláváš práci, přitom jiné jazyky ti nedělají bariéry a umí to dobře s pár řádky kódu (node.js, python, go, java/scala). Dělat z konkrétního jazyka univerzální jazyk na vše přináší vždy určité problémy, nechci tím říct, že php je špatný jazyk, jen tohle neumí a není to špatně, od toho tady je apache/nginx/cgi/fpm, která to řeší.
    Budu s tebou souhlasit, že PHP na daemony není úplně dělané (viz druhý odstavec), ale jako CLI s tím není moc problém. Pokud forkujes procesy, tak se dají sledovat, spravovat i monitorovat.

    Nemohu ale do velké míry souhlasit s tím prvním odstavcem. Je sice pravda, že je docela těžké udržet memory (u mě třeba cca 20M na proces), ale jde to, jen člověk musí být pečlivý při psaní kódu a čistit paměť, kde to jen jde.

    Co se týká využití zdrojů (procesorů/threadů), tak ano, každý script využije jeden thread, ale zase jsem u toho CLI a forku, kde může jeden script obstarávat požadavky a další procesy mohou pracovat s daty, které předávají zpět k odeslání. Jako další (ne moc čisté řešení) je mít opět jeden controller script, který volá další úlohy (workery) klasicky přes URL. Dané scripty zpracují data a uloží je třeba do REDIsu, odkud si je hlavní script vytáhne a odešle.

    Z vlastní zkušenosti vím, že script spuštěný jako CLI dokáže odbavit tisíce zpráv za sekundu. Musí ale delegovat složité úlohy dalším procesům.

    Každopádně jsou jiná řešení (jazyky), které jsou na podobné věci šikovnější, v tom máš naprostý recht. Jen mi přišlo neobjektivní to Tvé "absolutní zavrhnutí".

    Takže s tebou souhlasím tak napůl no.
    Každopádně díky za názor.

  23. striktně jsem to zavrhoval jen z kontextu vlákna, radit zde použití php jako deamona mi nepřipadá košér a není dostatečný prostor to odůvodnit, proto jsem napsal "neumí dobře", to je striktně za to přesný popis :).

    Memory si sice dokážeš sám čistit, ale když použiješ balíček/framework třetí strany, jsi uvězněný v pasti. Forkování procesů, ipc komunikace (ať už přes shmop nebo stream_socket_pair) je vyšší dívčí pro zdejší publikum. Stejné je to i s těmi crony, ono to jde i pro 10 000 úloh, freebsd má třeba u cron daemona pro tyhle účely náhodné zpoždění v ms, aby vše nespustilo najednou a nedošlo k fork bombě, stejná věc se usleepem lze zajistit i pro linux atd.

    Na tyhle účely má třeba php tak špatně udělaný subprocess managenet, že stejně všichni končí u proc_open a ve smyčce si pulují stavy jednotlivých procesů a hlídám je. Další zádrhel jsou statické velikostí io bufferů a pro jejich změnu musíš rekompilovat php. Tohle je už za rámec většiny php programátorů, sám víš kolik jsi s tím měl práce a že to není sranda. Historie mě naučila, že raději je potřeba zavčasu na tyhle slepá místa upozornit a nedoporučit.

    PHP v roli daemona používá několik velkých českých ecommerce řešení a je to drahé produkční řešení, jakýkoliv debugging je obrovský problém, heapdumpy jsou skoro k ničemu, xdebug má vysoké nároky a na produkci způsobuje sám pády. Já z toho mám aspoň zakázky, ale nechtěl bych takovou věc mít doma :).

  24. Jsi to krásně doplnil Tomáši. Ten debugging je asi největší peklo a admini ze mě vůbec nebyli šťastní. Když já mám to PHP tak rád... :)

  25. taky sem dlouho mel PHP rad, ale uz jedu nodu... a nevracel bych se ani za nic...

Spolupracujeme: Jooble.org, Aximum - profesionální překlady Hostujeme u Server powered by TELE3