Urychlení PHP kódu/rada ohledně serveru/rada ohledně MySQL storage enginu – PHP – Fórum – Programujte.com

Zdravím všechny,

potýkám se se celkem ubíjejícím problémem: Na webových stránkách A (a dalších - B, C, D, ...) je vložen externě Javascript zčásti generovaný PHP (<script src=X/neco.js.php>) Tento JS kód odesílá relativně velké množství dat pomocí POST requestů ke zpracování na X/zpracuj.php Bohužel už jen server A navštíví i několik set lidí denně, nemluvě o faktu, že takových webů je a bude víc. Tzn ze muj PHP skript zpracuj.php ukládá do MySQL databáze třeba 200000 řádků denně a má tolik požadavků najednou, že se moje stránky X sesypou (zahlcení serveru), a jelikož skript neco.js.php na těchto stránkách je nedostupný, tak jsou nedostupné i A, B, C, .... A to je ten problém. Řešil jsem to otpimalizací všech kódů, dostal jsem velice dobrý výsledek.

Skript zpracuj PHP je jednoduchý: jen přijmu sposutu dat oddělených nějakým znakem, projdu to smyčkou, jednotlivé části uložím do MySQL databáze, žádné hlouposti navíc, jen toto, přesto je to z nějakého důvodu moc pomalé.

1) Jak urychlit takové vkládání do MySQL databáze, je to vůbec možné?

2) Má někdo zkušesnosti s využitím virtuálních serverů - myslíte, že by jejich zavedení mohlo pomct a jaké by měly být parametry?

3) Používám InnoDB, měl bych raději využívat něco jiného, co by se pro mnoho řádků rychle hodilo lépe?

Informace o současném výkonu serveru sem ještě dopíšu,

Nechápu vznik těchto problémů, když za poslední dvě hodiny bylo posláno celkem jen asi 1 MB dat směr server...

k cemu vubec potrebujete takovy mnozstvi dat?

pomoci muze:

1. dedikovana databaze (vlastni server jen pro ni)

2. dedikovanej database cluster

3. snizit zatez - jsou ty data opravdu potreba?

4. fcgi misto zpracuj.php (nemusi se porad pripojovat a odpojovat kvuli par dotazum - pripoji se na zacatku a posila dotazy)

5. jiny typ databaze - otazkou je, co a jak ma byt ulozeno.. (treba kyoto tycoon by melo zvladat http requesty primo na sobe pokud jsou ve spravnem tvaru (a zpracovat scriptem v lua primo v databazi)-- ale zase by to nesmelo byt samozrejme videt primo

6. rotovat databazi - jednou za cas vykopirovat jinam a ty zaznamy ... mala tabulka je rychlejsi nez velka .. obzvlaste pokud sou tam zaple indexy

Díky za rychlou odpověď!

Databáze je dedikovaná

Cluster zní jako velice dobrý nápad

data jsou posílána opravdu jen ta, která jsou potřeba, vždy jde pár znaků proškrtat, ale spíš než o velikost jednoho requestu jde asi o to, že jicj je ve finále opravdu hodně ve finále třeba i z A jde ve špičce 2000-3000/hod. (a bohužel jich potřebuju hodně, hodně často)

ou... fcgi neumím, možná se to kvůli tomu naučím, ale kamarád říká, že to je na dlouho, což se teď moc nehodí...

o bodu 5 ještě popřemýšlím... ukládám timestamp (i s msec), 6 místné číslo, číslo < cca 100, číslo 0-10, pak řetězec v 95% do 7,9 znaků, jinak nepatrně delší nebo taky 3,4 znaky - prostě krátký

indexy tam vůbec nastavené nemám, nejsou potřeba, nikdy se nestane, že bych vyhledával pomocí ID, ale vyhledávám vždy třeba 10000 řádků se stejnou položkou (a je to velice rychlé)

----

právě mi někdo poradil použití TCP/IP (php i js to prý podporují) pro přenos dat, snad právě místo fcgi

ja prave kyoto + lua script pouzival na vyceurovnovy token bucket... ukladalo se cca 100B dat index pomoci 32B hashe... na notebooku (vcetne generatoru) sem se dostal k rychlostem pres 10000 requestu/s

jinak innoDB je transakcni engine... a kdyz koukam na moznosti tak by mohl klidne stacit CSV engine nebo ARCHIVE...

k tomu kyoto + lua ale potřebuju naisntalovat vyžadovaný vychytávky přímo na server (ano?), což by znamenalo přechod někam jinam, kde si budeme moct dělat co chceme. Ale rozhodně mi to přijde jako vhodné řešení, ještě pořádně prozkoumám.

mockrát díky za radu, chytím se toho a uvidím, jestli z toho něco vyleze :)

#6 LJ1024
jo to kazdopadne chce mit server s pravama ... kdyztak zkusit jesli nejde pouzit jiny engine.. ten csv nebo archive by mohl byt mnohem lepsi nez innodb .. i myisam by melo byt lepsi na tendle druh akci ..

Ahoj,

a nemohl bys poslat selekt? Ja si myslim, ze navrhovany postup je prislis drasticky, obsas staci jen vhodna uprava. Posli napr. strukturu tabulky, do ktere ukladas a posli insert, ktery pouzivat. Jsem si jisty, ze se s tim bude dat neco udelat ;-)

INSERT INTO `".$pre."record` (`link_id`, `key`, `stream`, `url`, `time`, `action`, `data`) VALUES (0, $id, '$stream', $url, $time, '$action', '$data')

1  link_id  int(11) - pozor! neni index, ani primarni klic, nic z toho
2  key  tinytext  utf8_czech_ci - prazdna poloha pro hash (ktery se objevi u kazde cca 10000. polozky a pote je odstranen od okamziku, kdy neni treba a uz je jasna identifikace pres link_id)
3  stream  int(11)
4  url  int(11)
5  time  bigint(20)
6  action  smallint(6)
7  data  tinytext  utf8_czech_ci