Mysql_lekérdezés hossza időben.
Sziasztok!
Azt szeretném kérdezni, hogy ebben a kódban ha mérem a lekérdezés hosszát, mettől meddíg tegyem?A $lekerdezes előtt indítsam a stoppert, és a $lekerdezes utan állítsam meg? Mert ha a $lekerdezes és a while között bontom az adatbázis kapcsolatot, az eredmény attól még meg lesz, ebből gondolom, hogy a while teljes egészében már csak a lekérdezés eredményét használja ,valahonnan.
Azt olvastam a php manualban, hogy az adatbázis lekérdezés után létrejön egy speciális változó, ami egy hivatkozás valamilyen külső adatforrásra (azt is írja ki ha printelem a $valtozo-t: Resource #Id13), de akkor mégis olvas az sql szerverről, csak már valami előkészített adatot (kapcsolat nélkül????)?
Hogy is van ez?
s_volenszki
■ Azt szeretném kérdezni, hogy ebben a kódban ha mérem a lekérdezés hosszát, mettől meddíg tegyem?
$lekerdezes = mysql_query("SELECT * FROM `tabla`");
while($sor = mysql_fetch_array($lekerdezes,MYSQL_ASSOC))
{
print $sor['record'];
}
Azt olvastam a php manualban, hogy az adatbázis lekérdezés után létrejön egy speciális változó, ami egy hivatkozás valamilyen külső adatforrásra (azt is írja ki ha printelem a $valtozo-t: Resource #Id13), de akkor mégis olvas az sql szerverről, csak már valami előkészített adatot (kapcsolat nélkül????)?
Hogy is van ez?
s_volenszki
Attól függ, mit akarsz mérni
mysql_queryidőköltségét szeretnéd mérni, akkor értelemszerűen igen. Ha nem, akkor nem.erőforrás gazdálkodás
A cél az, hogy megállapítsam mennyire hosszú a lekérdezés, és jelent-e problémát szerver erőforrás gazdálkodás tekintetében (több példányban, azonos időben futtatott lekérdezés). Optimalizálni szeretnék néhány lekérdezést, de tudnom kell, hogy az átalakítással nyerek-e erőforrást!
s_volenszki
inkább bízd rá a mysql-re
http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html
http://dev.mysql.com/doc/refman/5.1/en/log-tables.html
Jó megoldás
s_volenszki
korábbi téma
Ismét kérdezek tőletek.
Említettem már az előzőekben, hogy sajnos nincs jogosultságom log-slow-queries-hez, és az apache-al is csak beszélő viszonyban vagyok (tudom, ennyit ér a szolgáltatás amit használok), de viszonylag sokszor okoznak Internal Server Error-t a beragadt lekérdezések.
A megadott útmutatás alapján ismét átnéztem az alkalmazásaimat és egy mérőkóddal elkezdtem logolni minden lkeérdezést, most kiértékeltem, és a következőre jutottam:
Ahol lehet, minden lekérdezés indexelt.
A táblák rendszeresen karbantartottak, optimalizáltak, nincs töredezettség, és nincs overhead.
Minden lekérdezést megvizsgáltam EXPLAIN-el, és mysql mindegyiket megfelelőnek találta.
Ez nem is csoda, hiszen mindegyik teljesen egyszerű, de íme három péda (ugyanabban a táblában kb. 500 rekorddal):
1.
SELECT * FROM `termekek` WHERE termekcsoport_id = '15' ORDER BY termekek ASC
Átlagos futásidő: 0.0001-0.00005 másodperc.
2.
SELECT * FROM `termekek` WHERE katalogus_id = '15' ORDER BY termekek ASC
Átlagos futásidő: 0.0001-0.06 másodperc.
3.
SELECT * `termekek` WHERE akcios = '1' ORDER BY termekek ASC
Átlagos futásidő: 0.0001-0.07 másodperc.
A logfile ehez képest rendszeresen tartalmaz ennél jóval nagyobb futási időket!
Néhány példa:
1-es lekérdezés: 1.57 másodperc
2-es lekérdezés: 1.72 másodperc
3-as lekérdezés: 2.67 másodperc
Mi változtathatja meg a lekérezések idejét ilyen mértékben? Hogyan kezeli a mysql az egyidőben érkező lekérdezéseket? Előfordulhat, hogy ezekből az időkből a tényleges lekérdezés hasonlóan rövid mint általában, csak a várakozás miatt megnövekszik a teljes lekérdezés idelye?
Amikor elfogynak az erőforrások (mert egy vagy több szkript hosszabban fut), csak az újonan induló szkriptek kapnak error 500-at, és a folyamatban lévők lefutnak, vagy azokat is kidobja? Mert ha lefutnak, akkor ha logolnám az összes lekérdezést azonosíthatóan, akkor err.500-közben futva maradó szktiptek valamelyike lehetne a ludas.
Ha meg kidobja, akkor logolnám a kapcsolat azonosítókat, majd "elfoghatnám" a hibaüzenetet és kiszedném belőle, hogy melyik kapcsolathoz tartozik. Persze, ha külön hibakódja van az err.500-kor fellépő eröforrás hiány okozta kapcsolat megszakadásnak (ha ugye megszakad).
Ez egy kicsit tömény lett, remélem áttekinthető, és ha sok lenne benne a butaság, hát vállalom a kritikát. Barkácsolnom kell, hogy tovább jussak, de imádok tanulni! Nincs szebb és egyszerűbb dolog egy megoldott problémánál!
s_volenszki