Re: Curl-loader results vary from time to time

[alo s. <asi...@ic...>]

Hi Robert,

Thanks for your reply.

We have two test clients and the environment in both machines are same 
except the client 2 has 8 Gig RAM and client 1 has 4 Gig RAM. The test 
script works fine with test client 1 and it gives the following error 
with test client 2.

setup_curl_handle_appl - error: post_data is NULL.
setup_curl_handle_init - error: setup_curl_handle_appl () failed .
setup_url error: setup_curl_handle_init - failed
setup_curl_handle_appl - error: post_data is NULL.
setup_curl_handle_init - error: setup_curl_handle_appl () failed .
setup_url error: setup_curl_handle_init - failed
setup_curl_handle_appl - error: post_data is NULL.
setup_curl_handle_init - error: setup_curl_handle_appl () failed .
setup_url error: setup_curl_handle_init - failed
setup_curl_handle_appl - error: post_data is NULL.
setup_curl_handle_init - error: setup_curl_handle_appl () failed .


This is my test script:
--------------------
########### GENERAL SECTION ################################
BATCH_NAME=NOV10_SA_login
CLIENTS_NUM_MAX = 10000
CLIENTS_NUM_START=50
CLIENTS_RAMPUP_INC=50
INTERFACE=eth0   
NETMASK=24 
IP_ADDR_MIN=xx.x.x.xxx
IP_ADDR_MAX=xx.x.x.xxx
CYCLES_NUM= -1
URLS_NUM=2

########### URL SECTION ##################################

# GET-part
URL=http://xx.x.x.xxx/main
URL_SHORT_NAME="Login-GET"
#URL_DONT_CYCLE = 1
REQUEST_TYPE=GET
TIMER_URL_COMPLETION = 0 # In msec. Now it is enforced by cancelling url 
fetch on timeout
TIMER_AFTER_URL_SLEEP =0

# POST-part
URL=http://xx.x.x.xxx/login
#URL_USE_CURRENT= 1
URL_SHORT_NAME="Login-POST"
#URL_DONT_CYCLE = 1
USERNAME=test
PASSWORD=test
REQUEST_TYPE=POST
FORM_USAGE_TYPE= SINGLE_USER
FORM_STRING= USERNAME=%s&PASSWORD=%s # Means the same credentials for 
all clients/users
TIMER_URL_COMPLETION = 0    # In msec. When positive, Now it is enforced 
by cancelling url fetch on timeout
TIMER_AFTER_URL_SLEEP =0


These are my client machines:
-----------------------------

Test client 1:
Operating System:    CentOS release 5.2 (Final)
CPU:    Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz
Ram:    4 Gigabytes DDR2

Test client 2:
Operating System:    CentOS release 5.2 (Final)
CPU:    Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz
Ram:    8 Gigabytes DDR2


I have also followed the recommendations given in the following links,

section 7.2 in http://curl-loader.sourceforge.net/doc/faq.html
http://curl-loader.sourceforge.net/high-load-hw/index.html


If you have any clue as why we get this type of error in only one 
client, please advice us and Greatly appreciate your help.

Thanks,
Alo






Robert Iakobashvili wrote:
> Hi Alo,
>
> On Tue, Nov 4, 2008 at 4:18 PM, alo sinnathamby 
> <asi...@ic... <mailto:asi...@ic...>> wrote:
>
>     Hi Robert,
>
>     Because of these different results, i am not able to determine the
>     correct run time for any given number of requests. Our objective is to
>     determine the load capability and run time for any given number of
>     requests, say for an example 20000, 50000, 70000, 100000 requests.
>
>     Please render your valuable advice and Greatly appreciate your help.
>
>      
>
>  
> The suggestion is always to measure such things not at a ramp-up
> time (75 seems to be the max for your machine), but at a steady state.
>  
> Y may wish to look at the steady run-time slot and to adjust
> the number of cycles accordingly.
> Besides that, you can see CAPS number, which is at a steady stage
> the number of cycles, that all your virtual clients are doing each second.
>  
> Besides that, the following conversation may be of your interest:
> http://sourceforge.net/mailarchive/forum.php?thread_name=BAY131-W4271C5395CD9FFBBC04BF8D9C80%40phx.gbl&forum_name=curl-loader-devel 
> <http://sourceforge.net/mailarchive/forum.php?thread_name=BAY131-W4271C5395CD9FFBBC04BF8D9C80%40phx.gbl&forum_name=curl-loader-devel>
>  
> Sincerely,
> Robert