Служба исполнителя или потоки демонов, что лучше для многопоточности? - PullRequest
0 голосов
/ 13 июня 2018

извините за длинное редактирование,

Я пытаюсь загрузить 100 тыс. URL, и я начал скачивать, используя службу executor, как показано ниже,

ExecutorService executorService = Executors.newFixedThreadPool(100);
for (int i = 0; i < list.size(); i++) {
    try {
        Callable callable = new Callable() {
            public List<String> call() throws Exception {
                //http connection
            }
        };
Future future = executorService.submit(callable);

, но вышеуказанный метод загружает данныетолько один URL за раз ..

и поэтому я попытался создать потоки демона (как показано ниже), и этот метод создал несколько подключений загрузки (как и ожидалось) ..

for(int i=0; i<10; i++) {
    Thread t = new Thread("loadtest " + i);
    t.setDaemon(true);
    t.start();
}

while(true) {
    boolean flag = true;
    Set<Thread> threads = Thread.getAllStackTraces().keySet();
    for(Thread t : threads) {
        if(t.isDaemon() && t.getName().startsWith("loadtest")) {
            flag = false;
            break;
        }
    }
    if(flag)
        break;
    Thread.sleep(5000);
}

Можетэтот же метод будет использоваться для нагрузочного тестирования на серверах?

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

Заранее спасибо!

Ответы [ 3 ]

0 голосов
/ 13 июня 2018

Я рискну предположить, что ваш ExecutorService не работает, потому что вы вызываете get() для Future экземпляров, которые возвращают в вашем цикле. Эта ошибка действительно приведет к тому, что ваша обработка будетсериализовано, как если бы у вас был только один поток, потому что другая задача не была отправлена ​​до тех пор, пока не завершится первая.

Если вам действительно нужно использовать Callable, не get() результат, пока вы не готовыблокировать на неопределенное время по мере выполнения задач - и они не могут завершиться, если они еще не были отправлены.Для загрузки URL-адресов лучше использовать Runnable, где основной поток отправляет URL-адреса, а затем забывает о задаче;задача может самостоятельно завершить обработку своего URL.

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

0 голосов
/ 13 июня 2018

Нагрузочное тестирование - это не только «забивание» вашего сервера запросами, но и корректное нагрузочное тестирование должно представлять реального пользователя с использованием реального браузера со всеми связанными вещами, такими как:

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

0 голосов
/ 13 июня 2018

Поток демона - это поток, который не препятствует завершению JVM после завершения всех остальных потоков.

Я полагаю, что если вы хотите дождаться своего основного потока до тех пор, пока не завершатся потоки времени демона, то я предлагаю неиспользовать поток демона, как предполагается, не будет использоваться для этого варианта использования.Вы можете использовать Thread#join для ожидания вашего основного потока.

for(int i=0; i<10; i++) {
    Thread t = new Thread("loadtest " + i);
    t.setDaemon(true);
    t.start();
    t.join(); // main or parent thread will wait util the child thread finished 
}

Я считаю, что в вашем случае вы должны использовать обычный поток вместо демона.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...