Exekveras javascript i en ascx-sida lokalt eller server-side?

Permalänk
Medlem

Exekveras javascript i en ascx-sida lokalt eller server-side?

Tanken slog mig när jag noterade prestandaproblem i en viss funktion.

Användaren trycker på en knapp, "Sök", varpå en javascript-funktion på sidan anropas. Denna search() bygger upp ett dataset via ett webbservice-anrop till en databasprocedur (som alltså returnerar ett antal rader beroende på användarens input).

Sedan byggs en droplista upp baserat på innehållet i ovanstående dataset.

Är det många rader tar det längre tid att generera droplistan än om det är få rader, det är inte så konstigt.

Frågan är om funktionen "search()" jag nämner ovan drar kraft från användarens maskin eller om den körs på webbservern? Dvs. är hastigheten droplistan genereras på avhängig den lokala datorn eller webbserverns prestanda?

Tacksam för svar!
/SSB

Permalänk
Medlem

Båda. JavaScript körs i browsern, web servicen körs på servern. För att se hur lång tid JavaScriptet tar kan du skriva en dummy-funktion som bara returnerar datan och för att testa hur lång tid databasfrågan tar kör du den direkt mot databasen. Problemet kompliceras ju litet av att det introduceras fördröjningar i alla steg i processen.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Medlem

Antagligen är kommunikationen mellan klient och server flaskhalsen, ju större datamängd desto mer säker kan du vara på att det är där exekveringstiden används (jag ska reservera mig för så stora datamängder att klientens RAM tar slut när JavaScriptet ska presentera datat, då lär det bli en flaskhals).

Permalänk
Medlem

Tack för svaren, mycket uppskattat.

Är det någon skillnad om koden ligger i webbservicens .cs-fil istället? Då körs den väl server-side? (Enligt Phod tolkar jag det som så).

Det rör sig inte om några ofantliga mängder data. Får användaren mer än 100 träffar ritas inte droplistan upp utan användaren blir uppmanad att begränsa sökningen.

Kör man enbart proceduren får man fram svaret på cirka 2 sekunder, men när man kör frågan i sin helhet från klienten kan det ta upp till 10-15 sekunder som värst. Ibland går det på bara 2-3 sekunder även från klienten.

Det var därför jag började fundera kring klient/server-frågan.

Baserat på svaren låter det som att det först och främst är anslutningen mellan klienten och servern som är dålig och i andra hand att det är dålig hårdvara på klientsidan.

Skall försöka leta upp en dålig respektive bra dator för att se hur pass mycket det skiljer sig åt

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av SSB
Tack för svaren, mycket uppskattat.

Är det någon skillnad om koden ligger i webbservicens .cs-fil istället? Då körs den väl server-side? (Enligt Phod tolkar jag det som så).

Det rör sig inte om några ofantliga mängder data. Får användaren mer än 100 träffar ritas inte droplistan upp utan användaren blir uppmanad att begränsa sökningen.

Kör man enbart proceduren får man fram svaret på cirka 2 sekunder, men när man kör frågan i sin helhet från klienten kan det ta upp till 10-15 sekunder som värst. Ibland går det på bara 2-3 sekunder även från klienten.

Javascript kommer ALLTID att exkeveras på klienten och asp ALLTID på servern. Eftersom det ibland går snabbt även när du kör hela proceduren så verkar anslutningen server-klient vara flaskhalsen.

Eventuellt kan du ju rita upp dropplistan direkt i HTML på servern och returnera den så slipper javascriptet generera den, men tror inte att det spelar någon roll

Visa signatur

Windows XP Pro SP2 x32 | Ubuntu x64 | Firefox | Adobe Photoshop CS2 | Eclipse | Starcraft Broodwar
(X)HTML | CSS | XML | PHP | Java | C++ | vim script |
Daniel Örn, Eagleorn | Google is my friend, and he will be Yours to if You ask him »

Permalänk

Det kan väl även vara värt att kolla om du kan optimera databasproceduren, för att på så sätt få ner väntetiden lite? Har ju ingen aning hur komplex din sqlfråga är, men 2 sek bidrar ju iaf ganska mycket.

Permalänk
Medlem

Är det ett ajaxanrop som search() använder sig av, som i sin tur uppdaterar dropdownen? Eller laddas sidan om på nytt och search() submittar sidan så den laddas om på nytt?
Är det inte några större data som skickas (som 100 resultat till en dropdown) så är det INTE kommunikationen mellan klient och server som är flaskhalsen.

Permalänk
Medlem

DOM-manipulering i Javascript är fruktansvärt segt (på en slö klient blir det väldigt tydligt), så jag skulle skött så mycket som möjligt backweb, och låtit JS enbart presentera informationen. Men i och med att man inte har fått se någon kod, så är det svårt att säga om det är Javascript eller kommunikationen som är flaskhalsen.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av bjornie
DOM-manipulering i Javascript är fruktansvärt segt (på en slö klient blir det väldigt tydligt), så jag skulle skött så mycket som möjligt backweb, och låtit JS enbart presentera informationen. Men i och med att man inte har fått se någon kod, så är det svårt att säga om det är Javascript eller kommunikationen som är flaskhalsen.

Istället för DOM-manipulering kan man oftast använda innerHtml istället vilket går betydligt snabbare.
http://www.quirksmode.org/dom/innerhtml.html

Permalänk
Medlem

Ja, självklart - men det beror ju också på i vilket format informationen skickas från webservicen. Är det JSON går det ju ganska smärtfritt, men är det XML så måste man använda DOM-funktionalitet på XML:en som kommer in...