Jump to content
php.lv forumi

PHP un templeitu sistēmas


briedis
 Share

Recommended Posts

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ē.

Orly? T.i. tu gribi teikt, ka ja tu ar HTML norenderē milzīgu blāķi un tad to pašu blāķi pieprasi no ar AJAX un renderē frontendā, lietojums būs tāds pats? :> I beg to differ.

Link to comment
Share on other sites

  • Replies 111
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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ē :)

Šāds apgalvojums gan ir diezgan subjektīvs (uz lietotāja sajūtām balstīts). 

 

 

Šeit daži grafiki no tiem pašiem draugiem.lv (t.i. real world "keiss")

 

 

post-31-0-82718900-1456153156.png

 

t.i. secinājums var izdarīt dažādus, bet fakts ir ka serverside average ir 30ms kur klienta puse ir 3 sec .. Attiecīgi var domāt par to kuru galu optimizējot teorētiski iespējams gūt labākus "panākumus".

graf.png

Link to comment
Share on other sites

Uz USA east cost RTT būs vismaz 70ms(šitas ir straight line no Rīgas līdz New York)

Tā rupji rēķinot visam kas ir pāri okeānam 0.2 sec tīklā roundtrips aiziet viennozīmīgi  .. 

 

 

Man pings uz google.com - 30ms

pings uz tvnet.lv - 9ms

Abet jocīgi (ka tik daudz).. google jau LV auditorijai savu cache instanci hostē tepat Telijas DC

 

 

 

"Every project that creeps up is even more ambitious than the next. It all starts with a core module and 400 plugins for this module." - šis ir kas mani visvairāk tracina, atliek tikai piekrist developerim, ka vajag uzlikt uz servera composeri vai npm, kā sākas miljons un viena dependency ķeska utt :)

Link to comment
Share on other sites

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ē.

Redzi, vienmēr ir jautājums par to, cik rūpīgi programmētājs skatās līdzi tam, kas notiek ar atmiņā ielādētajiem objektiem. Nevajag nemaz tik daudz aizmirst, lai pārlūka viena cilne aizņemtu dažus simtus megabaitus, jo JS piedāvā plašas iespējas veidot memory leakus.

Piemēram, tu pat uzmanīgi nepaskatījies, kuru tevis teikto teikumu es nocitēju. Un, ja tu ar tikpat lielu "uzmanību" mētā pa dažādām koda daļām bināro failu base64 stringus, nav izslēgts, ka esi atmiņā izveidojis vairākas šāda stringa kopijas un tad veiksmīgi par tām "piemirsis". Tāpat ar tevis pieminēto CSV - svarīgi, kas ar to CSV un tā starpproduktiem notiek pēc renderēšanas.

Link to comment
Share on other sites

Feins raksts. Mani arī baigi besī tas, ka ļoti daudziem npm packages ir vesela kaudze ar dependencies, kuros gandrīz katrā ir tikai viens īss skripta failiņš vienai sīkai funkcionalitātei.

Composer packages arī ir līdzīga slimība (mēdz būt daudz dependencies), lai gan ne tuvu tik traki.

Link to comment
Share on other sites

Orly? T.i. tu gribi teikt, ka ja tu ar HTML norenderē milzīgu blāķi un tad to pašu blāķi pieprasi no ar AJAX un renderē frontendā, lietojums būs tāds pats? :> I beg to differ.

 

Pierādi :> Ikdienā strādājam ar +100mb failiem, no lietotājiem dzirdu tikai pozitīvas atsauksmes par to ka ielādēs formas ar POST ir aizvāktas.

Tiko notestēju, 120mb fails klienta pusē ielādējās 2 sekundēs.

 

Un beigās, ko ar to blāķi darīsi? Tāpat vajadzēs piejūgt meklēšanu, kaut vai banālas lapaspuses. Visu darīsi ar serveri? Katru reizi sūtīsi jaunu pieprasījumu un gaidīsi atbildi?

 

Redzi, vienmēr ir jautājums par to, cik rūpīgi programmētājs skatās līdzi tam, kas notiek ar atmiņā ielādētajiem objektiem. Nevajag nemaz tik daudz aizmirst, lai pārlūka viena cilne aizņemtu dažus simtus megabaitus, jo JS piedāvā plašas iespējas veidot memory leakus.

Piemēram, tu pat uzmanīgi nepaskatījies, kuru tevis teikto teikumu es nocitēju. Un, ja tu ar tikpat lielu "uzmanību" mētā pa dažādām koda daļām bināro failu base64 stringus, nav izslēgts, ka esi atmiņā izveidojis vairākas šāda stringa kopijas un tad veiksmīgi par tām "piemirsis". Tāpat ar tevis pieminēto CSV - svarīgi, kas ar to CSV un tā starpproduktiem notiek pēc renderēšanas.

 

Oj, pasmējos, nopietni, izlasi kā javascripts glabā datus atmiņā un tad raksti... dievs pasarg...

 

Runājot par paketēm, jebkurš var jebko piedrazot ja labi grib. Nav atkarīgs no valodas vai veida.

 

Man ir šādi:

"dependencies": {
    "history": "1.17.0",
    "react": "0.14.0",
    "react-dom": "0.14.0",
    "react-router": "1.0.3",
    "socket.io-client": "1.4.0"
  }

Servera pusē

  "dependencies": {
    "mongoose": "4.3.5",
    "socket.io": "1.3.7",
    "winston": "2.1.1"
  }
Edited by Wuu
Link to comment
Share on other sites

Runa ir par to, ka šīm te paciņām vēl parasti ir miljons dependenciju ar dependencijiem.

 

Man ir šitāds, uzlikts standalone:

"dependencies": {
    "gulp": "^3.8.8",
    "laravel-elixir": "^3.0.0"
  }
Tagad paskaties, kas zem "node_modules/gulp/node_modules" atrodas... un kas atrodas katram no tiem zem "node_modules". Nebija ilgi jāmeklē, un vieta alfabētā jau parāda, ka tas ir tikai sākums: "node_modules/gulp/node_modules/chalk/node_modules/has-ansi/node_modules/ansi-regex"

 

119 MB. 29780 faili. Lai salipinātu CSS un JS failus un pārkopētu tos citā folderī.

post-742-0-36050100-1456222407_thumb.png

Link to comment
Share on other sites

Pierādi :>

https://github.com/Addvilz/rendering_test

 

Hīps ir gandrīz x2, 11289% uz scripting un ja nolevelo loading (kā tas normāli būtu, nevis katru reizi lasa džeisonu = fuck this, nav man vaļas optimizēt te), tad vispār viss ir acīmredzams.

 

Case closed.

 

Ikdienā strādājam ar +100mb failiem, no lietotājiem dzirdu tikai pozitīvas atsauksmes par to ka ielādēs formas ar POST ir aizvāktas.

Ko?

 

Tiko notestēju, 120mb fails klienta pusē ielādējās 2 sekundēs.

No localhosta? Ar optiku 400? :P How about https://github.com/tylertreat/comcastun/vai https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/network-conditions?hl=en uz aDSL 10/1

 

Un beigās, ko ar to blāķi darīsi? Tāpat vajadzēs piejūgt meklēšanu, kaut vai banālas lapaspuses. Visu darīsi ar serveri? Katru reizi sūtīsi jaunu pieprasījumu un gaidīsi atbildi?

LOL?! Ko tu piedāvā? Nogāzt visu info frontendā? Tu saproti, ka ne visi te blogus taisa?

 

Oj, pasmējos, nopietni, izlasi kā javascripts glabā datus atmiņā un tad raksti... dievs pasarg...

Javascripts neko neglabā, glabā un menedžē dzinis + GC. Un viņam ir vismaz daļēja taisnība, jo viena lieka reference un tavs 100mb fails ko tu tur ielādēji nekad netiks līdz nākamajam GC ciklam. Vai arī 100 mazi failiņi, katrs pa 1mb vien...

Link to comment
Share on other sites

Tu vispār lasīji kaut ko iepriekš? XD Ir lielu failu apstrāde frontendā, sūta uz serveri tikai kaut kādus finālā vajadzīgos datus. Līdz tam operācijas notiek lokāli, tur arī 120 MB izparsēšana 2 sekundēs un viss pārējais.

 

Acīmredzot ne pietiekami dziļi. :D Ā, tad sanāk ka jams ielādē kaut kādu usera failu pārlūkā, tad palaiž kaut kādu JS pret to failu un pēc tam rezultātu nosūta uz serveri? :D

 

Ja tā, tad es vispār nekomentēšu. Tas pamatā automātiski nozīmēs banu, jo bez betona stila rupjībām te īsti vairs neiztikt... 

 

Edit: Kavacky, nu neesmu tomēr dzēris. Jams teica, ka nav atšķirības starp atmiņas lietojumu starp datiem kas tiek apstrādāti un renderēti frontend + backend, vai frontend only. Which is sort of bullshit. Also, ātrums ir paralēls client side resursiem. Planned scaleability yayy!

Edited by F3llony
Link to comment
Share on other sites

Kavacky, kam tev zem dependencies gulp un laravel-elixir? Tas viss iet zem devDependencies (Klients par to visu nekad neuzzinās), un man reāli pajāt, ja izstrādājot produktu man būs 10GB ar failiem kas paātrina procesu, tas būs to vērts.

 

 

F3llony...

 

Piemērs ar 120mb CSV faila ielādi un apstrādi (Izvadīt key, un pirmos 8 simbolus) klienta pusē. Viss lielāko laiku aizņem datu izvade! (Neviens normāls cilvēks 52k tabulu rindas vienā lapā nerāda)  Ja attēlo normāli lapaspuses, tad ir FileReader ielādes laiks.

 

http://postimg.org/image/s6oyhudjf/full/

 

3.5 sekundes.

 

Pārējie var turpināt lipināt POST formas un sūtīt datus turpu šurpu. Man tā ir vieglāk un cilvēkiem darbs raitāk iet uz priekšu. (Pietam man ir Windows serveris ar kaut kādu gatavu mysql,php,apache uzparikti kas darbojas uz malkas, spriežot pēc ātruma, bet es tur neko nevaru mainīt.) 100mb uz viņu sutās apmēram minūti.

Edited by Wuu
Link to comment
Share on other sites

Piemērs ar 120mb CSV faila ielādi un apstrādi (Izvadīt key, un pirmos 8 simbolus) klienta pusē. Viss lielāko laiku aizņem datu izvade! (Neviens normāls cilvēks 52k tabulu rindas vienā lapā nerāda)  Ja attēlo normāli lapaspuses, tad ir FileReader ielādes laiks.

 

http://postimg.org/image/s6oyhudjf/full/

 

3.5 sekundes.

 

Pārējie var turpināt lipināt POST formas un sūtīt datus turpu šurpu. Man tā ir vieglāk un cilvēkiem darbs raitāk iet uz priekšu. (Pietam man ir Windows serveris ar kaut kādu gatavu mysql,php,apache uzparikti kas darbojas uz malkas, spriežot pēc ātruma, bet es tur neko nevaru mainīt.) 100mb uz viņu sutās apmēram minūti.

 

Bet tu saproti, ka diskusija ir pilnīgi par kaut ko citu? E.g. keisu, kad dati JAU ir uz servera, nevis ka tu datus ielādē no failu sistēmas lokāli? Seriously, cik tādu keisu ir webā? Preview bildes? Vēl kaut kas? Tas ir suņam saprotams, ka ielādēt failu no failu api ir pamatā instant deal. Bet kāds šim specifiskajam keisam ir sakars ar "visu nu bāzīs un renderēs frontendā" es galīgi nesaprotu.

 

Tajā pašā laikā, ko tu darīsi ja uploads ir diezgan komplekss binary report no kaut kādas citas legacy sistēmas (viens no maniem real world case - vienā dumpā sajāts XML un custom binary, eksporta reports pāris reizes mēnesī un sver ap 400M) un pirmo pārdesmit baitu vietā tev jaizvada gigantiska tabula analīzei? T.i. tu darīsi to frontendā vai tomēr ielādēsi failu uz servera (ar skaistu uploaderīti) kur ar smuku async procesu to izmalsi, ielādēsi DB un tad attēlosi cilvēkiem gatavu rezultātu?

 

Tavs keiss ir edge keiss. Edge keisi kā likums pārējiem ir maz relevanti.

Link to comment
Share on other sites

400mb toč frontendā nebāzīšu, tas ir ektrēmi, pat 10mb ir diezgan 0.99999% gadījums. Es vienkārši ar piemēru pierādu, ka frontends neatpaliek, pie prastas apstrādes būs ātrāks, par datu nosūtīšanu uz serveri un atpakaļ.

Un nekādas problēmas ar atmiņu nav. Man viss fronteds ir React'ā sapakots, pat uz sūda planšetēm, griežas un darbojas 100% ātrāk par standarta "pie katra klikšķa novelc svaigākos failus".

 

Man liekas, ka šis vairāk ir pieraduma faktors. Ja datu apstrāde, tad tikai servera pusē - frontends vairāk par css un html neko nemāk.

 

Mierīgi, klienta pusē ģenerēju CNC programmas un apstrādāju medicīniskos legacy XML'us no rentgena diagnostikas :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...