2015-01-29 3 views
3

사용자 이름과 암호가 포함 된 CSV 파일을 사용하여 세션 ID를 얻고 saveAs를 사용하여 저장하는 시나리오가 있습니다.수집 시나리오간에 데이터 공유

세션 ID가 필요한 몇 가지 작업을 수행하는 다음 시나리오에서 해당 세션 ID를 사용할 수 있기를 원합니다. 또한 세션 ID와 사용자 이름을 상호 연관시키고 싶습니다.

본질적으로 나머지 작업에서 로그인 작업 (세션 ID 얻기)을 순차 화하려고합니다. 그것은 개 틀림에서 가능한가? 그렇다면 시나리오간에 데이터를 전달하는 방법은 무엇입니까?

답변

7

나는이 질문이 오래되었다는 것을 알고 있지만, 내 자신을 위해 비슷한 문제를 연구하면서 그것을 발견했으며 다른 사람들이 비슷한 문제를 겪을 경우를 대비하여 내가 도달 한 해결책을 나눌 것이라고 생각했습니다. 내 상황이 완전히 비슷하지는 않지만 내 문제의 핵심 요소는 병렬로 실행되는 두 시나리오 사이에서 데이터를 전달하는 것이었기 때문에 기술적으로는 원본의 절반 만 응답해도 미래에 다른 사람들에게 약간의 가치가있을 수 있기를 바랍니다. 문제.

다음 설치는 두 번째 시나리오는 시나리오 1에서 생성했던 데이터를 확인하기 위해 지연 시작 어디에 두 가지 시나리오가 함께 실행 방법의 일반적인 생각을 보여줍니다

setUp(
    scenario1.inject(constantUsersPerSecond(0.5) during (10 minutes)), 
    scenario2.inject(nothingFor(3 minutes), constantUsersPerSecond(0.1) during (7 minutes)) 
).protocols(httpProtocol) 

간단하게 두 가지 시나리오를 것 병합 가능했지만 두 시나리오가 긴 실행 단계 체인으로 구성되어 있고 서로 다른 주입으로 병렬로 실행해야하기 때문에 두 시나리오를 두 개의 별도 클래스로 유지했습니다. 프로필. 시나리오 2에서 필요한 데이터는 시나리오 1에서 생성되어 해당 세션에 저장됩니다.

하나의 시나리오에서 다른 시나리오로 데이터를 전달하기 위해 단일 LinkedBlockingDeque 항목을 보유하는 것 외에는 전혀 수행하지 않은 개체를 만들었습니다. 로드가 많은 테스트를 실행할 때 병행 문제를 피할 수 있도록이 콜렉션 유형을 정했다.

val saveData = exec{ session => 
    DataDequeHolder.DataDeque.offerLast(session("data").as[String]) 
    session 
} 

val scenario1 = scenario("Scenario 1") 
.exec(
    step1, 
    step2, 
    ..... 
    stepX, 
    saveData 
) 

그리고 마지막으로 시나리오 두 내가 데이터를 검색 한 사용자 정의 공급 장치를 만든 : 시나리오 중 하나에서

import java.util.concurrent.LinkedBlockingDeque 

object DequeHolder { 
    val DataDeque = new LinkedBlockingDeque[String]() 
} 

, 나는 다음 시나리오를 각 성공적인 루프의 끝에서이 양단 큐에 값을 저장 이것은 지금까지 입증했다

class DataFeeder extends Feeder[String] { 
    override def hasNext: Boolean = DataDequeHolder.DataDeque.size() > 0 
    override def next(): Map[String, String] = Map("data" -> DataDequeHolder.DataDeque.takeFirst()) 
} 

val scenario2 = scenario("Scenario 2") 
.feed(new DataFeeder()) 
.exec(
    step1, 
    step2, 
    ..... 
    stepX, 
) 

실행하지 않고 두 가지 시나리오를 통해 데이터를 전달하는 신뢰할 수있는 방법으로 : 당신이 다른 공급 장치가하는 것처럼 LinkBlockingDeque에서,이 장치를 사용 동시성 문제에 빠지기. 그러나 백엔드 시스템이 매우 과중한 작업을 수행하고 수천 명의 동시 사용자를 대상으로 실행되지 않기 때문에 높은로드로이 작업을 실행하지 않았다는 사실에 주목할 가치가 있습니다. 나는 이것이 높은 부하 상태에서 시스템과 어떻게 잘 작동하는지 모른다.

+0

LinkedBlockingDeque를 사용하면 쓰기보다 빨리 읽는 것이 문제가됩니다 (사용 사례에 따라 다름). 그렇다면 ConcurrentLinkedQueue를 사용하여 사용자가 데이터를 가져올 때까지 루프 및 일시 중지하도록 할 수 있습니다. –

+0

사실, 우리는 당신이 반복하고 멈추더라도 당신이 쓸 수있는 것보다 더 빨리 일관되게 읽고 있다면, 기다리는 사용자는 계속 누적 될 것이기 때문에 그것이 반드시 전적으로 신뢰할만한 것은 아니라고 생각합니다. 확실히 usecases에 많이 의존합니다. 그렇다면 ConcurrentLinkedQueue가 우리에게 더 좋은 옵션인지 살펴볼 것입니다. 팁을 주셔서 감사합니다! –

+1

큰 차이점은 Gatling 스레드를 차단하지 않으며 교착 상태에 빠질 위험이 없다는 것입니다. 사용자는 모든 스레드가 읽기를 시도하는 사용자에 의해 차단되어 대기열에 쓸 수 없습니다. –