Balazs Scheidler wrote:
ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge): Xeon: FreeBSD 5.4 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.2 [FreeBSD] 20040728
Opteron: FreeBSD 6.0 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.4 [FreeBSD] 20050518 Mindkét gép AMD64-es üzemmódban megy (azaz a Xeon EM64T, ahogy az Intel szeretné hívni).
sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1314.0 14458.4 rsa 1024 bits 0.0038s 0.0002s 262.1 4719.6 rsa 2048 bits 0.0232s 0.0007s 43.1 1417.8 rsa 4096 bits 0.1592s 0.0025s 6.3 405.3
Az asztali gépem (2,8 GHz P4) is hasonlót tud: sign verify sign/s verify/s rsa 512 bits 0.0009s 0.0001s 1140.6 12345.8 rsa 1024 bits 0.0042s 0.0002s 236.6 4348.8 rsa 2048 bits 0.0254s 0.0008s 39.4 1325.1 rsa 4096 bits 0.1704s 0.0026s 5.9 378.1
Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat. 512 kB cache-sel rendelkező 3,06 GHz-es Xeon: sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1268.6 13669.1 rsa 1024 bits 0.0039s 0.0002s 258.5 4820.7 rsa 2048 bits 0.0232s 0.0007s 43.1 1476.1 rsa 4096 bits 0.1563s 0.0024s 6.4 416.5
A te géped megveri (lehet, hogy FSB, vagy valami chipset mágia, vagy csak a FreeBSD ilyen gagyi? :).
Gondolom ti is végeztetek mérést ilyen kártyákkal. Mikor ajánljátok? Ajánljátok? Nagy mennyisegu SSL kapcsolatoknal igen, a gepnek eppen eleg dolga van a forgalom kezelesevel. Az eddigi számok alapján nekem úgy tűnik, hogy alternatívája lehet a sok olcsó gép a sok olcsó gép+kriptokártya felállásnak.
Persze itt is a terhelési minta a meghatározó. Ahol sok kapcsolatfelépítés van, jó lehet a kártya, de ahol inkább adatmozgatás, azt kilapátolja a PC is.
Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két processzoros dual core opteronos gépet, amely a fenti benchmark szerint olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik... Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna, ha viszont betolod egy Linux ala, akkor a processzorok kozti context switcheknek egy ido utan eleg nagy az overheadje. Persze, a processzek közötti környezetváltás is rengeteg idő, főleg ha másik processzorra migrálja az OS. :)
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag megvalósítható lenne az is, hogy ezeket a processzeket egyes processzorra dedikálja a user, azokból pedig load balance-olt poolt építsen. Végeztetek esetleg mérést arra nézve, hogy egy ilyen lehetőség mennyit segítene (a fentiekből azt feltételezem, hogy most a zorp nem külön végzi ezeket a műveleteket, így nem is lehet procit dedikálni alá)? Ha jelentős lenne a különbség, sokat dobhatna a teljesítményen, főleg a mostani multicore-os CPU-k esetében.
Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő felépítés esetén ez a késleltetés kiiktatható. Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL Persze, azt hiszem ezt már csak durva firmware hackkel lehetne megoldani. De erre is volt már példa. :)
Az nForce 800-as az 100k forintos nagysagrend (max 200k, nem emlekszem pontosan), Ultra-t meg nem hasznaltunk. Köszi.
Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :) Cache-elhetők ezek az SSL kapcsolatok? Elvileg igen. Az mit jelent? Az apache-ban például van SSL session cache. Van ilyen a zorpban?
Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del ezt a session store-t több gépen is használhatóvá tegyük? Teszemazt ha valódi load balancingot szeretnénk, nem pedig IP alapú stickys megoldást. (minden új kapcsolat mehet más zorpra, még ugyanarról az IP-ről is) Lehet, hogy inkább doksit kellene olvasnom, de ha már így belejöttem, megkérdezem azt is, hogy a többi (ha van) session jellegű infó közös tárolására vizsgáltátok-e már egy ilyen elosztott tudás jellegű megoldás előnyeit? Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye vagyok a zorphoz, na. :) -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758