On Thu, 2005-08-11 at 18:04 +0200, Attila Nagy wrote:
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).
aha, ez indokolhatja a kulonbseget.
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? :).
nem tudom :) azt nem is mondtam, hogy notebook-rol van szo, ahhoz kepest nem is rossz.
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á)?
Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem, hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul fussanak.
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. :)
naja, ha az openssl magan a kartyan futna es lenne ott egy kulon TCP/IP stack.
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?
1) az openssl-ben van processzen beluli session cache, ezt kulon implementalni nem kell 2) megneztem kozelebbrol, es sajnos ahogy a Zorp hasznalja az SSL-t, ugy ez a cache nem mukodik. fel is vettem egy hibajegyet ezzel kapcsolatban.
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?
bar a memcached-t nem ismerem, de az OpenSSL lehetove teszi un. "external session id cache" letrehozasat, ezt hasznalja az apache is a fork()-olt processzek kotzi adatmegosztashoz.
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 ilyet, bar nem tudom milyen gyakorlati elonnyel jarna. nyilvan a kiesett node miatt a kliens atkerulhet egy masik gepre, de ott is max egy kulcs-cseret kell vegrehajtania, es utana mar ott is cachelt a kapcsolata.
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?
meg nem :)
Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye vagyok a zorphoz, na. :)
jelenleg session informaciot csak a peldanyon belul lehet megtartani, ott viszont eleg egyszeru. (azaz azt meg lehet oldani kizarolag Zorp-bol, hogy a sikeres POP3 authentikacio utan mukodik az SMTP, bar ugye ezt mar tulhaladta a kor az SMTP auth miatt). -- Bazsi