Как тяжелые Java-потоки по сравнению с Scala/акками Akka?
Я просто сравнивал производительность scala актеров против java-потоков.
Я был поражен, увидев разницу, я заметил, что с моей системой я смог создать максимум ~ 2000 потоков (только за один раз). Но с той же системой я смог создать ~ 500 000 участников scala,
Обе программы используют около 81 Мбайт кучной памяти JVM.
Можете ли вы объяснить, насколько поток java намного тяжелее, чем актеры scala/akka?
Каков ключевой фактор, который сделал scala -актив этого очень легкого веса?
Если я хочу достичь наилучшей масштабируемости, должен ли я перейти на веб-сервер, основанный на актерах, вместо традиционного веб-сервера приложений или Java, например JBoss или Tomcat?
Спасибо.
Ответы
Ответ 1
Scala актеры (включая сорт Akka) используют потоки Java. Там нет магии: более нескольких тысяч потоков, работающих одновременно, является проблемой для большинства настольных компьютеров.
Модель Actor позволяет актерам с активными действиями, которые не занимают нить, если у них нет работы. Некоторые проблемы могут быть эффективно смоделированы, так как многие спящие ждут, чтобы получить какую-то работу, кто сделает это относительно быстро, а затем снова заснет. В этом случае актеры - очень эффективный способ использовать потоки Java для выполнения вашей работы, особенно если у вас есть библиотека, такая как Akka, где производительность была высокоприоритетной.
Akka docs хорошо объясняют основы.
Все достаточно масштабируемые веб-серверы должны решать такую проблему так или иначе; вы, вероятно, не должны основывать свое решение на веб-сервере в первую очередь на том, используются ли актеры под капотом, и независимо от того, что вы используете, вы всегда можете добавлять актеров самостоятельно.
Ответ 2
Акк Акка не эквивалентен нитке. Это больше похоже на Callable
, который выполняется в threadpool.
Когда сообщение отправляется актеру, этот актер помещается в threadpool для обработки сообщения. Когда это будет сделано, объединенный поток может использоваться для выполнения других участников.