Webszerver szoftverek és malware-ek

Internet, Közösségi média

A Google egy felmérést készített arról, hogy a webszerver piacon található legnépszerűbb szoftvereknek (Apache, IIS, és a futottak még kategória) milyen részesedésük van. Emellett megvizsgálták, a ezen webszerverek milyen mértékben veszik ki részüket a malware programok terjesztéséból. A felmérés eredménye itt.

( tepsi | 2007. 06. 06., sze – 20:30 )

Annyira kíváncsi lennék arra 7% Egyéb-re...

"[...] automatic updates have not been enabled due to software piracy [...], some security patches are not available for pirated copies of Microsoft operating systems. For instance the patch for a commonly seen ADODB.Stream exploit is not available to pirated copies of Windows operating systems."

kínában kicsit több a warezwin

( zsolt | 2007. 06. 06., sze – 21:09 )

Ez az nginx valami egészen elképesztő web szerver. Végre valaki észrevette, hogy a socket-eket aszinkron módon kezelve sokkal hatékonyabb szervereket lehet írni.
Az apache és az IIS már 5 éve is elavult technológiákat használtak. Nem csodálkoznék, ha néhány év múlva az nginx-nek lenne olyan részesedése, mint most az Apache-nak.
Használja itt valaki élesben?

Igen az, de tudtommal lighttpd nem használja a kernelek eseménykezelő architektúráját (kqueue, epoll), így kicsit az is le van maradva.
Ezért van, hogy nginx 10 ezer inaktív párhuzamos kérés esetén (http-keepalive) még normális válaszidővel dolgozik és mindössze 2,5 MB memóriát eszik.
Persze Apache/IIS ekkora terhelés töredékénél már rég belepusztultak a rohamba :)

A szerverekkel kapcsolatos legfőbb problámák és a megoldásuk ebben az írásban nagyon jól össze vannak gyűjtve: http://www.kegel.com/c10k.html
Szerintem alapmű, amit minden programozónak és rendszergazdának ismerni kéne, hogy szakadjanak már el az ősi multi-process szerverektől. Szerintem olvasd el és nem fogsz ilyeneket kérdezni.
Ez meg egy nagyon jól használható lib eseményvezérelt aszinkron szerverek fejlesztéséhez: http://www.monkey.org/~provos/libevent/

epoll/libevent meggyőző, már el is felejtetem a régi poll(), select() létezését :)
/dev/poll jobbab, mint poll() nagy terhelésnél , hmm érdekes.
500-700 usec (~25%) el gyorsabb a válasz ideje a kqueue -nek a teszt szerint, mint az epoll()-nak az se rosz.

De mégis, hogyan lehet sok processel megoldani ? Nincs kedvem szétturni az apache-t a kiderítésére.

( tr1719 | 2007. 06. 07., cs – 00:03 )

Bocsi ha hülyeséget kérdezek, de Kínában miért van ~98% IIS használat? No meg Dél- Kórea is érdekelne.

( bervi | 2007. 06. 07., cs – 01:49 )

hmm. nem úgy volt hogy kína linuxbuzi? szerk: ja de, benéztem

az nginx meg szépen feljött, bár én nem használom, de állítólag kafa. aszinkron szoketekbe nem mennék bele, nem értek hozzá. de látszik, hogy a cccp warez oldalak favorizálják legjobban :P:-)

egyébként
http://superjared.com/entry/benching-lighttpd-vs-nginx-static-files/

sebességben kb ugyanaz, de nginx javára szól ez a komment:

"in my simple stress tests cpu usage showed lighttpd at 98% while nginx was never more than 52%."

Meg kellett volna néznie dinamikus kontenttel is, hogy pl. egy phpinfo()-val mit ad elő fastcgi-ben.
Ahogy írja, mindkettőnél előbb fogyna el a sávszél, mint a hw-erőforrás.
Igen aktívan fejlesztik mindkettőt, ahogy elnézem, az nginx-nek mondjuk egy kissé rendezettebb oldal nem ártana, egyébként jónak tűnik, az visszatartú lehet, hogy nincs CGI, bár le is írja, hogy szar.
It doesn't matter if you like my song as long as you can hear me sing

sebességben kb ugyanaz, de nginx javára szól ez a komment:

"in my simple stress tests cpu usage showed lighttpd at 98% while nginx was never more than 52%."

Ezt többféleképpen lehet értelmezni...

Azoknál a teszteknél ahol a CPU használat 50% körülire jön ki én mindig elkezdek gyanakodni, hogy nem azért lett-e ennyi, mert az SMP/SMT tesztgépen nem skálázódott rendesen az applikáció és csak az egyik processzort hajtotta meg teljesen.