Diskuze: Složitý skript náročný na výkon pro web server s administrací

Člen

Zobrazeno 8 zpráv z 8.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |


Ahoj,
co to udělat tak, že si práci rozložíš a budeš ty stránky zpracovávat průběžně během celého dne? Pak nebude jednorázově taková zátěž a bude se to všechno hezky stíhat.
Jinak se mi 30 sekund zdá opravdu moc, co všechno tam děláš? Stažení stránky, zpracování a volání API by se běžně mělo stihnout pod 2 sekundy, v extrémních případech max. 5 sekund.
Ono to, že se to v tu jednu hodinu stane jak tak trochu účel. Jeden typ uživatelů musí do té hodiny připravit podklady ke zpracování pro odeslání druhému typu uživatelů. Ono to musí celou stránku přeparsovat a přefiltrovat informace v ní - používám k tomu http://simplehtmldom.sourceforge.net/ . Pak těmi informacemi naplní databázi pomocí údajů, které zadala první skupina uživatelů.
Nevím jak dlouho to může trvat na nějakém externím web serveru, když jsem ten parser použil u jednoho jiného projektu, tak místo mých 10ti sekund mu to trvalo 2 sekundy u cizího hostingu.
Myslíte že je tohle správný postup nebo existuje nějaký způsob jak to jinak optimalizovat za těchto podmínek?
myslim, ze v tomto pripade by mohlo pomoct prekompilacia PHP tak, ako to robi FB, ba dokonca aj vydal na to nastroj a myslim, ze je k dispozicii aj so zdrojovymi kodmi pod opensource licenciou
Myslím že po měsíci už to má pořešené 
Ta knihovna má velikou režii, taky jsme ji používali, ale museli jsme
vyvinout vlastní řešení kvůli výkonu (zlepšení z 160sekund na 23 sekund,
nehledě na to že si to vzalo 6x vyšší prostředky).
Ale 30 sekund není na podobný věci nic neobvyklýho, na nějakým normálním serveru by měl mnohem lepší výsledek.
No pořešené to mám jen dočasně, chce to optimalizaci. Už dávno jsem přemýšlel o předkompilováním, ale je to spíše studentský indie projekt a použít hiphop by mohlo být na mně trochu náročné.
Nejsem ještě v PHP moc zdatný, ale neexistovalo by v PHP něco jako multithreading? Nebo nějakým způsobem mít více webserverů pod jednou doménu a každý z nich by byl zodpovědný za jinou část webů, které se zpracují? Taky jsem koukal, že Amazon má nějaké servery na webové aplikace a uložiště (moc dobře tomu ale nerozumím), nemohl by Amazon tímto způsobem nabízet řešení?
Jsem z toho docela zoufalý, brzo by to mělo být v ostrém provozu.
Loadbalancing je řešení, ale myslím dost overkill, alespoň ten
opravdovej.
Samozřejmě můžeš rozložit operace na různé servery, tam je to už jen o
implementaci.
Multithreading v php je, ale je to taková sranda, určitě se najde lepší řešení.
Jestli rozumím správně, máš jeden php soubor, kterej po spuštění udělá postupně všechny operace? "Multithreadovat" to můžeš jednoduše tak, že budeš mít pro každou stránku jednu instanci - ale pozor, určit správné škálování je věda a mohl by sis uškodit více než pomoct.
Ale jestli máme nějak rozumně pomoct, budeme potřebovat víc detailních informací - klidně i do PM jestli to nechceš mít veřejně, rád pomůžu.
Zobrazeno 8 zpráv z 8.