How to make jmeter do log replay based on time stamps present in access log lines

Question

I recently started load testing my webapp.

I used apache access log sampler. I followed this tutorial.

https://jmeter.apache.org/usermanual/jmeter_accesslog_sampler_step_by_step.pdf

I am able to make it work. But now the problem i replayed all the get requests in less than 10 mins.

I want jmeter to run the get requests based on the time stamp at which the get request is posted.

I am not able to find any such configuration online.

I can write script to curl the get request at that particular timestamp. But i want to use jmeter.

Is it possible.

EDIT

I created a sample csv file with below lines:

0,/myAPP/home
5000,/myAPP/home
5000,/myAPP/home

First i created a thread group as shown in image:

Here i selected loop count forever. If not selected only first line in csv file is running.rest of the lines are not running.

Now i added csv data set config as shown in image:

Now i added constant timer as shown in image:

Now i added HTTP request as shown in image: I added view results tree listener and hit the play button.

When i see the sample start in view result tree for each of the samples, the delay is not according to the delay present in csv file. What am i doing wrong.

EDIT2 I made the constant timer as child of the HTTP request. Please find the timings of the requests in the below screen shot. Do you see anything wrong .

EDIT3

I followed bean shell timre approach and it worked fine when the delay is greater than previous response time. But it didnt work properly when previous response time is greater than delay.

I modified the csv file as below ( reduced delay to 100 msec)

0,/myAPP/home
100,/myAPP/home
100,/myAPP/home

I deleted constant timer and added below bean shell timer.

This is the results table:

These are the log lines:

Answer 1

The out of the box access log sampler won't work for what you're trying to do.

You have two options:

1 - Do all of the processing work outside of Jmeter and create a CSV file with two fields: URL and Delay and then use the CSV data set config.

Youtube JMeter CSV tutorial:
http://www.youtube.com/watch?v=aEJNc3TW-g8

2 - Do the processing within JMeter. If you're a Java developer you can write a beanshell script to read the file and parse out the URL and timestamp and calculate the delay.

Here is an example:
How to read a string from .csv file and split it?

EDIT 1
Using the data from your question and screenshot everything looks like it's working fine. A couple of things about JMeter delays (using timers).
- JMeter will add a delay AFTER the request (not before it)
- Jmeter will start the delay AFTER the server is done responding.

In your case (I'm rounding to the nearest second):
Initial request at 12:59:53
+ Request took 24.5 seconds
+ 0 second delay
= next request should be at 13:00:18 which is indeed when the next request happened.

Second request at 13:00:18
+ Request took 1.8 seconds
+ 5 second delay
= next request should be at 13:00:25 which is indeed when the next request happened.

I think what you want is that the next request will NOT factor in the response time. Offhand, you'd need to create a delay of ${delay} - ${responseTime}

EDIT 2
In order to create a delay that will factor in the response time you need to use the beanshell timer and not the constant timer.

Here is the code (put this in the script section of the beanshell timer):

rtime = Integer.parseInt(String.valueOf(prev.getTime())); // on first run will raise warning
delay = Integer.parseInt(vars.get("delay"));    

Integer sleep = delay - rtime;

log.info( "Sleep for " + sleep.toString() + " milli-seconds" );
return sleep;  

EDIT 3
What if response_time > desired_delay?
If the sleep calculation is less than zero, nothing will break. It will just sleep for zero milliseconds.

With just one thread there is no way to make an additional request if the existing request hasn't completed. Technically it should be possible to have a different thread start making requests when one thread isn't enough to keep the exact delays, but this would require intra-thread communication which can get very messy very quickly and requires beanshell scripting.