Webszerver nagyon gyenge hardverre

Web, mail, IRC, IM, hálózatok

Adott egy ~10 éves gép (AMD Athlon II X4 615e, 8 GB 667 MHz DDR2 RAM), aminek két weblapot kell kiszolgálnia. Egyszerű weblapok, sima PHP+PgSQL+sok server-side cacheing, extra igények nem nagyon vannak, HTTP/HTTPS, URL rewrite esetleg kellhet. Az OS OpenBSD 7.1.
Nem használják túl sokan, egyszerre max pár tucat ember, csúcsidőben, amúgy annyi se, viszont adatforgalom/fő az viszonylag sok lehet a fájlletöltések miatt.

Kérdés: melyik webszervert lenne érdemes itt használni? nginx? Lighttpd? thttpd? shttpd? Az OpenBSD saját httpd-je és relayd-je? Valami egyéb tipp? (Apache nem jöhet szóba, túl heavyweight. Lassú is. És sérülékeny is. (Apache: 1716, Lighttpd: 31, Nginx: 7))

  • 2343 megtekintés

( mauzi v | 2022. 07. 14., cs – 10:40 )

Nyugodtan használj Apache-ot. Az érdemi erőforrásigény a PHP és PgSQL részéről lesz, az pedig független a webszervertől.

Apache és MPM worker, fölös modulokat kukázod, .htaccess -t letiltod, és máris sokat lépsz előre. Egyébként ha nincs .htaccess, akkor már nginx, valóban. :)

Ja. Ez amúgy nem olyan gyenge ám, és kapjon normális SSD-ket, és meglepően használható lesz ehhez, ha nincs más opciód.

( Nyosigomboc v | 2022. 07. 14., cs – 12:03 )

Van itthon egy 1. generacios Raspberry, azon lighttpd szolgal ki egy egyszeru php scripttel latogatokat (nincs mogotte DB, csv file-okat parse-ol es jelenit meg emberi formaban). Amikor hasznaljak, akkor viszonylag keves felhasznaloja van, es kicsik a csv file-ok, de szerintem ha ez ilyen terheles mellett "szinte azonnal" megy, akkor az Athlonnak sem lesz kihivas. A netkapcsolatod valoszinuleg tobbet fog szamitani.

A strange game. The only winning move is not to play. How about a nice game of chess?

( arpi_esp v | 2022. 07. 14., cs – 12:51 )

én anno írtam egyet (pontosabban 6-ot, mire elégedett lettem az eredménnyel) c-ben, kb semmit se tud az igenyeidbol, csak egy fix static html-t válaszol a requesttol függetlenül. de még ez is kiba bonyolult volt, 1 szálon fut, select SET-ekkel kezeli a párhuzamos kapcsolatokat, elpusztíthatatlan és kb 0 az erőforrásigénye.

Jaja, en is szoktam webszervereket beletenni mindenfele backend szolgaltatasokba (ipari vezerlok, beagyazott elektronikak multiplexerei, ilyesmik) ha epp ugy hozza a kedvem ;) 1x megirtam a lib-et, azota jo. Raadasul a sima text-only teletype-szeru protokollokkal teljesen osszekapcsolhato a http protokollja is, igy nem kell ket portot nyitni ugyanarra. Raadasul kis trukkel mikrokontrollerekre is portolhato ha van mogotte egy tcp/ip offload engine (w5500, pl). Mondjuk ez elegge dinamikus szolgaltatas-tipus, de a klasszik webszerver-konfiguracioknal (nginx, apacs) is mar elegge rohadtul frusztralo hogy mindig az a default hogy fileokat szolgaljon ki. 

elpusztíthatatlan és kb 0 az erőforrásigénye.

es igen, pontosan ez az elonye ezeknek :] 

( gee v | 2022. 07. 14., cs – 13:45 )

Egy 10 éves gép mitől lenne _nagyon_gyenge_ hardver?

25 évvel ezelőtt is tudtunk weboldalakat kiszolgálni az akkori hardvereken.

Ahogy egy Raspberry Pi, egy otthoni NAS vagy a WiFi router is ki tud szolgálni a saját gyengécske hardverén dinamikus weboldalakat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Igen, saját tapasztalat - nem fejlesztői, hanem üzemeltetői oldalról. Nem egy és nem két "szuboptimálisan" megírt sql meg taknyolt kód jött már szembe. Az "ilyen probléma nem lesz" azért erős - igen-igen nagy tapasztalattal bíró tanult kolléga szokta volt mondani, hogy olyan kód nincs, amin ne lehetne optimalizálni. Én meg hozzáteszem, hogy az a kód, amit csak két szemmel néznek, az pláne ilyen.

Minden kódon lehet még optimalizálni. Viszont nem mindegy kinek a két szeme nézi a kódot. www.fantajatek.hu, www.cokeolimpia.hu, www.cappyicefruit.hu, nyerjahaverokkal.hu; ezek voltak a Coca Cola által futtatott kupakfeltöltő promók 2012-ben és 2013-ban, amiknek én csináltam a (PHP+Oracle és az utóbbit akkor láttam életemben először (és szerencsére utoljára)) backendjét Mcload kollégával, a saját keretrendszeremmel és napi sokszázezer embert és többtízmillió lekérést szolgált ki a rendszer, mert rengetegen töltögettek fel kódokat. Ha én írok meg egy "webappot", akkor az rendesen meg lesz írva, nem fogja a világ összes CPU idejét megenni. Igazán abbafejezhetnéd ezeket a hülye célozgatásokat, mert nem nekem kínos.

Oldschool Computer - http://oscomp.hu

A PHP+Oracle valóban nem szerencsés párosítás, pláne, ha a fejlesztő nincs képben a DB-backend tudásával, és MySQL-ként tekint rá. Persze az sem jó, ha mindent a DB-re bíznak. (Az, hogy kinek mi a kínos... Szerintem az a "szerencsére utoljára" egy webes fejlesztőtől nem kicsit kínos... No mindegy. Egyébként nem azt mondtam, hogy sz@r kódot írsz, hanem azt, hogy nem igazán van olyan kód, ami négy szemmel nézve ne lehetne jobb/hatékonyabb. (Jó, egy form meg egy "insert into..." hatékonyságán nem sok reszelni való van :-D  )

Szerinted sz@r, bár én ezt úgy pontosítanám, hogy Az Oracle DB MySQL-nek sz@r, azaz ha valaki MySQL-ként akarja használni, akkor valóban szuboptimális dolgokba fut bele. Egyébként Oracle 12 (2013 július) óta van "FETCH", tehát a problémád épp "határeset" volt ebből a szempontból. Amit leírtál, az egyébként mind arról tanuskodik, hogy se a megbízó, se a fejlesztő nem ismerte kellően az eszközt, csak rá lett bökve az Oracle XE-re, hogy az megy alá, és kész.

A thread-ben egyébként Jason mondta meg a tutit...: https://hup.hu/comment/2336196#comment-2336196

A nyavalya akarta MySQL-ként használni, pláne, hogy sokkal közelebb áll a PostgreSQL-hez, csak utóbbi rendesen lett megtervezve és megírva.
Mivel akkor láttam életemben Oracle-t és úgy kellett megírni a portált két hét alatt, így nem csoda, hogy nem ismertem kellően az eszközt. Csináld utánam ennyi idő alatt nulláról. Úgy, hogy el is bírja azt a terhelést, amit mondtam.

Jason mondta meg a tutit, csak nem ott, hanem itt: https://hup.hu/node/163631#comment-2336194
Amit nekem linkeltél, abban nem tűnt fel a smiley a mondat végén?

Szerintem ne erőlködj. Még összecsinálod magad. Ha itt valaki nem ért semmihez, az te vagy.

Oldschool Computer - http://oscomp.hu

"A nyavalya akarta MySQL-ként használni" - csak minden 10 php programozóból mondjuk nyolc... Amiket felhoztál _számodra_ problémás dolgokat, az erre utalt egyébként.

"Mivel akkor láttam életemben Oracle-t és úgy kellett megírni a portált két hét alatt, így nem csoda, hogy nem ismertem kellően az eszközt. Csináld utánam ennyi idő alatt nulláról. " - Van az a munka, amit nem szabad elvállalni - meg ugye van az a pénz, amilét korpásodik... :-D
Én sem hőzöngök az AIX ellen, pedig amikor először láttam közelebbről, hát... Szóval megvolt róla a nem túl jó véleményem... Aztán amikor napi szinten üzemeltetni/használni kellett, akkor egészen más lett a véleményem róla.

csak minden 10 php programozóból mondjuk nyolc.

Én Assembly/C/Pascal programozó vagyok. Az, hogy tudok PHP-ban/SQL-ben is, az mellékes.

Amiket felhoztál _számodra_ problémás dolgokat, az erre utalt egyébként.

Tehát magyarul megint látatlanban ítélkeztél, a tények ismerete nélkül. Ok.

Van az a munka, amit nem szabad elvállalni

Alkalmazottként? Ott azt csinálom, ami a feladat. Ezért a két-három hetes szívásért buktam volna el az állásomat inkább? Egyébként, amikor közölték, hogy akkor most van két napom megtanulni az Oracle-t, akkor még nem tudtam, hogy ennyi baromság van benne, ld. a mellékelt listát.

meg ugye van az a pénz, amilét korpásodik

Nem fizették meg.

Én sem hőzöngök az AIX ellen

Nincs is miért.

Oldschool Computer - http://oscomp.hu

Szerintem a szent indulat rossz tanácsadó; mint minden bonyolult terméknek, az Oracle adatbáziskezelőnek is számtalan egyéni érdekessége/problémája van, mondhatni hozzáértést igényel. Például a kódkészletek kezelése sem egy 'gyere cipó, hamm bekaplak'-szerű probléma, néhány részletet ide gépeltem be.)

Attól, hogy másképp működik, mint ahogy te egy másik rendszert megszoktál, még nem biztos, hogy szar. (Lehet, hogy szar, de nem ezért).

- Nincs benne se LIMIT, se OFFSET. Helyette egy bedrótozott immaginárius rownum oszlop van. Amivel így lehet pl. lapozni:
SELECT * FROM
(
    SELECT a.*, rownum r__
    FROM
    (
        SELECT * FROM ORDERS WHERE CustomerID LIKE 'A%'
        ORDER BY OrderDate DESC, ShippingDate DESC
    ) a
    WHERE rownum < ((pageNumber * pageSize) + 1)
)
WHERE r__ >= (((pageNumber-1) * pageSize) + 1)
Hogy ez a két kulcsszót három egymásba ágyazott SELECT-tel helyettesítő kód milyen szép az egy dolog, de az megvan, hogy így tkp. az egész táblát le kell kérnie az embernek ahhoz, hogy lapozni tudja?

Ezt újabb (2013-) Oracle szerverek esetén lehet pl. így:

SELECT *
FROM user
ORDER BY first_name
OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY;

Régebbiek* esetén meg tömbbe ment a select. Erre most hirtelen nem találtam példát (nem tudom, mi lenne a jó keresőszó), a pontos szintaxisra meg nem emlékszem így több, mint 20 év után.

Valami olyasmi volt, hogy készítettünk PL/SQL-ben a tábla oszlopainak megfelelő típusú változókból tömböt, aztán volt egy SELECT akármi ORDER BY valami INTO :tömb

A tömb tartalma ment az oldalra, és amikor lapozni kellett, akkor kértük a következő mennyiséget.

Nem olvasta végig a táblát teljesen (feltételezve, hogy indexelve volt az oszlop, ami alapján sorba rendeztél), és a hálózaton is mindig csak annyi jött át, amennyit épp lekértünk a következő laphoz (ez az akkori lassú hálózatokon fontos szempont volt).

* (Oracle 7-en 96-ban nem emlékszem, hogy használtam-e, de 98-tól 8i-n biztos)

- Nincs autoincrement flag, szekvenciákat (sequence.nextval()) pedig beszúrásnál nem lehetett használni: "ora-02287: sequence number not allowed here"

beszúrásnál az mi? INSERT?

Réges rég nem használtam Oracle-t, de csodálkoznék, ha nem menne INSERT utasításban sequence.nextval.

PL/SQL-ben persze simán lehetett régen is id = sequence.nextval; insert into tábla (:id, akármi), és jellemzően ezt is csináltuk, mert ugye amikor ide-oda ugyanazt az id-t be kell tenni, akkor egyszerűbb a változót beírni minden insert utasításba.
Manapság persze meg van már identity oszlop, amit nem én töltök ki, hanem ő magának tölti fel.

- Egyetlen szöveges típusú mező van benne, a VARCHAR2 (igen, 2), ami max. 4000 karakter lehet. Van ugyan CLOB, de:

Mekkora szövegeket kellett tárolnod, hogy a VARCHAR2 nem volt elég?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Attól, hogy másképp működik, mint ahogy te egy másik rendszert megszoktál, még nem biztos, hogy szar. (Lehet, hogy szar, de nem ezért).

Kezdődik a szalmabábcséplés? Ki mondta, hogy azért szar, mert én mást szoktam meg? Azért szar, mert vagy hülyén, vagy egyáltalán nem működik.

Ezt újabb (2013-) Oracle szerverek

Ami 2012-ben még nem volt.

Régebbiek* esetén meg tömbbe ment a select. Erre most hirtelen nem találtam példát (nem tudom, mi lenne a jó keresőszó), a pontos szintaxisra meg nem emlékszem így több, mint 20 év után.

Mi sem találtunk példát, de még utalást sem. Az Oracle manualban sem.

Réges rég nem használtam Oracle-t, de csodálkoznék, ha nem menne INSERT utasításban sequence.nextval.

Értem, tehát rég használtad, de csodálkoznál, ha nem menne. Az, hogy még hibaüzenetet is adtam az mindegy. Azért szar, mert mást szoktam meg, nem azért, mert nem működik, igaz?

Mekkora szövegeket kellett tárolnod, hogy a VARCHAR2 nem volt elég?

Pár tíz kB-nyit. ÁSZF, leírás, játékszabályok, ilyesmi.

Amúgy az megvan, hogy a felsorolt kb. 20 problémából kipécéztél hármat? (És azokra sem adtál elfogadható választ, mert az, hogy későbbi verzióban már lehet ilyet, meg "csodálkoznál", ha nem lehetne, az nem válasz.)
Kérném az urakat, hogy az Oracle marhaságait, ne ebben a topicban próbálják meg megvédeni.

Oldschool Computer - http://oscomp.hu

Kezdődik a szalmabábcséplés?

Remélem, hogy nem

Ki mondta, hogy azért szar, mert én mást szoktam meg? Azért szar, mert vagy hülyén, vagy egyáltalán nem működik.

Az nem igaz, hogy egyáltalán nem működik. Az, hogy hülyén működik, az meg egy szubjektív dolog. Aki ezt szokta meg, az majd azt mondja, hogy nem is működik hülyén :-)

Mi sem találtunk példát, de még utalást sem. Az Oracle manualban sem.

Sajnos a Google messze nem mindenható. Sokszor vak vezet világtalant típusú kérdés/választ talál, ha egyáltalán bármit ad. Ha nincs tapasztalatod, akkor azt se fogod tudni, hogy melyik Oracle manualban keresgessél egyáltalán (és mivel van baromi sok, kicsi az esélye, hogy véletlenszerűen pont jó helyen nézed). Tippre a PL/SQL manuálban kellene kezdeni a nézelődést. Ha te épp abban nem nézted meg, akkor ennyi. A mostani Oracle adatbázisokat nem ismerem, de a régiekben nagyon sok mindent PL/SQL-lel oldottunk meg.

Értem, tehát rég használtad, de csodálkoznál, ha nem menne.

Igen. Mivel insertáltam már táblába sorokat sequence-ből jövő ID-val. Ha kiderül, hogy azt, amit 1996-2000-ig végre tudott hajtani az Oracle, azt 2012-ben nem tudta már végrehajtani, akkor bizony, csodálkozni fogok.

Az, hogy még hibaüzenetet is adtam az mindegy.

Hibaüzenetet azt írtál, de azt nem, hogy mi volt az utasítás. Anélkül meg csak tippelgetni tudok.

Amúgy az megvan, hogy a felsorolt kb. 20 problémából kipécéztél hármat?

Meg. Egyfelől nem értek mindenhez, pl. nagy méretű szövegeket sose kellett adatbázisban tárolnom, tehát amit a CLOB-ról írtál, ahhoz semmi kommentem nincs. Másfelől nem kötözködni akarok, hogy minden mondatodba belekössek, hanem pár dolgon megakadt a szemem.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az nem igaz, hogy egyáltalán nem működik. Az, hogy hülyén működik, az meg egy szubjektív dolog.

A szekvencia egyáltalán nem működött. Az, hogy a lekérésben az összes üres stringet lecseréli NULL-ra, az nem szubjektív dolog, az egy tény és ez egy hülye működés. Az, hogy nincs benne integer adattípus, hanem ábrázolj minden számot egy 160 v. 192-bites float-on, az sem szubjektív dolog, hanem az is egy tény és ez egy hülye működés. Az, hogy a szöveges változókban nem lehet 4000 karakternél többet tárolni sem szubjektív dolog, az is egy tény és ez egy hülye működés. Ezeket a baromságokat nem lehet "megszokással" magyarázni.

Tippre a PL/SQL manuálban kellene kezdeni a nézelődést.

Ez a tipp sajnos kereken 10 évet késett...

Igen. Mivel insertáltam már táblába sorokat sequence-ből jövő ID-val. Ha kiderül, hogy azt, amit 1996-2000-ig végre tudott hajtani az Oracle, azt 2012-ben nem tudta már végrehajtani, akkor bizony, csodálkozni fogok.

Hát, akkor csodálkozhatsz.

Hibaüzenetet azt írtál, de azt nem, hogy mi volt az utasítás. Anélkül meg csak tippelgetni tudok.

INSERT INTO "table1" ("id", "field1") VALUES (table1seq.nextval(), 'kecske');
Vagy valami hasonló. 10 év után már a tököm tudja. De a manualok/netes példák alapján próbáltuk úgy, ahogy.

Oldschool Computer - http://oscomp.hu

A szekvencia egyáltalán nem működött.

Kb. 5 éven át dolgoztam Oracle-lel. Mindig sequence-ből vettem az id-t. Nem igaz az, hogy a szekvencia nem működik. Elhiszem, hogy valahol, ahol próbáltad, nem ment, de ez csak annyit jelent, hogy máshogy kellett volna csinálnod. Ha ez nem tetszik, az OK.

Az, hogy a lekérésben az összes üres stringet lecseréli NULL-ra, az nem szubjektív dolog, az egy tény és ez egy hülye működés.

Az, hogy lecseréli az üres stringet NULL-ra, az valóban nem szubjektív dolog. Az összes többi példád szintén tény, nem szubjektív dolog. Az a szubjektív vélemény, hogy ez hülye működés-e vagy nem.

CREATE table "TABLE1" (
    "ID"         NUMBER NOT NULL,
    "FIELD1"     VARCHAR2(10),
    constraint  "TABLE1_PK" primary key ("ID")
)

create sequence "SEQUENCE1"

insert into table1 (id, field1) values ( sequence1.nextval, 'kecske');


1 row(s) inserted.


0.09 seconds

Működik. Azt feltételezem, valamit rosszul másoltál ki a leírásokból, vagy rossz helyen nézted és ott valami másról volt szó, de a valódi példa nélkül már sose fogjuk megtudni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Kb. 5 éven át dolgoztam Oracle-lel. Mindig sequence-ből vettem az id-t. Nem igaz az, hogy a szekvencia nem működik. Elhiszem, hogy valahol, ahol próbáltad, nem ment, de ez csak annyit jelent, hogy máshogy kellett volna csinálnod. Ha ez nem tetszik, az OK.

Ez nem érv, ez tekintélyre hivatkozás, meg bizonyítási kényszer áthárítása. Megmutattam, hogy mi volt a parancs, megmutattam, hogy mi volt a hibaüzenet. Te viszont nem mondtad meg, hogy mit rontottam el, csak hajtogatod, hogy én rontottam el.

Az a szubjektív vélemény, hogy ez hülye működés-e vagy nem.

Valóban. Aki logikusan gondolkozik, annak ez hülye működés. Az üres sztring egy érték. A NULL egy állapot. Én sztringet szúrtam be, nem állapotot. Ennyi.

Működik. Azt feltételezem, valamit rosszul másoltál ki a leírásokból, vagy rossz helyen nézted és ott valami másról volt szó, de a valódi példa nélkül már sose fogjuk megtudni.

Nagyjából ez volt, persze nem ezekkel a változónevekkel. Esetleg abban a 2011-es/2012-es Oracle DB-ben volt egy bug.

Oldschool Computer - http://oscomp.hu

Ez nem érv

Dehogynem. Ha azt állítod, hogy a sequence egyáltalán nem működik, az azt jelenti, hogy soha, semmilyen körülmények között. Erre akár csak egy ellenpéldát hozni azt jelenti, hogy ez a kijelentés téves. Ha megnézed, ebben a threadben az elejétől kezdve azt állítom, hogy nem hiszem, hogy valaha lett volna olyan Oracle verzió, amiben a sequence egyáltalán nem működött volna.

Ettől még lehet, hogy van/volt hiba, de az eredeti kijelentés túl széles volt. Kristálygömböm nincs, így nem tudom, mi miatt nem ment neked.

Esetleg abban a 2011-es/2012-es Oracle DB-ben volt egy bug.

Ezt valószínűleg már sosem fogjuk megtudni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

És van még a RETURNING záradék, amivel visszakérjük a generált ID-t. Ettől függetlenül sok erőt nem tennék ebbe az ügybe, ha a kolléga két hetes önképzéssel eldöntötte, hogy az Oracle egy rosszul sikerült MySql-klón, amivel kár vesződni, akkor marardjunk ennyiben.

Te is kezded a hazudozást? Hol mondtam, hogy az Oracle egy MySQL klón? Ezért jöttél te is ebbe a topikba, hogy baszogass, meg hazudozz? A másik kommented is rohadt konstruktív és hasznos volt. Jól megcáfoltátok egyébként a belinkelt kommentben felsorolt két oldalnyi listát...

Oldschool Computer - http://oscomp.hu

Egyetértek a kollégával, annyira nem gyenge gép ez. Jó, régi, meg mai szemmel nézve a még több magos csodákhoz képest nem számít már combosnak, de azért ne feledd, hogy sokan futtatnak webszervert olyan gyenge hardveren, mint egy RPi, ahhoz képest mégis csak erősebb vas.

A másik tényező meg, amit szintén írtak már, hogy nem maga a webszerver fogja az erőforrások javát enni, hanem a PHP, SQL része.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez hogy működik?

A legenerált dinamikusan előállított oldal kerül a cache-be, és ha valaki ugyanaztokat az paramétereket választja, akkor php-s generálás helyett a cache-ből megkapja a korábban előállított html-t?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nagyjából, bár ez csak a látogatók által módosítható tartalomra (vendégkönyv) és a látogatók által előállított linkekre (keresés) vonatkozik. Ami pre-cache-elhető, az már az adminfelületen való létrehozáskor/módosításkor cache-elődni fog.

Oldschool Computer - http://oscomp.hu

Látom vannak zavarok. Néhány pontban:

  • a webszerver maga, az bazira gyors lesz ezen a gépen
  • ami lassú lesz első körben az a PHP vagy Java kód, ha mondjuk úgy lazára vették a figurát, hiszen az 5GHz-es aktuális csodaprocin nagyon gyors volt (hiszen a fejlesztőnek bazira atomreaktor gép kell, hiszen 3 mpenként az egész mindent lefordítja, nem várhat 1 mp-nél többet)
  • második körben az adatbázis struktúrát nem sikerül rendesen megtervezni, vagy ha nagyjából jó, akkor a későbbi biznisz igényekre már nem, és a jajjuristen működjön téma miatt jönnek majd a bajok
  • harmadik körben iszonyat módon felhízik az adatbázis, vagy azért mert nem tartják karban, vagy azért mert hát nem gondoltuk, hogy itt 30 millió bazinagy rekordban kell mazsolázni (lásd még adatbázis tervezés, mezőtípusok, indexek), a webszerver sosem lesz adattárház, akármennyire is szeretnék

Amint az látszik relatív kevés a pozitív tapasztalat fejlesztési oldalról. A legszomorúbb az, amikor az értelmes fejlesztő mondja, hogy ezeket tudja, de egyszerűen a fejlesztési igényt eléteszik és helo, leszamilesz. Simán előfordulhat, hogy az adott valami tényleg nagyot nő, és át kell dolgozni, de erre a kedves megbízónak biztosítania kell az erőforrást, és nem úgy, hogy plazmában izzanak szerverek a hosszú évek sara alatt.

Sok esetben volt az, hogy két SSD-vel szerelt szerver izzadt plazmát, majd amikor migráció után tőlünk (tőlem) tudták meg a valóságot, akkor ment a pillogás, hogy hát dehát.  Aztán néhány konkrét probléma után elkezdték belátni a dolgokat, és legalább valamennyi foglalkozni a visszakövetéssel, szóval a fejlesztőnek erre is adtak időt/pénzt.

Oracle, PgSQL meg mindenféle csodákról kár álmodozni, meg szarozni addig, amíg egy külső kulcs, egy trigger vagy tranzakció működése, de főleg felhasználásuk a ködbe vész igen sok webes projektben. A MySQL autocommit, és MyISAM táblatípus justworks története sokmindenről tehet, de egy netto myisamból jött hozzáállás alá fölösleges bármi extrát tenni.

Ifjúkoromban volt PHP+PgSQL projektem egy nagyforgalmú fórummotor formájában, működött rendben, ha jól emlékszem milliós rekordszám felett. Nem voltam rest doksit olvasni, tesztelni, és használni rendesen a tranzakciókat, és külső kulcsokat, meg normális indexeket, ja és használni a query plannert. SSD-k még a kanyarban sem voltak, valahol az AMD Opteron korai generáció körülről van szó.

ami lassú lesz első körben az a PHP vagy Java kód

A PHP kód az esetek kb. 90-95%-ában a cache-ből való előhalászást fogja csak végezni. Már többször írtam.

hiszen a fejlesztőnek bazira atomreaktor gép kell

10 éves gépen fejlesztek...

második körben az adatbázis struktúrát nem sikerül rendesen megtervezni, vagy ha nagyjából jó, akkor a későbbi biznisz igényekre már nem, és a jajjuristen működjön téma miatt jönnek majd a bajok

Hullaprimitív adatbázis van alatta.

harmadik körben iszonyat módon felhízik az adatbázis, vagy azért mert nem tartják karban, vagy azért mert hát nem gondoltuk, hogy itt 30 millió bazinagy rekordban kell mazsolázni (lásd még adatbázis tervezés, mezőtípusok, indexek), a webszerver sosem lesz adattárház, akármennyire is szeretnék

Kevesebb, mint 2000 rekord gyűlt össze benne 15 év alatt. A teljes SQL dump tömörítetlenül 2 MB.

Amint az látszik relatív kevés a pozitív tapasztalat fejlesztési oldalról.

Itt üzemeltetési oldalról van kevés tapasztalat.

Oldschool Computer - http://oscomp.hu

Nem pont rád gondoltam, csak összeszedtem az amúgy nem mindíg egyszerre jelenlévő dolgokat. :)

Ami tetszőleges méretnél érdemes figyelni, hogy mi van akkor ha egyszerre sok kérés jön, illetve alakul át sok queryvé a sql fronton. MyISAM-ba ragadt dolgoknál simán tudnak race conditiont generálni, mert waiting for table lock és akkor úgymaradnak (látszólag, csak több a kérés, mint amivel végez a szerver).

Ha MySQL, inkább a MySQL mint a MariaDB, bár lehet ezzel sem leszek népszerű, akkor ott InnoDB táblatípus, és a mysqltuner.pl (ezen a címen be is szerezhető) scripttel néha érdemes megnézni, hogy miket javasol cache és puffer érték fronton. Amíg tényleg kicsi és egyszerű marad a forgalom, és az adatmennyiség, addig nagy meglepetések nem lesznek. A hardware állapotok (főleg ssd-k smartctl -lel, meg a software raided mdadm-es emailjeit kapd meg) monitorozandóak, bármilyen egyszerű módon, hogy tudd, mi a helyzet.

Kösz a MySQL tippeket, de PgSQL lesz alatta. :)

Egyébként, ha MySQL-re/MariaDB-re kell fejlesztenem, akkor általában InnoDB-t szoktam én is választani, pont a MyISAM table lock-ja miatt, de van kivétel: ha van valami bazi nagy, de egyszerű, vagy alapból denormalizált (nincs JOIN) tábla, ami read-only, nem lesz írva (vagy csak az adminok írják és ők is ritkán), akkor ott tapasztalataim szerint jobb a MyISAM, mert valamivel gyorsabb és a table lock ott nem fog gondot okozni, mert a read lockot nem zavarja a másik lock jelenléte, tehát a SELECT-ek futni fognak.

Oldschool Computer - http://oscomp.hu

1 magos VM, 1 GByte RAM egy NAS-on, reverse-proxy módban. Nem valami hű de nagy forgalom, 10 fő alatti napi felhasználószám. Memóriahasználat eddig, amikor ránéztem 50-200 MByte (Go-ban írták szegénykémet), viszont az SSL-t kapásból beállítja mindenféle beavatkozás nélkül, ha kintről is elérhető. Csak intraneten tanúsítvány kézzel telepíthető. Én felhúztam mindenféle tömörítést max-ra, és olyan változatot fordítottam, ami ismeri a Brotli-t.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( bennyh | 2022. 07. 14., cs – 14:36 )

Szerkesztve: 2022. 07. 14., cs – 14:37

(nemide)

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( quash | 2022. 07. 14., cs – 15:29 )

nginx

oBSD alatt stabil, jó, mi elég sok helyen proxy-unk vele.
"packages-stable"-ben frissítik is néha, adott oBSD verzióhoz.

Ha nagyon bele akarsz menni, akkor újra forgatod ports-ból, akár magasabb verziószámmal is mint az aktuális oBSD verzió.
 

+1

Én pl. azért használok lighttpd-t pl. ngnix helyett, mert jobban kézreáll a konfigurálása. Vagyis _számomra_ egyszerűbb telepíteni, beállítani és üzemeltetni.

A 10 éves vasra is ennek alapján választanék, nem a webszerver erőforrás igénye alapján (ami várhatóan elenyésző egy 10 éves vas teljesítéményéhez képest)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ne már! Ha a lighttpd-t szeretnéd kipróbálni, akkor próbáld ki azt! Azért, mert másoknak más a kedvence, nehogy már ne a saját vágyaidat kövesd! Persze ha valakinek ellenérve lenne a lighttpd-vel szemben, az más.

Ennek alapján, amit írtál, én kipróbálnám a lighttpd-t, és ha nem bízol benne, akkor esetleg jól letesztelheted, hogy bírja-e a hatalmas terhelést. Ha nem bírja vagy valami nem tetszik, akkor még mindig lecserélheted másra.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Direkt nem érted amit írok?

Ha valaki azt bizonyítja be, hogy a lighttpd nem fog működni, akkor ne használd!

Ha valaki azt mondja, hogy neki a nginx szimpatikusabb, az viszont nem jelenti azt, hogy ne a lighttpd-t használd. Eddig nem láttam ellenérvet a lighttpd ellen. Volt, csak nem vettem észre?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezt írtad: "Azért, mert másoknak más a kedvence, nehogy már ne a saját vágyaidat kövesd! Persze ha valakinek ellenérve lenne a lighttpd-vel szemben, az más."
Ez a két mondat egymásnak ellentmond. Én csak erre céloztam. Egyébként nem volt ellenérv a Lighttpd ellen, viszont az nginx mellett volt sok érv. Érvekre meg mindig vevő vagyok. Még emésztem a dolgot, de lehet nginx lesz.

Oldschool Computer - http://oscomp.hu

Akkor én meg a Win11-re szavazok, faszányos IIS-sel, MS SQL-lel, PHP helyett ASP.NET-tel és mindenféle MS-os földi jóval. Pont az, amit te keresel, már boot utáni idle-ben bekajál az alap rendszer IIS nélkül is 3-4 giga memóriát. Egyelőre csak desktop változat van, a Win11-re épülő Server még nem jött ki, a Win Server 2022 is egyelőre még csak Win10 alapú, az meg már múlt századi, semmi lekerekített ablak, meg középre igazított tálca, ami kell, mint egy falat kenyér.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( szkaresz v | 2022. 07. 14., cs – 15:58 )

Szerkesztve: 2022. 07. 14., cs – 16:00

Nálam egy Q6600 INTEL procival működő 8GB rammal bíró DELL gépen fut az Apache szerver. Online többfelhasználós  fotóalbum és egy owncloud mysql támogatással. Elég jól megy. A sávszélesség szokott inkább gondot okozni.

Karesz

Letölthető háttérképek  |  Portréfotók

( KoGa v | 2022. 07. 14., cs – 16:30 )

Nagyon hasonló hardware volt nekünk webszerver 10+ évig Apache, PHP kombóval. Szépen ment, gond nélkül. De ha valami lightosabbra vágysz, nginx, az is teljesen korrekt. A többit nem ismerem, de biztos más jó megoldás is van.

( apal v | 2022. 07. 14., cs – 16:51 )

A felmerultek kozul nginx-re szavaznek. Egy ennel regebbi, kevesebb ramos gepen volt apacs, mar a tokom tele volt a lassusagaval - amiota lecsereltem nginx-re, eg es fold, teljesen jo mindenre is amire kell (AMD Athlon 64 X2, '07-es kiadas, 2G rammal). 

Kizárólag statikus oldalakat szolgál ki gyorsabban az nginx-es felállás, vagy van PHP is? Mert ugye Apache default-ként mod_php van (gyárilag nagy terhelésre nem túl optimális konfiggal), nginx esetén meg kizárólag php-fpm játszik, ami nagyon nem ugyan az teljesítmény és skálázás terén. Én nem látom, hogy ha PHP-ről beszélünk, akkor hogyan lehetne jelentős teljesítmény különbség a két webszerver között, ha azonos módon futtatod mellettük a PHP-t és ilyen viccesen kevés terhelést kapnak...

Hja, csak nem biztos, hogy mindig PHP marad. Lehet egy nap átírom Pascalba és nginx vagy Lighttpd modult csinálok belőle. :]
A terhelést meg nem tudom pontosan belőni jelen pillanatban. Folyamatosan nem várható nagy terhelés, de olyan előfordulhat, hogy egyszerre beesnek rá párszázan, vagy még többen.

Oldschool Computer - http://oscomp.hu

( uid_395 v | 2022. 07. 14., cs – 18:07 )

Ez csak a "troll" kérdés, https lesz?? :))) Bocsi, magas labda volt :)

( ggallo | 2022. 07. 14., cs – 18:35 )

Szerkesztve: 2022. 07. 14., cs – 18:36

Egyébként most teljesen komolyan! 10-12 egyidejű felhasználónál gondolkozik bárki, hogy az Nginx gyorsabb az Apache-nál? 

A linkelt cikk meg egy vicc. Inkább ilyen marketing bullshit mint tudományos írás. Mindenféle körülmény, hardver, szoftver spec, stb. _nélkül_ kijelenti, hogy az Apache "slow", az Nginx meg "2.5x faster". Ez komoly? Mert viccnek durva.

A cucc biztonságát meg elsősorban a PHP kód milyensége fogja meghatárózni, nem a webszerver ismert sebezhetőségei... Persze, ha a tűzfalon nincs nyitva minden pont a webszerverbe meg nincs betöltve semmi, csak ami a működéshez kell.

Nem tudom, hogy mennyi lesz a peak maximum user. Lehet 10-20-30x annyi is.

Nekem is az a tapasztalat az Apache-csal, hogy lassú.

A tűzfalon csak a 80-as, 443-es port van nyitva, más nincs. A PHP kódról meg annyit, hogy 18 éve írok portálokat, de még egyiket sem törték fel.

Oldschool Computer - http://oscomp.hu

Hát, ha ennyire megnő a forgalom, és esetleg nem bírja el a gép, akkor át kell majd költöztetni erősebb hardverre, nagyobb sávszélességre. Nem lehet csak optimalizálással meg kis erőforrás-igénnyel megoldani a növekvő terhelést. Azt nem tudom elképzelni, hogy adott terhelést adott hardveren az Apache nem bír el, de az Nginx meg gond nélkül lekezeli (megfelelő konfiguráció és jó minőségű webapp mellett).

Nem mondtam, hogy feltörhető a PHP kód, amit írsz, hanem azt mondtam, hogy _általában_ a PHP kód a sebezhetőbb, mint a webszerver.

- használj PHP 8.1-et
- PHP opcache legyen bekapcsolva
- és ha van session, akkor tegyél fel redis-t vagy memcached-t és állítsd át rá

session.save_handler = redis
session.save_path = "tcp://redis:6379"

- neten keress rá : "speed up php", "optimize php-fpm", stb.
- én is nginx-et ajánlok

Általában igen, gyorsabb, néhány keretrendszer esetében viszont nem.
Bővebben itt olvashatsz róla: https://kinsta.com/blog/php-benchmarks/
De kiszedve két részt belőle:

  • WordPress 5.9-RC2 PHP 7.2 benchmark results: 106.56 req/sec
  • WordPress 5.9-RC2 PHP 7.3 benchmark results: 108.45 req/sec
  • WordPress 5.9-RC2 PHP 7.4 benchmark results: 110.24 req/sec
  • WordPress 5.9-RC2 PHP 8.0 benchmark results: 111.10 req/sec
  • WordPress 5.9-RC2 PHP 8.1 benchmark results: 163.43 req/sec

 

  • Laravel 8.80.0 PHP 7.2 benchmark results: Unsupported 🚫
  • Laravel 8.80.0 PHP 7.3 benchmark results: 2278.86 req/sec
  • Laravel 8.80.0 PHP 7.4 benchmark results: 2303.23 req/sec
  • Laravel 8.80.0 PHP 8.0 benchmark results: 2376.40 req/sec 🏆
  • Laravel 8.80.0 PHP 8.1 benchmark results: 2002.94 req/sec

Előfordulhatnak olyan speckó függvények, osztályok, amik adott újabb verzióval gyorsabbak, és sokkal. Egy távoli galaxisban megkaptuk, hogy elképesztően f...s a szerver, és ezt hogy a trágyát hogyan képzeljük. Néztünk csak bután magunk elé, hogy miről beszélnek, mert ha nem is a legújabb széria volt, azért csak 1-2 generációval volt régebbi, pláne SSD is volt. Nos kiderült, hogy a szuperszakértő hisztibajnok fejlesztőjellegű az 7.2-es vagy 7.3-as PHP-val csapatta, és eközben a szerveren (a saját maguk kódja miatt, nem  miattunk) PHP 5.4 vagy 5.6 volt fent prodban. Nos az ő saját kódjuk tényleg 2x gyorsabb lett a 7.2/3-mal, de persze nekem kellett bizonyítani, hogy ő van megvadulva, csodálatosak ezek. Ha jól emlékszem XML feldolgozás volt a kérdés.

Ugyanakkor ha kicsi a forgalom, nincsenek extra cron igények (pl. 1 órát fut valamilyen matekos feladat), akkor nem kell feltétlenül 8.1-ezni, bár a jövőállóság miatt mindenképp jó gondolat.

Nem, nem használok. Két fájl lesz meghívva, az egyik ugye maga az index.php, a másik meg az index.php elején, ami a cacheing további menetét eldönti a lekérésből és ha van tárolt példány a legenerálandó lapból, akkor azt fogja odaadni.

Oldschool Computer - http://oscomp.hu

( gabor.79 | 2022. 07. 15., p – 08:37 )

Tapasztalataim szerint nincs gyenge hardver, csak gyengén megírt szoftver. Szerintem nem ártana kipróbálni, mérni, hogy mi is a valós helyzet, addig mindenki csak okoskodik.

1, OpenBSD: régóta OpenBSD párti vagyok, anno a weblaborra is írtam még az 5.0-ról. Pár éve, a 6.5, 6.6 környékén foglalkoztam vele utoljára, és az jött ki, hogy ugyanazon a hardveren fele akkora teljesítményt tud produkálni, mint egy Debian alapú Linux. Mindegy, hogy ARM vagy x86 volt az alap, igazi vas vagy virtuális. Tehát, ha számít a teljesítmény, akkor az OpenBSD sajnos nem jó választás. A lassúságot okozhatja a kernel és a driverek is, ezeket jóval kevesebben fejlesztik, mint a Linuxét, emiatt csodákra nem lehet számítani.

2, Sok évig Apache-t használtunk, aztán áttértünk nginx-re, majd lighttpd-re. Utóbbi némileg gyorsabb az nginx-nél, nem orosz, kisebb, és számomra könnyebben konfigurálható, de igazából nem sok különbség van köztük. A legkönnyebben az OpenBSD httpd konfigurálható, valamint kicsi az erőforrásigénye, viszont pár éve volt egy hibája, amit be is jelentettem, de nem írtak, hogy javították volna. Az AJAX kérésekhez kézileg kellett tenni egy Connection: close http fejlécet.

3, Nem tudom, mennyire releváns valójában az, hogy hány sérülékenysége van egy szoftvernek, amíg azt nem használják sokan, és azok is megbízható, ismert emberek. Bár a publikus IP címeket folyamatosan próbálgatják kívülről, de az OpenBSD kiváló pf-jében megírt pár jó szabállyal ezeket könnyen ki lehet védeni. Innentől kezdve pedig már a weboldal mögött futó szoftveren múlik minden.

4, Memória
a,
OpenBSD: a szűz telepítés 9-11 MB-ot eszik
Lighttpd: 5 MB-ot eszik
PHP-FPM: 3-5 MB szálanként, a futó szoftver nélkül
PostgreSQL: ezt fejből sajnos nem tudom, de jóval több, mint a MySQL-é, és lassabb is

Jómagam PG párti vagyok, de ha számít a teljesítmény és a memória, akkor akár egy 4.0 vagy 5.0 MySQL is bőven elég lehet, ami unix socketen fut, és nem TCP porton, így kívülről akkor nem lehet támadni. Ha kicsi az adatbázis, nyolc-tíz megabájtra le lehet szorítani a memóriafoglalását.

b, PHP
Mint fentebb írtam, alapból nem eszik sokat, erre jön a szoftver. Mit csinál a (saját) szoftver? Lefuttat pár lekérdezést és kiköp legfeljebb pártíz kilobájtnyi HTML-t? Akkor kérésenként két-három megabájt többlettel kell számolni.

c, Fájlletöltések
A webszerver a közvetlen fájlletöltéseknél egy memória mappinget csinál, sajnos a neve nem jut eszembe, ennek a processzor teljesítményvonzata elhanyagolható. Ha jól sejtem, a gépben van egy gigabites hálókártya, ami legfeljebb másodpercenként 90-100 megabájtot tud átereszteni másodpercenként. Az SSD-k legrosszabb esetben is tudnak 100-150 MB/s-t, a 128 GB-os 3-400 MB/s-t.

Az SSD-vel tehát nem lehet kihajtani a hálókártyát, tehát effektíve száz megabájtnál több fájl cache-t nem igazán tud kihasználni a gép.

Összegzés: az alaprendszer tehát eszik 50 megabájt memóriát, efelett minden fájl gyorsítótár. Magyarul, ha 256 megabájt memória lenne a gépben, az SSD miatt pont ugyanolyan gyors lenne, mintha 8 gigabájt. Egyedül a fogyasztást érinti a dolog, az SSD-k olvasás alatt 2Wh áramot "esznek", ez 365 napig tartó 24 órás folyamatos terhelés alatt 17,5 KWh-t jelent, ami 40 forinttal számolva egy évben legfeljebb 680 forinttal terheli a pénztárcádat. Ha HDD lenne benne, akkor viszont teljesen más a kép.

Ez alapján el lehet tehát gondolkodni, hogy megéri-e sok memóriát pakolni ebbe a szerverbe. Nem csodálkoznék rajta, ha az átlagos load 0 körül lenne.

Hazudsz. Veled vagyok ilyen, ugyanis te jössz folyton azzal, hogy én milyen szar programozó vagyok, én meg csak védem magam, hogy nem, meg emlékeztetlek rá, hogy te mekkora egy hiperlamer/überpancser vagy.

Te mást sem csinálsz, ha összefutunk, mint vagy azt próbálod megmagyarázni, hogy nem értek semmihez, szar programozó vagyok, etc., vagy bűncselekményeket próbálsz vért hugyozva rámolvasni, vagy csak simán mocskolódsz, jó, hogy anyámat nem szidod.
A magas lovon is te üldögélsz, amikor előveszed a veterán stílust és a korommal jössz, holott a kor nem érdem, hanem állapot, attól nem okosabb vagy képzettebb leszel, hanem csak öregebb. Akkora baromságokat vagy képes azzal a nagy fene nagy tapasztalatoddal összehordani, hogy az eszméletlen.
Pl. amikor megpróbáltál azzal cseszegetni, hogy az Opera 12 elavult, mert nem támogatja a TLS 1.2-őt, de nemcsak azzal égtél be, hogy azt sem tudtad, hogy de, támogatja, de még a ciphereket is összekeverted a TLS-sel.
De az is vicces volt, amikor leoltottad Zizit, hogy manageres a kódja, aztán amikor - NagyZ, meg még egy páran - helyretettek, akkor még neked állt feljebb és elkezdtél okoskodni a processzek és a csövek pazarlásáról...csak azért, hogy kiderüljön, hogy a legnagyobb pazarlás az maga az awk volt, amire te átírtad az egészet. Erre válaszul nekiálltál okoskodni, de azzal is csak beégtél, mert a cut mögé raktad volna a head-et, így ahelyett, hogy csak egy sort tartottál volna meg a vágáshoz, inkább minden sort levagdaltál volna, feleslegesen, hogy aztán csak egy sort tarts meg belőle. 16-danos shellscripter vagy.
Vagy, amikor kijelentetted, hogy a systemd-s üzemeltetéshez nem szerencse, hanem normálisan összerakott disztró kell. Miközben még az a cég sem tudott összerakni vele egy működő disztrót, amelyik a systemd-t kitalálta. Érdekes egyébként ez a systemd mánia nálad, mert régen véresszájú systemd-hater voltál, most meg véresszájú systemd-zelóta vagy. (Most már nem zavarnak a systemd-ben hemzsegő "igencsak jelentős átdolgozásért ordító gánykupacok", amikért "anno C-programozás alapjai tárgyból páros lábbal rúgtak volna ki, ha ilyeneket csinálsz"?) Mindegy mi vagy, csak véresszájúskodni szeretnél? Vérivás FTW? Az enyémet nem fogod.

Jössz utánam folyton, mint egy kutya és ott próbálsz belémmarni, ahol tudsz. Nem unod, hogy folyton pofáraesel vele?

Oldschool Computer - http://oscomp.hu

Hogy te mekkora egy lúzer vagy, hogy már megint csak erre a személyeskedő szúrkálásra futja...és mekkora gerinctelen egy suttyó, még így a tetejébe, mert te pontosan tudod, hogy miért nem megy, mert a múltkor, mikor levelet írtál érte, megírtam neked, hogy lehalt a hosternél a MySQL, nekem meg nincs hozzáférésem. Hogy tegyem akkor rendbe? Ez az aljas surmóság a gáz, amit tolsz.

Egyébként, ha már fos, a te bloggerkomos oldalad, na az fos.

Mi lenne, ha lekopnál rólam? Kezdem unni a patkánykodásodat.

Oldschool Computer - http://oscomp.hu

Az OpenBSD itt a biztonság miatt lett választva, nem a teljesítmény miatt.

Az miért szempont, hogy az nginx orosz, a Lighttpd meg nem? Oroszul vannak benne a kommentek?

Én pont azt tapasztaltam, hogy a PostgreSQL gyorsabb, de egyébként ez majdnem mindegy, mert szinte minden cache-elve lesz.

A PHP nagyjából azt csinálja, amit mondasz, de csak, ha nincs cache-elt verzió abból, amit ki kell köpnie, amúgy azt adja oda.

Kösz az összefoglalót, akkor nem fontos annyira a memória.

Oldschool Computer - http://oscomp.hu

O_O
Na, ezt légy szíves magyarázd már meg, hogy ezt honnan szedted, hogy én nem vagyok hajlandó feltelepíteni egy másik böngészőt, hogy regisztráljak az Acer fórumba, amikor több mint 10 browser van felrakva a gépemre. Ezt honnan szedted...?
Meg azt is magyarázd már meg plz., hogy ha ez így is volna, az mitől is volna politika...

Oldschool Computer - http://oscomp.hu

Nem gondolnám, hogy woke lennék.... :-/

De mind1, továbbra sem politikai volt a mondandóm... De legyen off.

On:

Nem pont értem a problémát, amúgy az egész szálat végig olvasva. _Nekem_ az jött le, hogy ha az indiánt nem akarod (tökmindegy miért), akkor nyomhatod a nginx-et vagy a light-ost. A vasad elég lesz rá sok userrel is.

Ha olyan pengén fejlesztesz, ahogyan írod, akkor bizonyosan. A többi meg csak kötekedés és/vagy a szőr hasogatása... 

Nem azt mondtam, hogy te vagy woke... /o\

Na ja, csak nem én kötekszem. Én pár tippet szerettem volna lightweight webszerverre, csak így á la natúr, de ehhez képest a fél topik arról szól, hogy de miért legyen mégis Apache, meg ne PgSQL legyen, hanem MySQL, meg miért jó az Oracle...
Szerencsére azért voltak páran, akik hasznos tippeket adtak, nekik ezúton isoraz thx...

Oldschool Computer - http://oscomp.hu

Én továbbra sem értem ezt a szélsőséges biztonságba kapaszkodást és az OpenBSD választást. Inkább ezt szeretem a legjobban, ebben hiszek dolgot sejtek a háttérben, mint objektíven megítélt kisebb kockázatot. Pláne, miután a téma jó része a teljesítményről szól és épp most fejtette ki egy hozzászóló, hogy jelentősen rosszabb a teljesítménye.

Ezen felül ha rákeresek, hogy mennyi webszerver fut a világon, és ebből mennyi fut OpenBSD alatt (tippre a FreeBSD alatt futóknak is csak a töredéke), valamint megnézem, hogy mennyi webszerverből mennyi Apache, Nginx és Lighthttpd, akkor biztos kijön, hogy egy Debian 11 + Nginx + PHP-FPM + SQLite nem lenne olyan rossz választás egyszerűség stabilitás, teljesítmény, támogatás és biztonság kombóban...

Inkább ezt szeretem a legjobban, ebben hiszek dolgot sejtek a háttérben, mint objektíven megítélt kisebb kockázatot.

Te alapozol sejtésre, de engem vádolsz hittel? Ott a CVE database, nem hinni kell, hanem ott megnézni.

Pláne, miután a téma jó része a teljesítményről szól és épp most fejtette ki egy hozzászóló, hogy jelentősen rosszabb a teljesítménye.

A téma a webszerver teljesítményéről szólt, nem az OS-éről.

Ezen felül ha rákeresek, hogy mennyi webszerver fut a világon, és ebből mennyi fut OpenBSD alatt (tippre a FreeBSD alatt futóknak is csak a töredéke), valamint megnézem, hogy mennyi webszerverből mennyi Apache, Nginx és Lighthttpd, akkor biztos kijön, hogy egy Debian 11 + Nginx + PHP-FPM + SQLite nem lenne olyan rossz választás egyszerűség stabilitás, teljesítmény, támogatás és biztonság kombóban...

A popularitás, mint a kvalitás indikátora? Együnk tehénszart, a legyek nem tévednek? Engem nem a piaci részesedés érdekel, hanem a futással kapcsolatos nyers adatok. Ha azt mondod, hogy az OpenBSD lassabb, az rendben van, de az OS kapcsán a biztonság volt a szempont. A webszerver kapcsán volt kérdés a teljesítmény és az erőforrásigény. És, ha már erőforrásigény, az OpenBSD kevesebbet is eszik, a minimálkörnyezet miatt.

Oldschool Computer - http://oscomp.hu

Hát jó, akkor a Te stílusodban reagálok (ugyanis én objektiven írtam egy felvetést, nem érzelmektől fűtötten, mint az Te teszed itt többeknek).

Ha ilyen szélsőségesen aggódsz a CVE adatbázis tartalma miatt (hogy az alapján választasz szoftvert), akkor írj egy egyszerű HTTP szervert Pascal-ban (vagy tetszőlegesen választott más nyelven), és az mindenféle sebezhetőség nélkül (mert ugye a Te kódod mindig hibátlan, már tudhatjuk mindannyian) tudja majd küldeni a kliens felé az egyébként agyon cache-selt (kvázi statikus), eredetileg PHP által generált tartalmadat. Én napi szinten benne vagyok mindenféle szerver üzemeltetésben, és követem a híreket, és nem igazán sorjáznak a jelentések arról, hogy _akármelyik_ webszervert egy-egy sebezhetőségen keresztül nagy számban törögetnék fel. Arról inkább (amit írtam is máshol), hogy a PHP kódokban hemzsegő hibákat használják ki (ami nálad ugye nem jelent problémát, mert a Te kódod hibátlan mindig).

Az szomorú, ha szerinted a webszerver teljesítménye nincs összefüggésben az alatta futó OS teljesítményével. Ez a szemlélet összefüggésben lehet azzal, hogy a programozók felsőbbrendűnek gondolják magukat az üzemeltetőknél (azaz pontosabban minden más IT-s területnél, valami érthetetlen oknál fogva, és ráadásul ez iparági szinten megy, mert az IT felmérésekben is kizárólag fejlesztők szerepelnek...), és emiatt hajlamosak a rendszereket és üzemeltetésüket egy ilyen mellékes, nem fontos kérdésnek tekinteni, amiből aztán az ilyen hozzáállás születik, hogy az egyik szoftvert teljesítményében nem releváns a másik, valami módon kapcsolódó szoftver teljesítménye.

A popularitás és a kvalitás azért mutat némi párhuzamot a nyílt forrású szoftverek világában. Ugyanis az általam említett Debian azért populáris, mert biztonságos és megbízható a szakma szerint. Nyilván nem szerelemből használják olyan sokan, hanem azért, mert az a tapasztalat, hogy kevés gond van vele. Az ingyenes szoftvereknél eléggé erős összefüggés van a jóság és a népszerűség között. Ez persze a fizetős szoftvereknél nem feltétlen van így, mert ott egyéb tényezők is befolyásolják az eladott darabszámot, nem csak a szoftver jósága, de itt most kizárólag nyílt forrású, ingyenes szoftverek játszanak.

Jól van haver. Én veled itt befejeztem, mert azt rohadtul nem állom, hogy ha hazudoznak rólam. Sosem állítottam ilyet, hogy az én kódom mindig hibátlan lenne, ez gusztustalan, aljas hazugság. Gratulálok, mehetsz zeller után. Látom, itt fentebb is bepluszegyezted, amit zeller hazudozott, csak éppen az előzményeket szartad le, hogy hogy beszél ő velem, hogy mit művel minden topicban, ahol összefutunk; nem tűnt fel, hogy már alapból azzal nyitott, hogy nekiállt célozgatni, hogy szar a kódom? Mire alapozza ezt? Semmire, csak jön utánam kutyamód, minden topicban és baszogat. Ez téged nem érdekel, de ha visszaszólok neki, akkor magas lovon üldögélek, meg azt mondom, hogy mindig hibátlan a kódom.

Lófasz.

Oldschool Computer - http://oscomp.hu

Én utoljára általános suli harmadik-ban-negyedikben lehettem ilyen. Azóta eltelt bő 40 év, szerencsére kinőttem ezt a fajta hisztit.

Te futtatod magad, hogy milyen szuper, hibátlan kódot írsz mindig, kivétel nékül, bármilyen nyelven, akár számodra ismeretlen eszközökel is. Ezen felül feltettél egy kérdést, amire sokan sokféle választ adtunk, de ahelyett, hogy kipróbálnád, megfotolnád, megfogadnád bármelyiket, Te mindenkit meg akarsz győzni, hogy az eredetileg választott stack-ed az egyetlen járható út a feladat megoldására. Ergo azt akartad hallani, hogy "jobbat nem is találhatnál", de nem így történt, és nem tudsz vele mit kezdeni, így elkezdtél személyeskedni, megsértődni meg hazugozni többünket.

Egyáltalán nem vezérelt a Zeller által írt egyik HSZ sem a mondanivalómban, hanem readáltam a kérdésre, és a reakciókra. De visszaolvasva vélek hasonlóságot felfedezni abban, ahogy Ő meg ahogy én látom. De mivel Te tévedhetetlen vagy, így nyilvánvaló, hogy mi ketten gondoljuk rosszul. Ezzel nincs semmi bajom, nem tudhatok mindent (jól).

A topic-ból annyi tanulságot szűrtem le, hogy 1) ha kérdezel bármit, akkor nem válaszolok akkor sem, ha van tapasztalatom, mert felesleges; 2) ha bárhová bármit beírsz, akkor nem írok alá semmit, mert személyes támadásnak fogod venni, így elkerülöm az értelmetlen konfrontációt. Azért felírok egy pluszpontot, hogy a javaslatok kipróbálása helyett arra vetted a fárdtságot, hogy ki pluszegyezte azokat a HSZ-eket, amik neked nem tetszenek. Remélem listát is vezetsz rólunk.

Én utoljára általános suli harmadik-ban-negyedikben lehettem ilyen. Azóta eltelt bő 40 év, szerencsére kinőttem ezt a fajta hisztit.

Helyette rákaptál a hazudozásra? Alacsony energiaárakat is ígértél már?

Te futtatod magad, hogy milyen szuper, hibátlan kódot írsz mindig, kivétel nékül, bármilyen nyelven, akár számodra ismeretlen eszközökel is.

Már megint hazudsz. Én ilyet nem írtam sehol. Citáld be. Idézet nélkül könnyű ám hazudozni a másik emberről.

Itt annyi történt, hogy zeller megint bejött azért, hogy folyamatosan azt sulykolja, hogy szar kóder vagyok. Én meg a magam védelmére felhoztam, hogy mit raktam le eddig az asztalra. És szerinted ez ekvivalens azzal, hogy én futtatom magam, meg, hogy azt állítom, hogy mindig hibátlan kódot írok mindig, bármilyen nyelven.

Ehhez képest:
- Ctrl+F "kivétel nélkül": az első találat a te kommented. Vagyis ez a te hazugságod volt.
- Ctrl+F "bármilyen nyelv": az első találat a te kommented. Vagyis ez is a te hazugságod volt.
- Ctrl+F "hibátlan": az első találat a te kommented. Vagyis ez is csak a te hazugságod volt.

Az általad elmondottakból én zérót állítottam magamról. Mind a te gusztustalan hazugságod volt. Ezért kurwa érdemes volt bejönnöd.

Te mindenkit meg akarsz győzni, hogy az eredetileg választott stack-ed az egyetlen járható út

Ez is hazugság. Méghozzá orbitális. Én eredetileg Lighttpd-t akartam, de olyan sokan és olyan jókat mondtak az nginx javára, hogy szerintem azt fogom feltenni, mert meggyőztek. Ennyit rólad, meg a hazugságaidról.

De mivel Te tévedhetetlen vagy

Te vagy gerinctelen és hazug. Olyanokat adsz a számba, amit sosem mondtam.

Menj zeller után hazudozni a devnullba.

Oldschool Computer - http://oscomp.hu

Azt javasolnám, hogy a saját projekted nézd azért messzebbről, magasabbról. Anno FreeBSD 4.4 körül kezdtem a dolgokat, baromira sokat tanultam belőle, és valahogy az 5.x-nél az elsők között próbálkoztam a ZFS-sel (aztán kukázni kellett mindenféle okokból).

Az évek folyamán kiderült, hogy a BSD feeling akkor nyerő, hogy ha roppantmód elhivatott minden résztvevő arra, hogy a karbantartással jól lehessen foglalkozni. Azaz pénzt és időt nem sajnálnak ilyesmire, meg embert. Ezzel szemben amint a feladatok sűrűsödnek, látod, hogy mennyivel hatékonyabban lehet dolgozni Ubuntu vagy Debian (mások mondjuk CentOS) vonalon, akkor azért kikopnak a BSD-k. Kis projektnél hasonló kategória a Postgres.

Abba gondolj bele, hogy 3 év múlva mi lesz a szerverrel, kell majd migrálni? Vajon ha migrálod, akkor esetleg virtualizációra költözik? Ha esetleg már nem Te tartod karban, akkor át lehet könnyen adni másnak? Legyen ez beosztott, vagy ha távozol a cégből, akkor leizzadnak, hogy ők amúgy is migrálják egy számukra jobbra. De legyen pusztán azaz egyszerű eset, hogy neked nem lesz időd, lehetőséged ezt babusgatni olyan szinten, amit egy BSD + Postgres igényel a deb vonalhoz képest.

A CVE fronttal az a helyzet, hogy az alapvető SSH és szerver biztonsági dolgokat beállítod/betartod, akkor roppant kis eséllyel találnak be a szerver oldalról. Sokkal nagyobb esélyed lesz a PHP app mindenféle dolgait próbálgatni, legyen az SQL injection, futtatás (trükkös POST változó), vagy file feltöltési téma. Szóval változó ellenőrzések minden szinten, már a rewrite-tól indítva, mert mindennel is bepróbálkoznak robotizáltan. Igen, a való életben simán szippantottak ki egyedi PHP appban lévő SQL injection át dolgokat, nem voltam boldog, de a megbízó és fejlesztő mégjobban fogták a fejüket, amikor megmutattam, hogy nem sikerült ellenőrizniük, hogy id=1 az legyen már szám biztosan. Tudom, tudom, van WAF meg minden megoldás, viszont ez egy "megnyert" szerver volt, és korlátozott lehetőségekkel, illetve a szokásos ideoda rohangálással. A bónusz, hogy a jelszavakat sikerült sima md5 kódólniuk... nem volt egy sikersztori.

Dehát ez nem céges cucc... A migrálás meg egyelőre nem szempont. Ameddig bírja a gép, bírja. Ha elég a feladatra, akkor elég rá. Ha kinyiffan, akkor így jártam. Ez egy kényszermegoldás.
A PHP "appot" az elmúlt 15 évben sem törték eddig meg; amiket említettél, azok vagy le vannak védve, vagy lehetőség sincs rájuk (pl. feltöltés), szóval maximum magát a szerverkonfigot cseszhetem el úgy, hogy sérülékeny legyen.

Oldschool Computer - http://oscomp.hu

Egyetértek. Jó az OpenBSD, kevés RAM-ot fogyaszt, elegáns az egyszerűsége sok ponton, de egy Linux köröket fut köré teljesítményben. Jó lehet utóbbi több RAM-ot is eszik, de jobban van optimalizálva sebességre, és elbírja az a Phenom-os gép, amit a kolléga írt, a 8 giga RAM-nak is elégnek kéne lennie.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez nem Phenom, ez Athlon. Athlon II X4 615e. A 8 GB RAM sajnos nem jött össze, nem működnek benne a modulok. Marad a 2 GB, de a kolléga szerint (és mások szerint is) elég lesz az is.
Amúgy oké, hogy a Linux gyorsabb, mint az OpenBSD, de az OS esetében a fő szempont a biztonság volt, a másodlagos meg az erőforrásigény. Az OpenBSD kevesebbet eszik, mint egy Linux.

Oldschool Computer - http://oscomp.hu

a másodlagos meg az erőforrásigény. Az OpenBSD kevesebbet eszik, mint egy Linux

A Linux is tud keveset enni, csak ahhoz dolgozni kell rajta. Játszom olyan webszerverekkel, amelyek töredék erőforrással rendelkeznek a tiedhez képest, webes alkalmazásban átlag válaszidejük 15ms, a Linux memóriafoglalása 6 megabájt. Buildroot segítségével nagyon könnyű visszanyesni, hogy milyen szoftverek legyenek rajta, mik induljanak el, valamint saját kernelt ki lehet hozni három megabájtból, ha tűzfal is kell bele, akkor négy-öt. Hasonló eredményeket lehet kihozni OpenWRT-ből is.

( bocs | 2022. 07. 15., p – 10:18 )

Adatbázis "szerver"ként kimondottan erőforrás szűkös helyen SqLite?

Gondolkoztam rajta, de az SQLite-ot nem ismerem, csak nagyon felületesen. Lehet, hogy kevesebbet enne, mint a PgSQL, de a cache miatt azt hiszem összességében nem sokat számít, hogy milyen DB van a rendszer alatt.

Oldschool Computer - http://oscomp.hu

Fent írtad, hogy anno az Oracle-t sem ismerted semennyire, és két heted volt rá, és összejött. Akkor miért nem szánsz 1-2 napot az SQLite-ra? Az Oracle meg az SQLite azért finoman szólva sem egy liga tudásban és így rákészülésben sem. Valóban az lenne a legkisebb igényű mind közül, ha csak olyan funkciók kellenek, amik ebben is elérhetőek...

( bocs | 2022. 07. 15., p – 11:33 )

Szerkesztve: 2022. 07. 15., p – 11:49

Ez egy server daemon/process nélküli flat-file SQL adatbáziskezelő, de ACID-képes. Nem hiszem, hogy egy ekkora mikroprojekt olyat kérne tőle, amit ne tudna.
PHP-ban driverként van benne: mivel csak egy lib az egész, ezért a "szerver" benne van a driverben, tehát nem kell külön adatbázis szerver komponenst telepíteni.

( _ventura_ v | 2022. 07. 15., p – 14:11 )

Nem a vas gyenge, a kód szar :D

Fedora 42, Thinkpad x280

Leírtam: PHP+PgSQL, de a cacheing miatt a DB igazából mindegy és a PHP se sokat fog futni, mert kb. a letárolt page-eket fogja odaadogatni. Viszont sok fájlt lehet róla letölteni, kb. napi 100 fájlletöltés, de a pageview akár 100x annyi is lehet. És ezek csak a júzerek voltak, a robotokat nem tudom mennyi lesz, pl. a google robotja.

Oldschool Computer - http://oscomp.hu

Thx, az ilyen infók begyűjtése miatt indítottam a topikot. Azt ugyan nem definiáltad, hogy a normális vas az mit takar, de ha másodpercenként tud akár 10k-nyi kapcsolatot kezelni egy bármilyen mai PC-n, akkor valszeg túlaggódom a dolgot.

Oldschool Computer - http://oscomp.hu

Nem mondtam, mert nem volt éppen meg fejben. Most for the fun of it, a lehető legortóbb tesztet csináltam. Az nginx konténerbe belemountoltam egy kb ~2k-s random jsont, és meghajtottam maga mellől egy k6-al.

/k6 run k6.js                                                                                                                                                                                                            

          /\      |‾‾| /‾‾/   /‾‾/   
     /\  /  \     |  |/  /   /  /    
    /  \/    \    |     (   /   ‾‾\  
   /          \   |  |\  \ |  (‾)  | 
  / __________ \  |__| \__\ \_____/ .io

  execution: local
     script: k6.js
     output: -

  scenarios: (100.00%) 1 scenario, 10 max VUs, 1m30s max duration (incl. graceful stop):
           * default: 10 looping VUs for 1m0s (gracefulStop: 30s)


running (1m00.0s), 00/10 VUs, 763003 complete and 0 interrupted iterations
default ✓ [======================================] 10 VUs  1m0s

     data_received..................: 1.6 GB 27 MB/s
     data_sent......................: 68 MB  1.1 MB/s
     http_req_blocked...............: avg=2.99µs   min=1.09µs   med=2.26µs   max=7.83ms   p(90)=2.85µs  p(95)=3.37µs 
     http_req_connecting............: avg=260ns    min=0s       med=0s       max=1.56ms   p(90)=0s      p(95)=0s     
     http_req_duration..............: avg=707.71µs min=163.78µs med=614.56µs max=241.06ms p(90)=1.08ms  p(95)=1.29ms 
       { expected_response:true }...: avg=707.71µs min=163.78µs med=614.56µs max=241.06ms p(90)=1.08ms  p(95)=1.29ms 
     http_req_failed................: 0.00%  ✓ 0            ✗ 763003
     http_req_receiving.............: avg=48.65µs  min=17.45µs  med=36.18µs  max=14.53ms  p(90)=57.01µs p(95)=73.11µs
     http_req_sending...............: avg=12.94µs  min=5.49µs   med=11.01µs  max=8.96ms   p(90)=13.44µs p(95)=19.13µs
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s      p(95)=0s     
     http_req_waiting...............: avg=646.12µs min=108.12µs med=557.09µs max=241ms    p(90)=1.01ms  p(95)=1.21ms 
     http_reqs......................: 763003 12716.274372/s
     iteration_duration.............: avg=775.75µs min=218.02µs med=679.77µs max=241.13ms p(90)=1.15ms  p(95)=1.37ms 
     iterations.....................: 763003 12716.274372/s
     vus............................: 10     min=10         max=10  
     vus_max........................: 10     min=10         max=10

Ez a laptopom, ez van benne: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz. Közben egyébként az nginx összes szála láthatólag max olyan 80%-nyi procit evett htop alapján, szóval egy coret se, a többit felzabálta kb a k6 meg a járulék (syslog, ilyesmi). Az egész produkció a végére tesztkliensestől felzabált vagy 200 mega memóriát, meg az nginx konténer még megeszik kb 50et, mikor elindul.

Nyilván ez egy hevenyészett izé, meg nem https, meg nincs php meg mittomén, de azért szerintem belátható, hogy túlreagálod kissé :)

/off

Mondjuk mi ilyeneket fejlesztés közben is szoktunk nézni, mert különben nehéz belátni, hogy amit írtál, az jó, de pl arra is van metrika, ha hirtelen gyorsulna valami, akkor az alapból piros, mert szinte biztos, hogy nem ügyes vagy, hanem kipatcheltél valami fontosat. És egyébként is az üzemeltető teljesen jogosan azzal fogja kezdeni, hogy megkérdezni, hogyan kel méretezni. Tény, hogy ezután sok esetben az jön, hogy a fejlesztő pingvinezik, az üzemeltető meg morogva mér (vagy persze hasal alá valamit, aztán várja a shitstormot, hehe :D)

/on

Van már kb. 15 éve is talán, hogy utoljára ilyesmin dolgoztam. Akkor jött valaki, hogy meg ez és ez kellene. Adni nem adtak semmit. Megírtam az egészet cloudban és csók.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Én a konkrét esetben Oracle cloud-ot használtam, de másik esetben pl. Amazon AWS-t vagy máskor csak simán béreltem egy magyar VPS-t

Az első esetben az felhő költségét (fix időszakra) beleszámítottam a fix áras árajánlatba és így a programozással és oktatással együtt ezt is kifizették.

Az Amazonos esetben és a magyar VPS-ek esetében meg az kiszámláztam a költséget amíg a program készült, amikor meg megkapták a kész cuccot, megkapták az accountot is és azt is írásban, hogyan kell fizetni érte a jövőben.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Valóban. Azért mertem így tenni, mert egy VPS havi díja vagy egy cloud-ban egy kisebb szerver költsége alacsony tud lenni.

Mindenesetre ha onnan indultunk, hogy nincs szerver, oldjad meg ÉS nuku mani, akkor nem kell elvállalni a munkát. Főleg, hogy a VPS költségénél a te fizetésed mondjuk 100x (vagy 1000x) több lesz, így ha a VPS-t nem tudják kifizetni, akkor téged se fognak.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Mondom, én találkoztam olyannal, hogy ez a feladat, oldjad meg. Mondtam, hogy x pénz, azt mondták, rendben. Megoldottam. Kifizették. Mindenki örült.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ha nincs pénz a hw igényre, illetve sw környezetre, legyen az akár egy egyszerű VPS, akkor szükségük sincs arra, amiről azt gondolják, hogy majd "ingyen" megoldod. :) Szoktak az ilyen fellengzősnek gondolt dolgaimért utálni, de ez valszin így jó mindkét félnek.

Jellemzően akár egy holdutazásra is azt szokták gondolni, hogy páff az "ájtis" előhúzza a farzsebéből. Amikor közlöd, hogy azt sem tudod, hogy eszik-e vagy isszák, mert igazából tökmás a szakterületed, akkor néznek bután, hogy dehát ez ájti, neked csak 5 perc. Hamar vége szokott lenni a beszélgetésnek, már 20-25 év kűzdelem után ehhez nincs idegzetem.

hogy páff az "ájtis" előhúzza a farzsebéből. Amikor közlöd, hogy azt sem tudod, hogy eszik-e vagy isszák, mert igazából tökmás a szakterületed, akkor néznek bután, hogy dehát ez ájti, neked csak 5 perc

Ezeket az ügyfeleket én nagyon régóta nem láttam már. Talán az lehet a kulcs, hogy a napidíj kellően megszűri az ilyen fogalmatlanokat.

Honnan tudjam? Még sosem találkoztam olyan céggel, ahol nekem kellett volna szervert intézni. Mint leírtam, a szerver mindig adott volt. Csak bennyh mondta, hogy van, ahol még azt is az embernek kéne szerválnia, én meg mondtam, hogy pénz nélkül nem megy. Azóta tkp. már teljesen elment a szál az irrealitások és a fikciók irányába...

Oldschool Computer - http://oscomp.hu

( kruska v | 2022. 07. 16., szo – 10:16 )

Néhány szempontot én is írok:

- ha a fileletöltést nem a static webszerver, hanem a PHP szolgálja ki, akkor teljesítmény szempontjából kb. mindegy milyen webszervert használsz (a kiszolgálási idő töredékéért felelős csak így)

- ha FPM-et használsz, új requestnél nem indít új PHP processzt (mint pl. Apache mod_php), ezért gyorsabb.

- az opcache megspórolja a PHP fordítási időt. Kell figyelni a statisztikát, hogy minden kódod beleférjen, és feljebbvenni a méretét, ha szükséges.

- 2M adatbázisra szerintem is jó az sqlite3, de azért tudni kell, hogy az erős konkurencia (sok egyidejű látogató) nem az erőssége. Pont az a hátránya ilyenkor, ami az előnye, hogy nincs külön adatbáziskezelő engine, hanem a párhuzamosan futó processzek egymástól függetlenül direktben piszkálják a db file-t. WAL a barátod. Ha nem várható sok egyidejű írás, akkor ez nem gond.

> kb. a letárolt page-eket fogja odaadogatni.

Statikus tartalom ne menjen PHP-n keresztül, ha nincs rá nyomós ok. A kiszolgálási idő túlnyomóan nagy részét a PHP futásidő adja, meg kell spórolni ahol lehet. 

Köszi a tippeket, ezt a statikusat PHP-n keresztül ne, ezt jó, hogy mondod, mert az eredeti fejlesztő úgy oldotta meg a fájlletöltést. Igaz, gondot nem okozott eddig, de eddig sokkal erősebb vas volt alatta, meg jobb kapcsolat, stb.

Csak FPM-et tudok használni, mert (AFAIK) sem az nginx, sem a Lighttpd nem támogat mást. (fixme)

Az opcache-et ismerem, a mérettel nem lesz szerintem gond, 135k az össz. PHP és ebbe benne van az admin felület is, meg a mindenféle "toolok", amik kívülről vannak meghívogatva.

DB, az marad PgSQL, mert azt ismerem, meg amúgy is cache-elve lesz az egész. :)

Oldschool Computer - http://oscomp.hu

( azbest | 2022. 07. 16., szo – 12:24 )

Remélem ez csak valami hobbi vagy retro projekt, mert ha ez lesz a "production" szerver több cégnek, akkor már régen rossz az, ami felé elment az egész topic.

Szerintem semmi értelme mindenféle világmegváltó gondolatnak és enterprise infrastruktúra teljesítmény elemezgetésnek egy játszós retro gépnél.
Ha production, akkor meg olyan fillérbaszásról és minimál költségvetésről van szó, aminél meg azért nincs értelme semmi enterprise dologról elméknedni vagy akár bármi nagy szakértelmet mögé tenni, gondolni.

Dehogy production... Semmi cég, saját cucc. Komoly infrastruktúrát nem pakolnék egy ilyen gépre. Ez kényszermegoldás két saját weblapra. Viszont attól még jó lenne, ha menne, szóval utánakérdeztem pár dolognak. Nem kell túl sokat mögélátni.

Oldschool Computer - http://oscomp.hu