jurgenzz Posted February 20, 2016 Report Share Posted February 20, 2016 Kā bij reiz iekš 'Shoptalk show' => kapēc tērēt savus servera resursos, to visu ģenerējot, ja vieglāk un ērtāk ir padot instrukcijas un lietotājs pats tērē savus resursus, šo visu ģenerējot, kur daudzos gadījumos, šī gala lietotāja resursi būs 2-8x lielāki, par tava servera (ja vēl sāksi rēķināt, ja tu ar saviem resursiem 10+ cilvēkiem reizē mēģināsi uzģenerēt saturu, izdali cik katram tiek patērēts utt..) Kā jurchiks minēja, padod statisku header, footeri + a vēl kaut ko, kas tiek arī nocachots un contentu padod un ļauj gala lietotājam ģenerēt > pēc tam vazājoties apkārt, headers, footers from cache, un pārējo atkal ģenerē lietotājs. Kaut kā tā Quote Link to comment Share on other sites More sharing options...
spainis Posted February 20, 2016 Report Share Posted February 20, 2016 https://blog.twitter.com/2012/improving-performance-on-twittercom Quote Link to comment Share on other sites More sharing options...
Wuu Posted February 20, 2016 Report Share Posted February 20, 2016 https://blog.twitter.com/2012/improving-performance-on-twittercom Es vienmēr apbrīnoju, cik lēni twiiters spēj ielādēt jaunāko saturu uz visām platformām. Lai viņi iet dir** ar saviem ieteikumiem. Quote Link to comment Share on other sites More sharing options...
codez Posted February 20, 2016 Report Share Posted February 20, 2016 Ja jau tie footeri un headeri tik statiski, kāpēc viņus ģenerēt backendā, ja viņu tādā gadījumā var uzģenerēt frontendā, bez papildus informācijas. Quote Link to comment Share on other sites More sharing options...
spainis Posted February 20, 2016 Report Share Posted February 20, 2016 Es vienmēr apbrīnoju, cik lēni twiiters spēj ielādēt jaunāko saturu uz visām platformām. Lai viņi iet dir** ar saviem ieteikumiem. Server side rendering vienmēr tāpat būs ātrāks Client side sanāk: GET some.html noparsējam GET app.js tas izpildās GET latest_tweets (pieņemot, ka ping ir +- normāls, 200ms uz katru request'u, kas ir vismaz 600ms līdz var sākt parādīt saturu) vai arī sākotnējo skatu var norenderēt server side un saturs parādīsies jau ~200ms (tas viss protams atskaitot TCP un SSL handshake'us) Quote Link to comment Share on other sites More sharing options...
briedis Posted February 20, 2016 Author Report Share Posted February 20, 2016 Es vienmēr apbrīnoju, cik lēni twiiters spēj ielādēt jaunāko saturu uz visām platformām. Lai viņi iet dir** ar saviem ieteikumiem. Atver draugiem.lv, tur runā plūsma arī tiek renderēta tīri klienta pusē, un tur ir ļoti daudz JS'a, pasaki, ka lēni ielādē :) Vienkārši nevajag taisīt līki - nevis tāpēc atteikties no renderēšanas klienta pusē, bet noselektē datus servera pusē, atgriez ar pamata lapas ielādi JSON datus saturā un JS uzreiz līdz ar lapas ielādi uzrenderē. Tad, kad vajag atjaunot datus, tad izmanto ajax un pārlādē to, ko vajag. Quote Link to comment Share on other sites More sharing options...
codez Posted February 20, 2016 Report Share Posted February 20, 2016 Server side rendering vienmēr tāpat būs ātrāks Reālā situācijā nē. Teiksim lietotāja, reālais tīkls ir 0.3 MB/s. Dati raw formā aizņem 60kB, bet HTML formā 300 kB, bet teiksim pliks htmls 30 kB Ja renderē servera pusē, tad ir 100ms html requests + 1000 ms datu pārraide = 1200ms Ja renderē klienta pusē, tad: 1. pieprasījums 100ms html requests + javascript sāk lādēties jau pēc 10ms, jo html tiek pārsēts tik, cik jau ielādēts + 100ms js faila requests + 100ms js faila trafiks + 100ms ajax requests + 200ms ajax trafiks = 610ms taču nākamajā requestā, html ir nokešots, js ir nokešots un ir tikai 100ms ajax requests + 200ms trafiks = 300ms Quote Link to comment Share on other sites More sharing options...
spainis Posted February 20, 2016 Report Share Posted February 20, 2016 1. pieprasījums 100ms html requests + javascript sāk lādēties jau pēc 10ms, jo html tiek pārsēts tik, cik jau ielādēts + 100ms js faila requests + 100ms js faila trafiks + 100ms ajax requests + 200ms ajax trafiks = 610ms Static content's stāv uz tā paša domēna, uz kura atrodas main content? Ja nē, tad vēl skaitām iekšā TCP handshake'u, SSL handshake'u(+optional DNS lookup) taču nākamajā requestā, html ir nokešots, js ir nokešots un ir tikai 100ms ajax requests + 200ms trafiks = 300ms Tā gan nebūs, tāpat būs jātaisa GET requests, lai pārbaudītu resursu(serveris atgriež 304), tāpatās ir jāveic roundtrips līdz serverim Tagad gadījies kā nē, bet PINGS ir 500ms Renderējam servera pusē: 250ms līdz serverim + 1250ms atpakaļ Client side: 250 + 100 + 250 lai dabūtu HTML'u, 250 + 100 + 250, lai dabūtu JS un 250 + 200 + 250ms, lai izpildītu AJAX(pieņemot, ka viss stāv uz viena domēna) Quote Link to comment Share on other sites More sharing options...
jurchiks Posted February 20, 2016 Report Share Posted February 20, 2016 >Reālā situācijā nē. >Teiksim lietotāja, reālais tīkls ir 0.3 MB/s. Jā, ļoti reāla situācija. Ja tavi apmeklētāji ir no Āfrikas. Quote Link to comment Share on other sites More sharing options...
codez Posted February 20, 2016 Report Share Posted February 20, 2016 (edited) Tur, kur pings ir 200ms (vai 500ms, kā te kāds piedāvā), tur arī tāds ir reālais ātrums. Normāli pings ir 10 - 30ms. Paņem šo un saliec kopā ar 10 Mb/s interneta pieslēgumu un tev sanāks tas pats, ka servera pusē ģenerēts variants ir 2-4 reizes lēnāks. Edited February 20, 2016 by codez Quote Link to comment Share on other sites More sharing options...
spainis Posted February 21, 2016 Report Share Posted February 21, 2016 (edited) 10-30ms pings uz ārzemēm tev nekad nebūs, teorētiski, piemēram, lowest RTT uz londonu(pieņemot, ka distance ir +- 2000km) ir ~20ms, bet tas ir optiskais savienojums bez jebkādiem citiem delay'iem(tīkla kartēm, switchiem, router'iem), reāli būs 50+ vismaz, atkarībā no datu centra utt. Uz USA east cost RTT būs vismaz 70ms(šitas ir straight line no Rīgas līdz New York) (Gaismas ātrums optice fiber ir ~0.7 no gaismas ātruma vakūmā, kas rezultējas ~2 * 10^8m/s) Edited February 21, 2016 by spainis Quote Link to comment Share on other sites More sharing options...
codez Posted February 21, 2016 Report Share Posted February 21, 2016 (edited) Man pings uz google.com - 30ms pings uz tvnet.lv - 9ms Ja mēs runājam par reālām situācijām, tad diez vai tu liksi serveri havaju salās, ja tev būs LV auditorija. Bet, ja projekts būs milzīgs un auditorijas no daudzām vietām, tad attiecīgi CDN + geo DNS serveriem. P.S. Pings uz google.com caur mobīlo netu 120ms, bet ātrums attiecīgi arī zem 1MB/s Edited February 21, 2016 by codez Quote Link to comment Share on other sites More sharing options...
Wuu Posted February 22, 2016 Report Share Posted February 22, 2016 Tas protams atkarīgs no lapas uzdevuma, bet jāsaprot, ka klienta puse mūsdienās ir ļoti spēcīga un pielietojums var būt plašs. Kādreiz dzenāju CSV failus uz serveri un konvertēju, tagad visu daru klienta pusē. Starp React komponentiem dalos ar base64 failu stringiem. Būtībā, servera puse tiek piesaukta, tikai kad nepieciešams kaut ko konkrēti saglabāt, vai nolasīt. Bet ja darbs notiek ar TEMP klienta failiem, to visu, mierīgi var izdarīt klienta pusē, neaiztiekot serveri. Quote Link to comment Share on other sites More sharing options...
e-remit Posted February 22, 2016 Report Share Posted February 22, 2016 Starp React komponentiem dalos ar base64 failu stringiem. Būtībā, servera puse tiek piesaukta, tikai kad nepieciešams kaut ko konkrēti saglabāt, vai nolasīt. Un pēc tam lietotāji brīnās, kāpēc pārlūks norij visu datora atmiņu, lai cik liela tā būtu... Quote Link to comment Share on other sites More sharing options...
Wuu Posted February 22, 2016 Report Share Posted February 22, 2016 (edited) Un pēc tam lietotāji brīnās, kāpēc pārlūks norij visu datora atmiņu, lai cik liela tā būtu... Pierādi, un tad mētājies ar apgalvojumiem. Neredzu atšķirību starp atmiņas patēriņu CSV datiem, kas uz klienta, vai servera konvertēti un attēlojas klienta pusē. Edited February 22, 2016 by Wuu Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.