Voi ce mi-ati recomanda?

[florinbad]

Daca l-ati ajutat pe NFS si pe Hitman, poate ma help-uiti si pe mine!

Am scris o aplicatie in VisualFoxPro care "descarca" orice tip de instalatie, masina, motor, avion etc.etc.etc pe articole componente, pana la nivel de surub, piulita, electrod, ulei, grund etc.

Cand am conceput aplicatia, n-am prevazut ce impact va avea asupra serviciului Tehnologie-Proiectare d.p.d.v. al ajutorului pe care aceasta il va aduce personalului (ingineri-tehnologi) din acest serviciu si astfel, de la o aplicatie mono-post am ajuns in momentul de fata la un server+12 posturi de lucru. Toate bune si frumoase pana aici, insa pe post de "server" este un PC obisnuit, un Pentium IV cu Hard de 80 Gb, memorie de 256 M si frecventa de 1,7 Ghz si s-au "incarcat" in cele 4 tabele de baza aprox. 170.000 de articole (ocupand un spatiu de 25Gb)! Am intrebat tehnologii cam cate instalatii au fost incarcate in baza de date si raspunsul a fost: 10-15% din totalul instalatiilor! Bashca, s-a redus timpul de raspuns, a crescut nervozitatea utilizatorilor iar peste 3-4 saptamani se vor mai adauga inca 6 utilizatori...

Sunt disperat deoarece as vrea un server "adevarat" cu cel putin 2 procesoare, cu hard de 1Tb, cu memorie de cel putin 512 M si nu stiu ce naiba sa fac! Aveti idei, solutii, "pile", recomandari, firme serioase etc. Danke foarte mult anticipat pentru orice recomandare!

[Shenck]

Am scris o aplicatie in VisualFoxPro

Nu cred ca te ajuta un partea de paralelism al unui sys nou.

VisualFoxPro nu e gindit pt paralelism. Parerea mea: schimba vfp si refa structura bazelor (program, de export/impot) in alta structura.

Sigur se poate gindi o alta structura la tabele.

Nu sint deacord cu crestrea sys de calcul pt a compesa un program care NU a fost gindit pt asa ceva.

[Satori]

stai putin. deci baza de date are pana acum 25GB?? ce SGBD folosesti? si cum este structurata baza de date?

 

puha... am citit visual basic... pai daca pastrezi in fox nu o sa rezolvi nimic.

eventual poti sa faci mai multe baze de date, dupa un anumit criteriu spargi informatia in respectivele baze de date (de exemplu: bddiesel, bdbenz) si mai tragi de timp. dar nu vei reusi mare lucru.

[john]

daca zici ca s-au incarcat 10-15% din instalatii si deja ai 25gb cand se vor incarca toate vei avea sa zicem in jur de 250gb DB

in plus spui ca mai creste si numarul de utilizatori deci timpul de raspuns creste si din partea asta. din cauza asta poate creste f. mult si incarcarea retelei, mai ales ca zici ca a fost gandit monopost.

deci in conditiile astea ai avea nevoie de super hard care nu sunt convins ca va face fatza.

cred ca cel mai bine e sa rescrii aplicatia, sa faci un client server sa reduci si traficul, plus o alta structurare a DB, un DB server mai puternic..etc.

partea cu hardul mi se pare o solutie de compromis..temporara..e clar ca nu va face fatza in viitor, dar macar mai dregi treaba pana rescrii aplicatia, apoi vei avea un hard mai bun pentru noua aplicatie.

 

p.s. io ma mir cum de nu a crapat pana acum foxul la giga aia.

sau a crapat ? :machiavelic:

 

inca ceva : zici de aplicatia actuala ca e de fapt monopost, folosita insa acum pe un 'server' si 12 statii de lucru. accesul la baza se face cu metoda oldie "Map Network Drive" ? ca atunci inseamna ca e destroy prin retea la volumul ala de date.

 

la partea de hard iti trebuie neaparat hdd-uri SCSI pentru viteza si latime de banda, plus o matrice RAID pentru sigurantza/backup-ul datelor.

 

eu am la serviciu un calc exact ca ala pe care e acum serverul tau, dar cu 512 ram / hdd 7200rpm si mi se pare jenibil :swearing: :spume:

dar pentru un server :eyespin:

[florinbad]

Nu mai este mono-post de mult, este multi-post! Bazele de date, indecsii, report-urile, sursele compilate etc se afla pe "server" iar local am numai fisiere temporare. Fiecare PC se leaga la "server" printr-o litera (de ex.: fiecare PC se leaga la calculatorul "X" si apoi se lanseaza aplicatia in lucru). Legatura este de forma: PC->Hub->Server. Timpul de raspuns a crescut (pe masura adaugarii utilizatorilor) de la 5-6 sec la 16-18 sec (pentru o instalatie care are, de exemplu, 6.000 de repere). Orice ar zice fiecare, VFP este foarte bun (nu vreau sa deschid aici o polemica referitoare la cel mai bun SGBD... :? ) si inca, recunosc, nu m-am obisnuit prea bine cu el! Sunt constient ca, folosind SQL-ul, as putea creste viteza, dar timpul ma preseaza si trebuie sa gasesc o solutie de compromis!

Pt.Satori: fiecare programator este "sluga" beneficiarului. Deci, a trebuit sa accept si 4 campuri de 50 caractere fiecare...

Pt.Akaionut: ei, uite ca n-a crapat si nici n-o sa crape! In background, se fac salvari pe fiecare PC in parte (nici un utilizator n-are habar de acest lucru!) plus o copie de rezerva pe "server". "Server"-ul nu este conectat la reteaua generala a firmei si astfel am scapat si de virusi si de hacker-ism sau craker-ism... Intr-adevar, asa cum am zis mai sus, accesul la baza se face cu metoda oldie "Map Network Drive". In firma nu a mai facut aplicatie de retea nici un programator. Eu sunt primul care a incercat si n-am avut nici un ajutor de niciunde, n-am avut si eu pe cineva cu care sa ma sfatuiesc, am fost numai eu si cartile... De aceea sunt depasit de evenimente! Multumesc oricum pentru sfaturi! Sa aveti, toti, o zi impecabila!

[panzer]

Din nefericire asta este buba lucrului connected. Nu prea conteaza cat e de mare BDul (fizic) conteaza cat de bine este INDEXat.

 

Sunt mai multe chestii pe care le poti face dar toate in structura programului:

Banuiesc ca folosesti select-uri.

- daca folosesti index-ul (in .cdx) pe campurile pe care se face comparatia ajuta. Cat mai multe index-uri si noaptea REINDEX ... very helpfull

- foloseste view-uri

- odata am incercat si folosind DBF-uri index: adik: dbf-uri adiacente doar cu informatiile de selectie si apoi un scurt "set rela to" sa se miste intre cele 2 tablele (cam nesatisfacator)

- daca ai organizat datele in DBC poti sa folosesti TRIGGERii care sunt foarte folositori.

 

Nefericirea FOX-ului este lucrul connected. Poti sa-l pacalesti transformand BDul in ACCESS si apoi conectandu-te la el cu ODBC tranzactional. E mai greu dar lucrezi disconected. Sau daca au vreun server serios este de preferat access-ului: ma refer la SQL Server ca la Oracle ai sa ai probleme sa gasesti un driver ODBC fara BUGuri...

 

Later edit:

Am vazut ca spui ca nu-l stapanesti prea bine. Poti sa postezi un mic exemplu despre cum faci adaugarea in cod... cu codul de deschidere a tabelei. Sa ne dam si noi seama cam la ce nivel gandim...

Cum adica timp de raspuns la 16 secunde??!?!?

Oricum: nu-i din HARD cum spune lumea. Am reusit sa fac query din 1.000.000 inregistrari cu timp de raspuns sub 20ms. Deci...

[Satori]

da, un cod ar fi destul de bun pentru depistarea unor eventuale imbunatatiri.

te rog, da si structura bazei de date sau/si a tabelelor si a indecsilor (chiar si cu denumirea schimbata nu ma deranjeaza).

 

ceea ce propuneam eu este sa imparti baza de date in 2 sau 3 sau cat se poate, acestea avand aceiasi structura dar cu anumite particularitati ale informatiei. (cum ar fi, de exemplu, impartirea abonatilor x in y tabele, fiecare tabela reprezentand un oras).

[florinbad]

Timpul de raspuns de 16 secunde se obtine numai la lansarea unei comenzi "normale" sau atunci cand se doreste verificarea corectitudinii anumitor tipuri de rapoarte. La lansarea comenzii se folosesc 17 tabele (cele 4 tabele de baza, 2 tabele "de lucru", 7 nomenclatoare si 4 tabele temporare). In rest (actualizare, consultare) timpii sunt in jur de 2-5 secunde. Lansarea comenzii ma omoara, parca toti tehnologii s-au vorbit intre ei sa lanseze in acelasi timp diverse comenzi si de aici ies nemultumirile lor in ceea ce priveste timpul de asteptare.

M-am gandit sa copiez toate report-urile si nomenclatoarele pe fiecare PC in parte iar cele 4 tabele de baza, uriase ca dimensiuni, inclusiv indecsii lor sa le pastrez pe "server". Tot pe server voi lasa si aplicatia. Dar daca doresc sa fac o modificare intr-un raport (de exemplu) va trebui s-o fac de 12 ori...

Satori spunea sa impart BD pe "caprarii". Ar fi o solutie pentru, sa zicem, 20 de instalatii, cel mult. Dar eu am de incarcat in jur de 185 de instalatii!

PS : acum un an si ceva, firma Siveco a incercat sa faca ceva d.p.d.v. al tehnologiei de lansare (cu preluarea datelor din baza mea de date) dar ne-a spus ca va dura cel putin 2 ani ! (partea de tehnologie-productie, este cea mai "grea" d.p.d.v. al unui Sistem Informatic Integrat si mai mereu este lasata la urma...). Firma SAP s-a bagat si ea dar cu rugamintea sa-i lasam...3-4 ani pentru partea de productie!

Cu SGBD Access nu merge, crapa la tabele cu peste 20.000 de inregistrari (adica poti sa mananci un sandwich bun pana iti apare ceva pe ecran, sau aplicatia se blocheaza cand ti-e lumea mai draga...(am foarte multe campuri, unele cu dimensiuni de 50 de caractere).La Fox nu mi-a crapat niciodata (pot sa bag mana in foc pentru asta !). Aplicatia am scris-o initial in Fox 2.6 iar acum o trec pe VisualFox 8.0 si as dori s-o folosesc impreuna cu SQL Server al lui Bill. Cam atat...

[cchrism]

Un move catre o baza de date adevarata se cam impune. Dezvantajul mare al lui FoxPro fata de un SGBD adevarat este ca iti lipsesc sculele de optimizare. In SQL Server de exemplu faci o captura cu query-urile cele mai dese si iti recomanda el indecsii pentru cresterea vitezei. Un import dintr-o baza de Fox in SQL Server se poate face destul de repejor (via DTS), mai faci si un frontend in ASP.NET sau mai stiu eu ce (chiar si un smartclient local, de fapt in cazul tau chiar mai recomandat) si nu ai ce sa faci dupa aia. Presupun ca in mare parte baza este read-only (ca procent al datelor modificate) si este folosita in mare parte pentru consultare, right?

Daca faci trecerea la SQL Server pe statiile de lucru poti sa lasi si un Celeron la sub 1 GHz si va merge decent (daca nu te apuci sa faci nu stiu ce calcule la client), iar pt. serverul de SQL o masina cu 1 - 1,5 Gb RAM si HDD cat sa-ti incapa datele va merge super. Conteaza f. mult RAM-ul si discurile sa fie rapide.

[florinbad]

Cchrism, multumesc pentru sfaturi! Din pacate, cel putin un an si jumatate aplicatia va fi folosita 85%-90% pentru incarcarea datelor... Partea de read-only este folosita intr-adevar de utilizatori, insa partea de actualizare primeaza in mometul de fata (tehonologii mi-au ridicat "statuie" pentru acest lucru; nu mai sunt nevoiti sa scrie de mana sutele sau miile de pagini necesare lansarii unei comenzi tehnologice: bonuri de consum, borderouri, bonuri de manopera prelucrari materiale, epruvete, debitare oxigaz, grafice de productie, fisele tehnologice, manopera cumulata si manopera specifica, SDV-uri, specificatia reperelor turnate-forjate-laminate-lemn, specificatiile tehnice de aprovizionare etc.etc.etc).

Voi merge in paralel cu aplicatia veche si voi incerca variantele:

1. SQL Server + VisualFox (interfete, report-uri)

2. SQL Server + VisualBasic (interfete)

 

Nu se pune problema de Oracle (foarte scump), Access (prea "mic" pentru o aplicatie de o asemenea anvergura) sau MySQL (cu care nu sunt familiarizat). Alte SGBD-uri nu voi folosi (Informix, Paradox, Firebird etc)

[john]

poti folosi MSDE (varianta gratuita a MS SQL Server)

[cchrism]

Dar dupa ce vor fi incarcate datele, baza va deveni mai mult sau mai putin readonly, right? In plus cum sunt incarcate datele? Manual sau luate din alte chestii si importate? Ca poate reusesti sa automatizezi acest import.

Dupa cum ziceam SQL Server it's a must (nu neaparat serverul de la MS, dar avand in vedere ca ai Fox se pot importa mai usor datele). Pentru interfata ti-as recomanda sa vizitezi varianta .NET, din mai multe motive: La suportul pentru VB s-a cam renuntat, 30 sept. fiind ultima data de suport pentru Visual Studio 6 (ce include si VB 6).

In .NET ai suport pentru ceea ce se cheama ClickOnce (ok, in 1.x, nu e asa dezvoltat dar este cat de cat usable), ceea ce inseamna ca le dai la oameni prin email un link si aplicatia se instaleaza si se updateaza direct de pe server automat (cand o sa ai 50 de posturi o sa vezi ce bine e). In plus faci interfata repede, iar daca stii VB o sa te obisnuiesti destul de rapid cu VB.NET.

Iar pentru raportare ai SQL Reporting services, care face niste rapoarte super-marfa, poti sa te abonezi si o data pe luna sa-ti trimita raportul prin email, etc.

Ma ofer sa te ghidez in masura timpului meu liber disponibil.

Pt. Akaionut, performanta MSDE se degradeaza destul de vizibil la peste 5 utilizatori concurenti (limitare din codul MSDE-ului, nu ca nu ar face el fata).

[panzer]

Si eu spun tot de .Net pt asa ceva. Doar ca reporting-ul nu mi-a placut deloc si am ajuns la Crystal Reports pt facilitatile Embedded ActiveX: Viewr & Designer...

Daca stii VB stai pe VB .Net, daca ai fost programator de Java (sau mai esti) atunci C#.

 

Revenind: programul este in Fox 2.6 (de dos banuiesc) :?: Si te miri!!! Asta este un FOX preMicrosoft. Macar un VFP 6 ar trebui sa faci caci odata cu intrarea in VS suportul SQL e mutl mai fain!

 

Aporpo: FOX 8 este aproximativ la acelasi nivel cu .Net. Ai avantajul portabilitatii codului si al report designerului integrat.

 

Eu tot mai spun ca problema e SOFT si nu HARD. "SQL Select"-ul nu tine cont de dimesiunea tabelei avand in vedere ca realizeaza queryul pe index. Problema este ca daca lucrezi file-sharing el nu poate executa selectul pe server ci se apuca sa transfere prin retea datele necesare si executa folosind masina client. Aici e buba programului tau: in plimbarea datelor de colo colo. Iti trebuie neaparat arhitectura Client-Server. Mult mai importanta decat trecerea la un SGBD serios (si scump).

 

Si ai spus dimensiunea tabelelor: cate rec-uri are de fapt?

 

fftopic: ce de programatori au daewoo

[cchrism]

Doar ca reporting-ul nu mi-a placut deloc si am ajuns la Crystal Reports pt facilitatile Embedded ActiveX: Viewr & Designer...  

fftopic: Ai vazut SQL Reporting Services si nu ti-a placut? Mama, e o minunatie scula aia. Pe langa faptul ca e gratis daca ai licenta de SQL Server, poti sa-ti faci niste rapoarte cu parametri, cu tot felul de nebunii, imbricate, accesibile ori de pe web, ori sa faci subscriptions, pai Crystal e mic copil, plus ca sunt rulate pe server, la client trebuie doar sa ai viewer de ce format i-ai zis sa-ti faca (Excel, HTML, PDF, etc.).

[cpop]

Fiecare PC se leaga la "server" printr-o litera (de ex.: fiecare PC se leaga la calculatorul "X" si apoi se lanseaza aplicatia in lucru). Legatura este de forma: PC->Hub->Server.

 

Ar fi indicata si schimbarea hub-urilor cu switch-uri pentru marirea latimii de banda + 2 placi de retea pe server. Dar in paralel si un HDD (matrice RAID) rapid. O solutie ieftina si imediata ar fi un RAID de 2 HDD SATA, dar va tine pe termen scurt.

Profi ar insemna matrice RAID pe SCSI (scump si cu ceva costuri de intretinere, HDD SCSI ar trebui schimbate la 2 ani), cel putin 2 Gb RAM rapid, 2 placi retea. Nici procesorul nu trebuie neglijat, dar aici e de discutat.

[Shenck]

scump si cu ceva costuri de intretinere, HDD SCSI ar trebui schimbate la 2 ani

Nu pot sa inteleg cum sinteti adeptii unui cod scris la repezeala compensat prin hardware. PC-ul actual este arhi suficint daca gindesti mai bien structura bazelor si alegi alt mediu de dezvoltare.

 

Florin, nu incerca sa cirpesti. O sa pierzi mai mult pe viitor. Solutiile cu hardware mai bun sint valabile numai daca ai nevoei sa cistigi timp pina termini aplicatia.

[john]

corect, insa nici partea hardware nu trebuie neglijata !!

de ce sa faci o interogare si sa treci cateva sute de megi prin retea si din recordsetul ala sa iti alegi o bucatica. pentru ca asta se intampla daca nu ai o structura client-server. asta e primul lucru care ar trebui schimbat, plus optimizarea codului si interogarilor si trecut la sql server sau mysql (parerea mea...cu oracle am lucrat mai putin si in plus stiu ca e f. scump).

alege o varianta de implementare a aplicatiei si un server de baze de date, schimba in client server si cauta tips-uri de optimizare in functie de varianta aleasa !