- persicsb blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Amit a gyors fejlesztésen nyersz, elbukod az áramszámlán. :)
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
Azért a g+ még mindig fényévekkel gyors, és nem kényszerültek ilyenekre.
Igaz nincs annyi user, de a facebook nem az userek száma miatt lassú. (imho)
pch
--
http://www.buster.hu "A" számlázó
--
- A hozzászóláshoz be kell jelentkezni
G+-nak a gépparkja is nagyobb, nem?
(Nem tudom a G+ miben van írva, a GMail az server-side javascript.)
- A hozzászóláshoz be kell jelentkezni
Reszben, reszben meg python.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
"GMail az server-side javascript"
links or didn't happen.
szerk. okes, megtalaltam.
"At the USENIX annual conference last month, Gmail engineer Adam de Boor surprised the audience by noting that the company's Gmail service was written entirely in JavaScript, and that all of its code, around 443,000 lines worth, was written by hand."
http://www.infoworld.com/d/developer-world/google-executive-frustrated-…
De itt a vezeto fejleszto azt mondja, hogy nem:
http://www.quora.com/What-programming-languages-is-Gmail-implemented-in
http://en.wikipedia.org/wiki/Paul_Buchheit
- A hozzászóláshoz be kell jelentkezni
Olyan nagy különbség lenne a fordított PHP és JVM class-ok között? Ez meglepő, mivel a fordított PHP kód már gépi kód, JVM meg továbbra is byte kód.
- A hozzászóláshoz be kell jelentkezni
A PHP kód mióta gépi kód? A JVM pedig a legtöbb implementációban JIT-et használ, azaz az tényleg gépi kód.
- A hozzászóláshoz be kell jelentkezni
Olvasd el még egyszer: "a fordított PHP" kód, a faszbúk hiphop fordítójával lehet első lépésben C++ kódot generálni. Onnan meg gépi kód és natívan fut a procin.
JVM class meg byte kód, először értelmezni kell azt és JIT-el fordítani. Ez overhead az előbbihez képest.
- A hozzászóláshoz be kell jelentkezni
Most megint az van hogy megszakértjük a HUP-ról a Facebook technológiai döntéseit? Rendben van hogy pár száraz tényt feltárunk (amivel amúgy mindenki tisztában van), de nem tudjuk a döntés mögöttes hátterét, mert nyilván nem véletlenül csinálják.
- A hozzászóláshoz be kell jelentkezni
NEM. Saját project-et szeretnék, nagy forgalmú webshop jelleggel.
Érdekel, melyik tudásomat fejlesszem tovább. PHP-ül és Java-ul is tudok. Szeretnék már az elején jól dönteni, hogy melyiket válasszam a megvalósításhoz.
- A hozzászóláshoz be kell jelentkezni
Ennyi információból nem derül ki semmi.
A performance kérdés olyan, hogy "don't argue, benchmark". Nem érdemes előre tervezni itt, olyan helyen lehet bottleneck az alkalmazásodban, ahol nem gondolnád. Akár még a végén a filerendszer is lehet a sebesség gátja. A lényeg: nem tudsz az elején jól dönteni. Egy alkalmazásnál csak futásidőben tudod megmondani, mi okozza a lassúságot. Akár egy rossz DB-index is lehet, nem tudni ezt előre, nem ismertek a használat mintázatok.
Viszont egy másik aspektust megnézve, Javaban akkora az ecosystem (akár csak akkor is, ha a nyílt forráskódú komponenseket, libraryket tekintem), hogy buta választás lenne NEM Javaban csinálni.
- A hozzászóláshoz be kell jelentkezni
"A performance kérdés olyan, hogy "don't argue, benchmark". Nem érdemes előre tervezni itt, olyan helyen lehet bottleneck az alkalmazásodban, ahol nem gondolnád."
Azért ez elég sarkos kijelentés. Szerintem igenis lehet előre tervezni a már rendelkezésre álló információk alapján, pl. említed a fájlrendszert, aminek az áteresztő képességét már akkor meg lehet mérni, amikor az alkalmazásból még egy sor nem készült el.
- A hozzászóláshoz be kell jelentkezni
Az FS teljesítményét is befolyásolja a használati minta: sok kis file-t fognak feltölteni, keveset, de nagyot, mennyi lesz az írás/olvasás aránya, fontos-e a hozzáférési időket is nyilvántartani, vagy csak a módosítási időket stb. Esetleg az is számít, hogy az egyes mért mennyiségeknek mekkora a szórása. Van ahol az a fontos, hogy a szórás kicsi legyen, de az nem számít igazán, mekkora a várható érték, van ahol az mindegy, csak éppen a legmagasabb mért mennyiség legyen egy bizonyos szint alatt.
Sok mindent megmérhetsz, de egyértelmű eredményt egyik mérés sem fog adni. Van ami ebben erős, van ami abban, a használati minták üzem közben majd megmutatják, mire van szükség.
- A hozzászóláshoz be kell jelentkezni
Viszont ismered a rendszer felé támasztott igényeket, ebből tudod, hogy milyen paramétereket érdemes figyelembe venni. Elvégzed a megfelelő méréseket, ebből el tudod dönteni, hogy melyik használati minta lehet hatékonyabb. Nyilván nem mehetsz biztosra, de inkább mérések befolyásolják a döntéseket, mint a dobókocka.
- A hozzászóláshoz be kell jelentkezni
Az igényeket mindig csak részben ismered,a használati mintákat üzem közben generálják majd a felhasználók. Azt meg nem tudhatod előre.
- A hozzászóláshoz be kell jelentkezni
Azert nem teljesen zoldmezos a dolog, vannak patternek, amiket ki lehet zarni, peldaul egy ilyennek nem olyan a terhelese, mint mondjuk egy VPS clusternek, vagy mondjuk egy backup szervernek. Tehat lehet talani olyan parametereket, amik ha jok, akkor nagy valoszinuseggel jol fog teljesiteni a rendszer. Nyilvan minden rendszer egyedi, azonban mindig lehet talalni hozza egy kozel hasonlo mintat, ami - ha nem is uberalles megoldas - ad egy jo tampontot/kiindulopontot.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Egy biztos, előre kell döntenem az egyéb programokból és netes összehasonlításokból tanult minták alapján. Kevesen tehetik meg hogy egy project-et megírjanak pl PHP-ben, Python-ban és Java-ban is. Aztán meg benchmark és eldöntik melyik jobb.
Manapság PHP-ben vagyok tapasztaltabb, de a Java felé húzok.
- A hozzászóláshoz be kell jelentkezni
Ez igaz PHP-re és .NET-re is. Jó, mondjuk PHP-hez a toolok fosok mind Java, mind .NET-hez képest.
Meg mondjuk az is jó kérdés, hogy kinek mi a nagy forgalmú webshop.
(Ismerős pl. azzal tud az őrületbe kergetni néha, hogy "van 5-6 db kb. napi 200 egyedi látogatóval rendelkező honlap" és olyan optimalizációs dolgokon agyal folyton, ami napi 20000 egyedi látogatónál már esetleg talán felmerül.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Természetesen Java.
Bár nemrég kezdtem el vele foglalkozni, de akkora a minőségbeli ugrás a PHP-hoz képest (toolok, debug, tesztelés, stb), hogy nem is értem, hogy eddig miért nem ezt használtam.
- A hozzászóláshoz be kell jelentkezni
Arrol nem is beszelve, hogy ma mar ugy sebessegben mint memoriafoglalasban egyaltalan nincs kulonbseg a ket nyelv kozott - ha az alkalmazas jol van megirva. Valamint a Java skalazhatosaga egy picit jobb.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
persicsb lentebb ezt írta:
""Igen, az a kod gyorsabb, de ez csak az egyik tenyezo. De sokkal tobb memoriat eszik:
"The x64 machine code that the translator generates consumes approximately ten times as much memory as the corresponding HHBC."
https://www.facebook.com/note.php?note_id=10150415177928920""
OK, ez nem az interpretált, hanem a fordított PHP állományokra vonatkozik.
- A hozzászóláshoz be kell jelentkezni
Ez egy implementacio. Sok esetben a nyelvet osszetevesztik annak implementaciojaval. Igen, az Oracle-fele JVM es JRE az elterjedt, ugyanigy PHP-bol is a php.net fele az A PHP, de nyelv es runtime kozott eg es fold a kulonbseg. Olyan, mintha azt mondanank, hogy C = gcc.
- A hozzászóláshoz be kell jelentkezni
Ugyan ez PHP meg félig-meddig irreleváns meg úgy egyébként is, de azt hiszem, a legnagyobb bottleneck még mindig a balfasz "nem amatőr" takonygyártó kóder.
Amikor pár hetes munkával effektíve 25-30x-osára lehet gyorsítani valamit, illetve 4-5x-ös gyorsítás mellett gyakorlatilag ötödölni a gépigényt...
Másrészt brutális erőforrás van egy mai gépben.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
te ilyen windows-berenc vagy, hogyhogy nem valami ms-tech? ;)
- A hozzászóláshoz be kell jelentkezni
Nem igaz! Ő Apple- és Opera-bérenc. :)
- A hozzászóláshoz be kell jelentkezni
Akkor meg plane. Az Apple szempontjabol a Java legacy technologia.
- A hozzászóláshoz be kell jelentkezni
Milyen servlet container-t használsz? Anno Tomcat / Catalina volt használatban. Manapság már biztos több elérhető lehetőség van.
- A hozzászóláshoz be kell jelentkezni
Ez hogy jon ide? Mintha csak Servletkent lehetne Javaban programozni illetve mintha PHP-ban csak weboldalakat lehetne csinalni.
- A hozzászóláshoz be kell jelentkezni
Weboldalt szeretnék létrehozni. Adódott a servlet container, mivel biztos hogy nem sajátot írtál. Kérdezhettem volna keretrendszert inkább.
- A hozzászóláshoz be kell jelentkezni
Amig standard Servlet API-t hasznalsz, addig mindegy, mi a servlet container, hiszen ha nem tetszik az A, akkor fogod es kicsereled a B-re. Pont ez a lenyege a szabvanyos API-knak :) Akar az is lehet, hogy Tomcat alatt fejleszted, de futni mondjuk Jetty alatt fog. Tok mindegy, amig szabvanyos es nem hasznal container specifikus dolgokat.
- A hozzászóláshoz be kell jelentkezni
Ezzel tisztában vagyok. Kérdésem inkább arra irányult, melyikkel van jó tapasztalatod. Konfigurálhatóság, teljesítmény, hibakeresés támogatása.
- A hozzászóláshoz be kell jelentkezni
Nekem a Tomcat tokeletesen megfelelt, ha pedig komolyabb dolog kell, akkor GlassFish.
- A hozzászóláshoz be kell jelentkezni
+1 annyi kitetellel, hogy ha cel a memoria optimalizaltsag, akkor lehet egy kort futni meg a Jetty-vel is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Igen, az a kod gyorsabb, de ez csak az egyik tenyezo. De sokkal tobb memoriat eszik:
"The x64 machine code that the translator generates consumes approximately ten times as much memory as the corresponding HHBC."
https://www.facebook.com/note.php?note_id=10150415177928920
A HipHop compilert azota amugy lecsereltek HHVM-re, ami egy bytecode alapu virtualis gep.
http://ajaxian.com/archives/hiphop-virtual-machine-for-php
- A hozzászóláshoz be kell jelentkezni
"JVM class meg byte kód, először értelmezni kell azt és JIT-el fordítani. Ez overhead az előbbihez képest."
Az első futtatásig. Nyilván nem fog minden futáskor lefutni a jit compiler, hiszen akkor az egésznek nem sok értelme lenne.
- A hozzászóláshoz be kell jelentkezni
A nih ott sem ismeretlen fogalom, de vegul sikerul majd feltalalni ezt:
http://quercus.caucho.com
- A hozzászóláshoz be kell jelentkezni
Azért nem feltétlenül. Ahogy a címben is van: Java (pontosabban a JVM).
- A hozzászóláshoz be kell jelentkezni
A quercus kicsit mas tema. Az csak webes kornyezetben teszi hasznalhatova a PHP nyelvet, de nem azt csinalja, hogy a PHP kodokat JVM bytecode-ra forditja, hanem Java osztalyokra, amibol majd JVM bytecode lesz.
Valamint a quercus alapbol, hackelgetes nelkul csak Servlet kornyezetben fut, en el tudom kepzelni, hogy a Facebooknak van egy csomo nem webes kornyezetben futo adminisztrativ PHP szrkiptje is. Valamint nem csak Servletbol all a vilag, HTTP alapu kiszolgalast mashogy is lehet csinalni Java alapon, csak ahhoz sajat API kell.
Csak arrol volt szo, hogy JVM alapon fognak futni a PHP kodok. Hogy a PHP kodok szamara ki biztositja a webes infrastrukturat (azaz a CGI alapu kornyezeti valtozokat, query parametereket stb.), az teljesen mas kerdes, nem kell annak Servlet containernek lennie.
Szoval ez nem "Not Invented Here", hanem "We Need Something Else".
- A hozzászóláshoz be kell jelentkezni
Ott a scripting api is - kb 10 sor egy parancssoros php. A runtime library ugyanugy javaban fog szuletni ... elobb egy language bootstrap kellene, hogy azt is phpben irhassak ...
- A hozzászóláshoz be kell jelentkezni