RServe - Масштабируемость

Question

Мое требование - выполнить R-скрипт через Java Webservice. Для веб-службы требуется параллелизм 50.

Мы используем RServe для выполнения R-скрипта из кода Java. Для этого на сервере linux мы создали 50 экземпляров RServe, запущенных на разных портах. Внутри приложения java создан пул соединений с 50 объектами RConnection, каждый из которых связан с одним из экземпляров RServe. Для каждого выполнения мы получаем RConnection из пула, выполняем R-скрипт, получаем значение ответа и затем возвращаем RConnection в пул.

Когда мы выполняем web-сервис с одним доступом пользователя, выполнение R завершается за 1 секунду. Однако, если я попытаюсь запустить тот же web-сервис с параллелизмом 50, для выполнения R-скрипта внутри RServe потребуется около 30 секунд. Поскольку фактическое выполнение R занимает всего 1 секунду, если выполнено с одним пользователем, Im думает, что Im делает что-то неправильно с RServe. Любые указатели помогут.

Answer 1

Хотя я считаю, что лучше всего использовать один экземпляр Rserve в Linux и позволить ему просто подпроцессы fork для параллельной обработки, это может не ускорить обработку вообще. С вашего вопроса неясно, интенсивно ли используется приложение, и много одновременных запросов обрабатываются постоянно. Если это так, я полагаю, что ваш R-код интенсивно работает на процессоре, а разные процессы просто требуют совместного использования процессорного времени, увеличивая время, необходимое для завершения.

Я испытал только такой сценарий и нашел эти результаты с top

PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND 
33839 *****  20 0 269792 57104 3496 R 10.3 1.5 0:15.33 Rserve 
33847 *****  20 0 269776 57100 3496 R 10.3 1.5 0:09.86 Rserve 
33849 *****  20 0 269792 57104 3496 R 10.3 1.5 0:08.20 Rserve 
33855 *****  20 0 269528 56840 3496 R 10.3 1.5 0:04.92 Rserve 
29725 *****  20 0 268872 56836 4020 R 10.0 1.5 1360:13 Rserve 
33841 *****  20 0 269784 57100 3496 R 10.0 1.5 0:14.42 Rserve 
33843 *****  20 0 269796 57104 3496 R 10.0 1.5 0:12.50 Rserve 
33844 *****  20 0 269792 57104 3496 R 10.0 1.5 0:11.72 Rserve 
33852 *****  20 0 269512 56836 3496 R 10.0 1.5 0:06.38 Rserve 
33856 *****  20 0 269520 56836 3496 R 10.0 1.5 0:04.05 Rserve 
33842 *****  20 0 269776 57100 3496 R 9.3 1.5 0:13.20 Rserve 
33851 *****  20 0 269784 57100 3496 R 9.3 1.5 0:06.69 Rserve 
33857 *****  20 0 269512 56836 3496 R 9.3 1.5 0:03.15 Rserve 
33834 *****  20 0 269792 57112 3496 R 9.0 1.5 0:18.56 Rserve 
33835 *****  20 0 269784 57100 3496 R 9.0 1.5 0:17.33 Rserve 
33837 *****  20 0 269776 57100 3496 R 9.0 1.5 0:16.46 Rserve 
33846 *****  20 0 269784 57100 3496 R 9.0 1.5 0:10.17 Rserve 
33848 *****  20 0 269796 57104 3496 R 9.0 1.5 0:08.61 Rserve 
33853 *****  20 0 269532 56840 3496 R 9.0 1.5 0:05.34 Rserve 
33858 *****  20 0 269532 56840 3496 R 9.0 1.5 0:02.27 Rserve 
33838 *****  20 0 269796 57104 3496 R 8.6 1.5 0:15.74 Rserve 

В% суммы CPU до 200%, что соответствует двум процессорных ядер, доступных.

Как вы можете видеть, процессы имеют одинаковый приоритет (PR = 20), а доли% CPU почти равны, около 10%, поэтому все они будут распределены только на 1/10 из времени процессора и, следовательно, потребуется в 10 раз дольше для завершения, по сравнению с случаем только одного экземпляра Rserve.

Это не в 20 раз больше, потому что в одном процессе Rserve будет использоваться только одно ядро ​​ЦП, оставив другое ядро ​​«спящим».

Вам просто нужно больше CPU, если вы хотите ускорить вычисления. Кроме того, если вы не хотите, чтобы 51-й (или 101-й или 1001-й) одновременный пользователь был лишен доступа, лучше реализовать очередь сообщений. Вы можете создать нескольких сотрудников для очереди, которые могут распространять рабочую нагрузку на многие процессоры на разных машинах.