- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Az elso komoly setup, ahol microsoft cuccokat latok. :) Szimpatikus az egesz.
- A hozzászóláshoz be kell jelentkezni
IS...maximum
- A hozzászóláshoz be kell jelentkezni
Meg SQL Server.
http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2…
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Ha tudnád, mennyi minden mögött van SQL Server...
- A hozzászóláshoz be kell jelentkezni
Termeszetesen, nekem nagyon aprocska a mintavetelem. Java-s kornyezetben mozgok, es ott azert kevesemm a microsoft sql server. Ezert is erdekes latni, mire is kepes.
- A hozzászóláshoz be kell jelentkezni
Pl. a magyar számtech nagykereskedés 60-80%-a mögött. (Cégek számától vagy forgalomtól függően.) De hozhatnám példának az egyik legnagyobb magyar (nem csak számtech) kiskert is.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Tényleg impozáns.
Szerintem a legtöbb magyar nagy (giga) szolgáltatónál tized ekkora sincs az összeállítás. Ami meg is látszik sokszor az oldalak betöltésén.
Ilyenformán erősen ajánlom tanulmányozásra a "tisztelt" szolgáltatók/bankok/ésatöbbiek rendszergazdáinak.
---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.
- A hozzászóláshoz be kell jelentkezni
+1
soksok +1
- A hozzászóláshoz be kell jelentkezni
A döntéshozóknak ajánld inkább...
- A hozzászóláshoz be kell jelentkezni
Reagálás lentebb.
---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.
- A hozzászóláshoz be kell jelentkezni
Igazából nem lepődnék meg, ha valójában sokkal nagyobb is lenne a géppark sokszor, csak mondjuk szimplán
a) komplexebb dolgok is történnek a háttérben egy stackoverflownál,
b) és még szarul is van megírva,
c) nincs ilyen szinten karbantartva
d) nem a megfelelő komponensekkel a megfelelő helyen.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Szamomra epp azert impressziv ez a felallas, mert nagyon keves hardvernek tunik ahhoz kepest, amekkora szolgaltatast futtat. A masik cikkukben irjak, hogy az MSSQL-t futtato hardvereik CPU kihasznaltsaga olyan 10% korul mozog.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Na igen, de nem is egy tárolt eljárásokkal, triggerekkel teletűzdelt ERP-t futtatnak, ahol minden a DB-n fut. (Látok ilyet, na, ott nem 10% a CPU :)
Egy másik cikkükben kifejtik, hogy lehetőség szerint az FE-ken cachelnek, utána reddis, aztán a DB jön. Ugyanezzel szembesültünk mi is a saját webünkön: gyakorlatilag érdektelen az, hogy milyen a PHP kód, a terhelés 90+%-a a PostgreSQL-re esik mögötte. Ha lehetne rendes webalkalmazásként futtatni a szoftverünket akkor egy halom mindent becachelnénk mi is a frontendeken és mondjuk PostgreSQL-es notificationokkal frissítenénk az adatokat. (Ezzel amúgy valószínűleg a DB terhelésünk 80%-át meg tudnánk szüntetni saccra 50-100%-os FE terhelés növekedéssel. De most már senki nem fogja emiatt átírni ASP.NET-re vagy Java-ra az oldalt.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Gondolom erre is gondoltatok mar, de mi a gond azzal, ha jon egy uj feature request, azt egy Java layerrel oldanatok meg, amit aztan hivogattok PHP-bol es igy szep lassan atallni?
- A hozzászóláshoz be kell jelentkezni
Igen, könnyen elképzelhető, hogy egyszer meg is lépjük ezt Java-val vagy .NET-tel, de eddig nem akartuk bevállalni az ezzel járó plusz szopást, másrészt van hasonlóban tapasztalat (a rendszer keretrendszere egy egyedi fejlesztés, aminek készült egy igen jelentősen átdolgozott verziója a projekt indulása -2008- után, ami már backportolva lett és hát khm. néhol azért nagyon nem lett szép az eredmény a felszín alatt. (Persze, hosszú távra nézve maximálisan megérte, az új keretrendszerben egy csomó minden egyszerűbb, gyorsabban kivitelezhetőbb volt. Vagy eleve: volt. Csak a backport megtörtént olyan 2011-12 környékén és még mindig van jócskán olyan rész, ami a régi keretrendszer dolgait használja :)
Harmadrészt, nem ez volt a prioritás.
Negyedrészt, aminél ki tudnánk ezt használni, ott nem igazán volt olyan drasztikus módosítás az elmúlt években, aminél megérte volna, vagy gyorsabban kellett, hogy egy ilyen projekt beleférjen a keretbe.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A legtöbbször pont a rendszergazda az, aki nem tehet arról, hogy milyen infrastruktúrán kell szolgáltatni. És nem csak hardver, hanem szoftver oldalról is képesek ordenáré baromságokat csinálni... Kedvencem egy olyan appszerver+Oracle felállás, ahol az alkalmasint gyorsan cserélendő statikus tartalmat (kép, css, js) az Oracle-ből veszi a kiszolgálást közvetlenül végző appszerver - de úgy, hogy ezek valójában egy, az Oracle által valamilyen táblaként látott fájlrendszerbeli könyvtárban vannak...
- A hozzászóláshoz be kell jelentkezni
Ott a pont. Nézd meg egyszer, hogy egy banknál kik hozzák a "mit vegyünk?" döntéseket. Többnyire nincs közöttük informatikával is foglalkozó ember.
- A hozzászóláshoz be kell jelentkezni
Látom az utolsó mondatomra ugrott a hup közössége.
Kifejtve: Most nagyon sok kollégát megfogok bántani, de szerintem aki ilyen szinten nem képes az (önön)érdekeit képviselni, az menjen el utcaseprőnek.
Ebben a szakmában túlnyomó részt nem azért dolgozik az ember, hogy organikus robot legyen. Igenis meg kell mondani, hogy mivel lehet jól és gyorsan dolgozni. Leírva előnyöket, hátrányokat. Aztán ha rosszul döntenek odafönt, lehet lobogtatni a feljegyzést, hogy én megmondtam.
---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.
- A hozzászóláshoz be kell jelentkezni
Ezt meséld el a Közbeszerzési Hatóságnak is. ;)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ez sikerült is egyszer, 20 év üzemeltetés alatt! De csak azért, mert a "szolgálati utat megkerülve" egyből egy szinttel feljebb küldtem a problémákat és lehetséges következményeket tartalmazó levelet. :(
A való világban senkit nem érdekel mit lobogtatsz.
- A hozzászóláshoz be kell jelentkezni
Dolgoztál már banknál? :-)
- A hozzászóláshoz be kell jelentkezni
Lobogtatni lehet, meg ha olyan papírra nyomtattad, akkor másra is használhatod. És ez egyébként nem csak banki informatikára jellemző - ahol picit nagyobb számok röpködnek, ott nem az üzemeltetőknél van a döntés. Javaslatot jó esetben tehetnek, de bizonyos méret fölött a beszerzés technikai/technológiai _és_ üzletpolitikai döntés is.
- A hozzászóláshoz be kell jelentkezni
Sehol sem az uzemeltetoknel van a dontes :-)
Ok uzemeltetnek, a donteshozok dontest hoznak.
Ha az uzemeltetok egy ezreleknel nagyobb hatassal lehetnenek a donteshozatalra, nem itt tartana az ipar, hanem valoban 21. szazad lenne mar.
- A hozzászóláshoz be kell jelentkezni
> Ha az uzemeltetok egy ezreleknel nagyobb hatassal lehetnenek a donteshozatalra, nem itt tartana az ipar, hanem valoban 21. szazad lenne mar.
Vagy nem, ez két élű penge. Az üzemeltetőnek (helyesebben kb. mindenkinek, aki közvetlenül technológiai voanlon dolgozik) van egy preferenciája, amit (tisztelet a kivételnek) papagájként ismételget _bármilyen_ kérdésben. Az Oracle DBA sosem fog MSSQL-t javasolni. Az IIS-es szerverek üzemeltetője sosem fog nginx-et javasolni. A .NET fejlesztőnek eszébe nem jutna, hogy egy új projekthez Pythont javaosljon. Stb.
Miért nem tesznek az üzemeltetők a közvetlenül érintett dolgozók ésszerű javaslatokat (megint csak, tisztelet a kivételnek)? Kettő oka van:
1) személyes preferencia
2) kontroll elvesztése (t.i. ha egy projekthez X technológiát használnak, akkor az Y-hoz értő munkatársak veszítenek a mozgásterükből)
A technikai döntéshozói réteg azért létezik, hogy bizonyos inputok alapján hozzon egy döntést, amit utána keresztül lehet vinni a szervezeten.
- A hozzászóláshoz be kell jelentkezni
Hogyne lenne, hisz mindegyik használ otthon laptopt. :D
- A hozzászóláshoz be kell jelentkezni
Nem mondod... És néha még a munkahelyen is :-)
- A hozzászóláshoz be kell jelentkezni
Ez 2300 req/sec? Nem tűnik soknak...ja hogy ez nem ping vagy ARP csomag? :)
Komoly, irigylésre méltó összeállítás. Tetszik, hogy csak a cache (Redis) 240GB SSD, 256GB ram :)
- A hozzászóláshoz be kell jelentkezni
2300req/sec esetén nekem kényelmes túltervezésnek tűnik.
Erősen hullámzó látogatottság mellett mi addig reszeltük a rendszer, amíg két, ehhez képest gyenge fizikai vason élő virtuális szerverek is elvittek ennyit csúcsidőben. Igaz az MS több gyorsjavítást is kiadott csak a mi igényeikre szabva, hogy bírja az IIS a terhelést...
- A hozzászóláshoz be kell jelentkezni
Oké, de mi volt a szolgáltatás, amit kiszolgált?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
VoD, a hozzá tartozó állandó adatgyűjtő kapcsolattartással a kliensek felé. Forró tartalmak felkerülésekor 100%-os terhelésen ment a webszerver és az adatbázis-szerver is...
- A hozzászóláshoz be kell jelentkezni
Sub
- A hozzászóláshoz be kell jelentkezni