Vracejí velké výsledky Přes Webservis

hlasů
9

Pracuji na webové služby v okamžiku, a existuje možnost, že vrácené výsledky by mohly být poměrně velké (> 5MB).

Je to naprosto platný pro tento soubor dat bude tento velký a webová služba může být volána sync nebo async, ale já jsem přemýšlel, jaké myšlenky lidí jsou na následující oblasti:

  1. Pokud dojde ke ztrátě spojení, celý resultset bude muset být obnoven a znovu odeslat. Je nějaký způsob, jak mohu udělat nějaký druh „životopis“, pokud dojde ke ztrátě spojení nebo obnovit?

  2. Vysílá sadu výsledků tento velký dokonce vhodné? Že by bylo lepší zavést jakési „stránkování“, kde se generuje resultset a uloženy na serveru a klient si pak mohou stáhnout kousky resultsetu v menších množstvích a znovu sestavit soubor na svém konci?

Položena 15/08/2008 v 01:08
zdroj uživatelem
V jiných jazycích...                            


4 odpovědí

hlasů
3

Viděl jsem všechny tři přístupy, stránkovaného , ukládání a načítání , a masivní tlak .

Myslím, že řešení vašeho problému, závisí do jisté míry o tom, proč vaše sada výsledků je tak velký a jak je generována. Do své výsledky růst v průběhu času, je to počítáno najednou a pak tlačil, chceš, aby je proud zpět, jakmile je máte?

paging Approach

Podle mých zkušeností, s využitím přístupu stránkovací Je vhodné, kdy klient potřebuje rychlý přístup k přiměřeně velké kousky sady výsledků podobný stránek ve výsledcích vyhledávání. Úvahy jsou zde celkově povídavost vašeho protokolu, caching celé sady výsledků mezi požadavky klienta stránek a / nebo doba zpracování trvá generovat stránku výsledků.

Ukládání a načítání

Ukládat a načítat je užitečná, když výsledky nejsou s přímým přístupem a sada výsledků roste co do velikosti, protože zpracování dotazu. Otázky, které je zde v úvahu, jsou složitost pro klienty, a pokud můžete poskytnout uživateli dílčích výsledků, nebo pokud potřebujete vypočítat všechny výsledky, než se vrátí něco pro klienta (myslím třídění výsledků z distribuovaných vyhledávačů).

Massive push

Masivní tlak přístup je téměř jistě chybné. I v případě, že klient potřebuje všechny informace a je třeba ji zasunout monolitické sadě výsledků, bych doporučil užívat přístup WS-ReliableMessaging(buď přímo, nebo prostřednictvím svého vlastního zjednodušené verzi) a Chunking své výsledky. Tím vás

  1. zajistily, že kusy dosáhnou klienta
  2. blok, může hned zbavit, jak se dostanete potvrzení od klienta
  3. může snížit případné problémy s spotřeby paměti z nutnosti zachovat 5MB XML, DOM, nebo co do paměti (za předpokladu, že nejste zpracování výsledků v streamování způsobem) na serveru a klienta stranách.

Stejně jako již bylo řečeno i když nedělají nic, dokud víte, že vaše výsledky nastavenou velikost, jak je generován, a celkový výkon jako aktuální problémy.

Odpovězeno 28/05/2009 v 14:47
zdroj uživatelem

hlasů
2

Neexistuje žádný tvrdý zákon proti 5 Mb jako velikost výsledné sady. Více než 400 Mb může být obtížné odeslat .

Budete automaticky získat asynchronní manipulátory (protože používáte .NET)

zavést určitý druh „stránkování“, kde se generuje resultset a uloženy na serveru a klient si pak mohou stáhnout kousky resultsetu v menších množstvích a znovu sestavit soubor na svém konci

Že už se děje pro vás - je to tzv tcp / ip ;-) Re-realizaci, která by mohla být zbytečná.

Podobně -

Celá resultset bude muset být obnoven a znovu poslal

Pokud se jedná o MS-SQL, například, že se generuje většinu resultsetu - pak re-generovat to využije nějaký implicitní cacheing v SQL Server a následných generací bude rychlejší.

Do jisté míry se můžete dostat pryč s ne starat o tyto problémy, dokud povrch jako ‚skutečné‘ problémy - protože platforma (y), který používáte postarat o spoustě výkonové překážky pro vás.

Odpovězeno 15/08/2008 v 01:18
zdroj uživatelem

hlasů
0

Takže to vypadá, byste měli zájem o řešení, které dodává ‚startovní číslo záznamu‘ a ‚Konečný počet záznamů‘ parametr na vaše webové metody. (Nebo ‚číslo stránky‘ a ‚výsledků na stránku‘)

To by nemělo být příliš těžké, pokud podkladová obchod je SQL Server (nebo dokonce mysql), protože mají vestavěnou podporu pro číslování řádků.

Navzdory tomu byste měli být schopni se vyhnout dělat nějakou správu relací na serveru nedošlo k žádné výslovné mezipaměti sadu výsledků, a jen spoléhat na krycí prodejny ukládání do mezipaměti, aby se váš život jednoduchý.

Odpovězeno 15/08/2008 v 02:40
zdroj uživatelem

hlasů
0

I poněkud nesouhlasím s secretGeek poznámka:

Že už se děje pro vás - je to tzv tcp / ip ;-) Re-realizaci, která by mohla být zbytečná.

Jsou chvíle, kdy budete chtít dělat jen to, ale opravdu jen z hlediska uživatelského rozhraní. Pokud implementovat nějaký způsob, jak buď streamování dat na klienta (přes něco jako pushlets mechanismu) nebo kus ho do stran, jak si navrhnout, pak můžete nahrát nějaké opravdu malá podmnožina na straně klienta a pak se pomalu budovat UI s plná množství dat.

To přispívá k pláštěnku, rychlejší rozhraní (z pohledu uživatele), ale budete muset zhodnotit, zda by další úsilí bude stát za to ..., protože si nemyslím, že to bude zanedbatelné množství práce.

Odpovězeno 15/08/2008 v 01:31
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more