LINUX.ORG.RU
ФорумTalks

Mail.ru жжёт

 , ,


0

3

http://habrahabr.ru/company/mailru/blog/158603/

И напоследок расскажу о небольшом хаке, который тоже существенно увеличил производительность. Мы сделали линк с /dev/random на /dev/urandom. Работает быстрее, потому что /dev/random блокирующий, /dev/urandom не блокирующий. Следовательно, I/O wait сокращается.

Ололо, поменять ГСЧ на ГПСЧ это ж надо додуматься. Еще от этого оказывается iowait «сокращается».

★★★

Последнее исправление: Klymedy (всего исправлений: 1)

ты только сейчас понял, что они наркоманы?

der_looser ★★
()
Ответ на: комментарий от goingUp

Да, не прочитал сообщение. Что можно сказать, это 3.1415здец.

Reset ★★★★★
()

Ололо, поменять ГСЧ на ГПСЧ это ж надо додуматься.

Не ГПСЧ, а КГПСЧ.

Насколько я по диагонали просмотрел статью, /dev/random там используется для сеансовых ключей. Соответсвенно, прежде чем кричать «ололо» стоит узнать матчасть, как устроен urandom в Linux и почему его здесь достаточно. А если не параноить, то достаточно даже для всех задач.

Собственно в man random английским по белому написано: «As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys». Нуф сейд.

atrus ★★★★★
()
Последнее исправление: atrus (всего исправлений: 2)
Ответ на: комментарий от xtraeft

надо было сделать линк на /dev/null или zero - он еще быстрее

не, оверхед на сисколы open/read/close. проще константу захардкодить.

exception13 ★★★★★
()
Ответ на: комментарий от atrus

ты бы абзац полностью привел уж

If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys.

лично я считаю, что авторы openssl достаточно компетентны в вопросе, что именно в каком случае нужно использовать.

maloi ★★★★★
()

Я на своей андройдной мобилке уже давно так сделал.

anonymous_sama ★★★★★
()
Ответ на: комментарий от maloi

ты бы абзац полностью привел уж

И? На гугл транслейте забанили? ;-)

«Если вы не уверены насчёт того, что из /dev/random и /dev/urandom вам нужно, тогда, вероятно, вам стоит использовать последний». Последний - urandom.

лично я считаю, что авторы openssl достаточно компетентны

Они компетентны, если после них над исходниками не поработают «специалисты» из Debian. Это я шучу.

Так вот. Они компетентны. Но они не телепаты. И они не знают, как вы будете использовать библиотеку. По этому вынуждены выбирать наихудший сценарий.

atrus ★★★★★
()
Ответ на: комментарий от atrus

И? На гугл транслейте забанили? ;-)

я к тому, что авторы криптографических библиотек - уверены, в отличие от администраторов.

Так вот. Они компетентны. Но они не телепаты. И они не знают, как вы будете использовать библиотеку. По этому вынуждены выбирать наихудший сценарий.

Cryptographic software needs a source of unpredictable data to work
correctly.  Many open source operating systems provide a "randomness
device" (/dev/urandom or /dev/random) that serves this purpose.
All OpenSSL versions try to use /dev/urandom by default; starting with
version 0.9.7, OpenSSL also tries /dev/random if /dev/urandom is not
available.

простите, это какой-то другой openssl?

maloi ★★★★★
()
Последнее исправление: maloi (всего исправлений: 1)

При чтении устройство /dev/random возвращает единичные случайные байты, количество битов шума в которых равно количеству бит шума в пуле энтропии. /dev/random следует использовать, если требуется высокий коэффициент случайности, например, при использовании одноразовой шифровки (one-time pad) или при генерации ключа. Если пул энтропии пуст, попытка чтения /dev/random приведёт к задержке, пока не будет собран дополнительный окружающий шум.

При чтении устройство /dev/urandom возвратит столько байтов, сколько было запрошено. Как результат, если в пуле недостаточная энтропия, то возвращённые значения теоретически нестойки к криптографической атаке на алгоритмы, используемые драйвером. О том, как это сделать, не сказано в современной несекретной литературе, но теоретически возможно, что такая атака может существовать. Если это важно для вашего приложения, используйте лучше /dev/ran- dom.

Ну и в чем драма? Я бы понял напряг, если бы речь шла о туннеле для какой-то действительно важной инфы, но это же просто почта на мэйлрушечке.

Manhunt ★★★★★
()
Ответ на: комментарий от atrus

а зачем ее выносить, если через год снова затаскивать? только напрасно силы тратить

der_looser ★★
()
Ответ на: комментарий от maloi

простите, это какой-то другой openssl?

Не знаю. :) Тут надо вставить шутку про 0.9.7 и новьё. :)

Однако, если уж в официальном руководстве от openssl такое написано, то ололошеньки топикастера точно не имеют под собой оснований.

atrus ★★★★★
()
Ответ на: комментарий от atrus

Ну раз «All OpenSSL versions try to use /dev/urandom by default» то симлинк бы ничего не изменил. А они заявляют от приросте в два раза.

Во всяком случае, очень сомнительная «оптимизация», и что-то я ни у кого больше о таком не читал.

disarmer ★★★
() автор топика

А все зависит от участка кода. Местами можно делать руками srandom(3) + random(3), что еще быстрее. Более того, не вижу смысла вообще обращать внимания на mail.ru, т.к. слив инфы у них делается более простыми способами :)

Позабавило это:

Ну, и последнее, про что я хотел рассказать — оптимизация. Можно было бы, конечно, накупить железа и покрыть возросшие затраты по процессорному времени и памяти, но это не наш метод.

Из чего следует, что их баннеры нафиг никому не нужны, а вот если в том же контексте передаются кукисы, авторизации, шмаризации, то да - ССЗБ.

gh0stwizard ★★★★★
()
Ответ на: комментарий от disarmer

openssl не единственная библиотека подобного рода. может у них там gnutls или еще что-то...

atrus ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.