Как проверить потокобезопасность приложения Rails для Puma

Я хочу развернуть свое приложение Rails на Heroku с помощью веб-сервера Puma. Однако я не совсем уверен, что все драгоценные камни являются потокобезопасными. Чтение всего исходного кода Gems для нас невыполнимо.

Есть ли способ автоматически проверять все драгоценные камни на безопасность потоков? Или Puma жалуется/отображает определенный журнал ошибок, если был выполнен/обнаружен небезопасный код потока?


ruby ruby-on-rails multithreading heroku puma
person Pahlevi Fikri Auliya    schedule 29.05.2015    source источник
comment
FWIW Потокобезопасность в ruby ​​в лучшем случае сомнительна. Это одна из причин, по которой Хосе создал Эликсир. Я бы не стал рассчитывать на безопасность потоков в любом рубиновом коде. Лучше всего использовать rubinius или jruby   -  person engineerDave    schedule 06.06.2015

Ответы (1)


arrow_upward
-3
arrow_downward

Потокобезопасность вообще не может быть обнаружена. Если бы был какой-то способ определить это автоматически, возможно, ваш компилятор/интерпретатор предупредил бы вас об этом. условия гонки не могут быть обнаружены автоматическими системами, их даже трудно воспроизвести.

В зависимости от вашего переводчика:

  • CRuby имеет GIL, поэтому использовать с ним Puma бессмысленно.
  • Если вы используете JRuby или Rubinius, вы, вероятно, можете извлечь выгоду из Puma, и, скорее всего, используемые вами драгоценные камни задокументировали свои методы/классы потокобезопасности. В этом случае все, что вам нужно, это проверить свой код.
person hahcho    schedule 29.05.2015
comment
Интерпретатор, использующий GIL, всегда будет разрешать выполнение только одного потока за раз, даже если он работает на многоядерном процессоре => до тех пор, пока память является общей, разве это не возможно для тупика, условий гонки, проблемы с живучестью? происходить? - person Pahlevi Fikri Auliya; 30.05.2015
comment
Хорошо, вы правы в этом. GIL упрощает большинство возможных проблем с потоками, которые могут возникнуть. Вы правы, главное, что вы не можете тестировать код на безопасность потоков каким-то автоматическим способом, и использование Puma для реализации Ruby с GIL не имеет преимуществ перед использованием, например, Unicorn. - person hahcho; 31.05.2015
comment
Отличная статья: bearmetal.eu/theden/ - person Pahlevi Fikri Auliya; 01.06.2015
comment
Даже с GIL использование многопоточности имеет свои преимущества. Конечно, вы не сможете запускать свою программу более чем на 1 ЦП одновременно, но все время, потраченное на ожидание после сети или ввода-вывода в целом, можно использовать для выполнения чего-то еще в том же процессе. Кроме того, вы в конечном итоге будете использовать гораздо меньше оперативной памяти. См., например, Sidekiq. - person Anthony Alberto; 01.06.2015
comment
Я все еще ищу актуальные тесты для MRI Ruby хода Puma и MRI Ruby хода Unicorn. Если вы можете показать что-то, я бы согласился, но до тех пор я думаю, что это просто предположение. Конечно, все, что вы говорите, верно в теории, но на практике, особенно когда речь идет о параллельном выполнении, все обстоит иначе. - person hahcho; 02.06.2015
comment
Была и, вероятно, все еще сохраняется проблема, связанная с тем, что Unicorn подвержен атаке медленных клиентов как форме тривиального DoS. По этой причине Heroku теперь рекомендует использовать Puma вместо Unicorn в качестве веб-сервера Ruby. - person David Unric; 02.06.2015
comment
@DavidUnric Разве не поэтому они обычно рекомендуют запускать Unicorn за обратным прокси-сервером, например Nginx? - person art-solopov; 03.06.2015
comment
@art-solopov Это может частично помочь в ряде ситуаций, но выделенная атака может просто обойти размер буфера nginx и все равно повесить Unicorn. Я прочитал техническую основу, но не могу сейчас найти ссылку. - person David Unric; 04.06.2015
comment
эта статья также интересна tomkadwill.com/benefits-of-switching-from -единорог-пуме - person Cris R; 18.10.2019