Revenirea rezultatelor mari printr-o Webservice

Nu există nici o lege greu împotriva 5 Mb ca dimensiune set de rezultate. Peste 400 Mb poate fi greu de trimis .

Veți primi în mod automat agenți de asociere (din moment ce utilizați .net)

pune în aplicare un fel de "paging" în cazul în care   rezultatul este generat și stocat   pe server și clientul poate apoi   descărcați bucăți de rezultate în   cantități mai mici și reasamblați   setat la capătul lor

Acest lucru se întâmplă deja pentru dvs. - se numește tcp/ip ;-) Re-implementarea ar putea fi depășită.

În mod similar -

întregul set de rezultate va trebui să fie   regenerat și trimis din nou

Dacă este MS-SQL, de exemplu, care generează cea mai mare parte a rezultatelor - atunci re-generarea va profita de unele cache-uri implicite în SQL Server și generațiile ulterioare vor fi mai rapide.

Într-o oarecare măsură, puteți să vă îndepărtați fără să vă faceți griji cu privire la aceste probleme, până când acestea se vor schimba ca probleme "reale" - deoarece platformele pe care le utilizați au grijă de multe dintre blocajele de performanță pentru dvs.

Deci, suna ca și cum ați fi interesat de o soluție care adaugă parametrul "numărătoare de înregistrare" și "ultimul număr de înregistrare" în metoda web. (sau "numărul paginii" și "rezultatele pe pagină")

Acest lucru nu ar trebui să fie prea greu dacă magazinul de suport este serverul SQL (sau chiar mysql), deoarece au construit suport pentru numerotarea rândului.

În ciuda acestui lucru ar trebui să puteți evita orice gestionare a sesiunilor pe server, să evitați orice caching explicită a setului de rezultate și să vă bazați doar pe cache-ul magazinului de asistență pentru a vă menține viața simplă.

Sunt oarecum de acord cu comentariul secret al lui Gek:

Asta se întâmplă deja pentru tine - se numește tcp/ip ;-) Re-implementarea care ar putea fi depășită.

Există momente în care poate doriți să faceți doar acest lucru, dar într-adevăr numai dintr-o perspectivă a UI. Dacă implementați un mod de transmitere a datelor fie către client (prin intermediul unui mecanism de tip pushlets), fie o introduceți în pagini după cum sugerează, puteți încărca apoi un subset cu adevărat mic pe client și apoi construiți ușor UI cu cantitatea totală de date.

Acest lucru conduce la un UI mai rapid și mai rapid (din perspectiva utilizatorului), dar trebuie să evaluați dacă efortul suplimentar va merita ... pentru că nu cred că va fi o muncă nesemnificativă.

Am văzut toate cele trei abordări, paged , stocați și recuperați și împingeți masiv .

Cred că soluția la problema dvs. depinde într-o oarecare măsură de motivul pentru care setul de rezultate este atât de mare și de modul în care este generat. Rezultatele dvs. cresc de-a lungul timpului, sunt calculate la o dată și apoi împinse, doriți să le redați înapoi de îndată ce le aveți?

Abordarea de vizionare

Din experiența mea, folosirea unei abordări de paginare este potrivită atunci când clientul are nevoie de acces rapid la bucăți rezonabile ale setului de rezultate similar cu paginile din rezultatele căutării. Considerațiile aici sunt discuția generală a protocolului dvs., cache-ul întregului set de rezultate dintre solicitările de pagini client și/sau timpul de procesare necesar pentru a genera o pagină de rezultate.

Stocare și recuperare

Stocarea și preluarea este utilă atunci când rezultatele nu sunt accesate aleatoriu, iar setul de rezultate crește în mărime în timp ce interogarea este procesată. Problemele care trebuie luate în considerare aici sunt complexitatea pentru clienți și dacă puteți oferi utilizatorilor rezultate parțiale sau dacă trebuie să calculați toate rezultatele înainte de a returna ceva clientului (gândiți sortarea rezultatelor din motoarele de căutare distribuite).

Push masiv

Abordarea masivă a împingerii este aproape sigur o eroare. Chiar dacă clientul are nevoie de toate informațiile și trebuie să fie împins într-un set de rezultate monolitic, aș recomanda abordarea WS-ReliableMessaging (fie direct, fie prin versiunea simplificată) rezultatele tale. Făcând asta, tu

1. asigurați-vă că piesele ajung la client
2. poate elimina bucata imediat ce primiți o chitanță de la client
3. poate reduce problemele posibile cu consum de memorie din necesitatea de a păstra 5MB de XML, DOM sau orice altceva în memorie (presupunând că nu procesați rezultatele într-un mod de streaming) pe server și pe cele ale clientului. >

După cum au spus și alții, nu faceți nimic până nu cunoașteți dimensiunea setată a rezultatelor, modul în care acestea sunt generate și performanța generală a problemelor actuale.