Search  
Sunday, August 09, 2020 ..:: Forum ::.. Register  Login
 Forum Minimize
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.

SearchForum Home
  Visual FoxPro  Baze de date, tabele, view-uri si indecsi  Performanta sla...
 Performanta slaba la accesul concurent pe tabele mari
 
 7/8/2011 11:48:20 PM
User is offlineclivius33
226 posts
4th


Performanta slaba la accesul concurent pe tabele mari
 (N/A)
Ma lovesc de o problema care am sentimentul ca este de la sistemul de operare. Pe un calculator cu Windows (nu conteaza daca este XP, 7 sau 2003 Server) ruleaza o aplicatie la care au acces mai multe calculatoare din retea (modelul file sharing). Accesul concurent la care ma refer in continuare este strict pe consultarea tabelelor ! Sa consideram un Select SQL simplu care se executa pe o tabela de vreo  80.000 de inregistrari (nici nu e prea mare nu ?) :
select nrfactura,client from facturi where nrfactura = 2011 into cursor qfacturi
Cum pe campul 'nrfactura' este un index, comanda trebuie sa zboare. Daca rulez asta chiar pe server obtin un timp foarte bun, daca rulez pe o statie din retea cand este singura intrata in program, timpul este iar foarte bun, sa zicem 0.2 sec.
 Daca insa mai intra o alta statie in program si ruleaza comanda asta, performanta se degradeaza ingrozitor (de aproximativ 10 ori, adica o sa dureze 2 secunde) pe ambele statii. Deci repet, se fac doar citiri, nu este nici un fel de blocare de genul flock() sau rlock() pe tabela respectiva. Ciudatenia si mai mare este ca daca una din statii iese din program, pe statia care a ramas se mentine performanta slaba, totul revenind la normal doar daca tabela 'facturi' este inchisa ! Dupa inchiderea tabelei si reluarea interogarii viteza se mentine buna atata timp cat statia ramane singura in program.
1.Oare de ce face asta ?
2. Pot sa fac ceva din punct de vedere Fox ? Adica d'aia nu e bun Fox-ul la lucrul cu tabele mari ?
3. Este o limitare a Fox-ului sau a sistemului de operare de retea care gestioneaza accesul concurent la fisiere ?   

Multumesc mult.
 7/9/2011 12:52:29 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: Performanta slaba la accesul concurent pe tabele mari
 (N/A)
Poate fi din cauza retelei, dupa cum poate fi din cauza aplicatiei.
Ce dimensiune are tabela dbc si ce dimensiune are fisierul cdx?
Ce lungime are o inregistrare?
Ce spune sys(3054,11)  la rularea selectului?

VFP se descurca bine si cu tabele mari, dar cu o baza de date bine structurata si intr-o aplicatie optimizata.
Totusi, pentru o aplicatie de retea singura solutie viabila este client/server. Tabelele dbf dateaza de pe vremea sistemelo mono-tasking, singura aplicatie care rula in sistem era cea care gestiona tabelele.

Nu exista nici o limitare in vfp in ceea ce priveste accesul concurent la fisiere. Asa ceva nu exista in VFP. Fisierele sunt accesate de fiecare aplicatie in parte. Indiferent daca sunt instante ale aceleiasi aplicatii, nu au habar una de alta.
Sistemul de operare are insa habar de cate ori este deschis un fisier, el este cel care citeste datele si le transmite aplicatiei care le-a cerut. Eu insa nu m-am lovit de limitari ale sistemului la acces concurent la un numar mic de instante.

Poti incerca sa testezi sistemul cu acces concurent pe un alt tip de fisier, cu o aplicatie cu rata mare de transfer, cum ar fi un film cu  bitrate 8-10Mbits/sec. Il rulezi pe cateva statii simultan, si vezi la a cata instanta incepe sa se poticneasca.

Daca totul revine la normal doar daca tabela facturi este inchisa, este ceva in aplicatie - baza de date + cod.
Daca poti executa acel select din vfp ide de pe mai multe statii fara ca viteza sa fie afectata, problema e in aplicatie.
Poti testa baza de date astfel: creezi o baza de date noua, creezi o tabela facturi noua, cu aceeasi structura, dar numai cu indexul primar si nrfactura. Aduci in ea datele din tabela de lucru, apoi incerci selectul in aceleasi conditii in care acum se poticneste.
Daca nu se reproduce situatia - viteza revine la normal doar dupa inchiderea tabelei - problema e in baza de date.




Daniel Buduru
 7/9/2011 9:56:56 AM
User is offlineclivius33
226 posts
4th


Re: Performanta slaba la accesul concurent pe tabele mari
 (N/A)
De luni am sa reiau testele la servici si am sa revin cu amanunte. Ma gandesc sa testez si pe niste tabele 'free' , sa elimin astfel din ecuatie dbc-ul sa vad performanta in acest caz.
Multumesc frumos pentru sugestii !
 7/9/2011 10:08:34 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: Performanta slaba la accesul concurent pe tabele mari
 (N/A)
Testeaza cu un dbc nou, nu e nevoie ca tabelele sa fie free, dar nici in dbc-ul curent.
Se poate ca problema sa fie in dbc-ul curent - trigger, constraint sau altceva.
Poate postezi si informatiile despre dimensiunile fisierelor si ale inregistrarii.

Daniel Buduru
  Visual FoxPro  Baze de date, tabele, view-uri si indecsi  Performanta sla...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement