thread priority

[cji_work]

Hi folks,
I am doing some loadtesting on my company's web application now by
runing a perl script, and I have a problem need to solve.

Here are the general description of that script:
The script reads a data file to get a list of username & password; For
each username & password it reads, it creates a new thread to pass the
username & password to a function; This function will access a web page
, use the passing parameters to log-in, and do some shopping-work, and
finnally it will "check-out" from that web-page.

That web application is written in perl/cgi-bin and the backend DB is
mysql. Both are running on linux, and the script is also running on
liunx. All the users are different and for that web server, they are
eqully-weighted.

It works perfectly if I have about 200 users. But if I raise the number
of users, I will see further more failure as they received "500
time-out".

So my Question is if I could set some priority for the first 200
threads to guarantee thses threads are good to pass ?


thanks for the tips,


CJ

 

[xhoster]

Hi folks,
I am doing some loadtesting on my company's web application now by
runing a perl script, and I have a problem need to solve. ....

It works perfectly if I have about 200 users. But if I raise the number
of users, I will see further more failure as they received "500
time-out".

I would guess you are getting these errors because the server is not
responding fast enough, and that is has nothing to do with the threads on
the client end, no? How about making the client more patient?

So my Question is if I could set some priority for the first 200
threads to guarantee thses threads are good to pass ?

So, you created a module to load test your company's web site. It
demonstrates that your company's web site fails (it becomes slow to respond
at high loads). It seems to me that the load-testing script has done its
job. Why do it think it needs to be changed? Fix the web-server, not the
web-server testing script.

Xho

 

[cji_work]

I agree with both of you, but maybe I should have it specified at the
first time.
When I was running the test, I need to see the performance of both the
Apache and the backend DB. Right now when I increase the number of
users, I will see the load on the Apache is growing up. But I guess as
too many users that causes extra requests have been turn down, the load
on the DB is actually going down.

So the really problem for me is how I can increase the load on web
server as well as on the DB?

I was thinking if somehow I can set the high priority of the first 200
threads (if it is possible), these transactions are guaranteed. For the
rest, it may just depends on if there is extra rooms.


-CJ

 

[xhoster]

I agree with both of you, but maybe I should have it specified at the
first time.
When I was running the test, I need to see the performance of both the
Apache and the backend DB. Right now when I increase the number of
users, I will see the load on the Apache is growing up. But I guess as
too many users that causes extra requests have been turn down, the load
on the DB is actually going down.

How are measuring these two loads?

So the really problem for me is how I can increase the load on web
server as well as on the DB?

My first thought is "why would I want to?" If Apache is the rate limiting
step, then optimizing the DB performance isn't going to get you anywhere.
And whatever you do learn about DB performance *now* may no longer be
applicable once Apache is optimized, as then the patterns of usage will
likely be differnt.

But anyway, my second thought is that I'd try to make another test script
which incorporates enough of the code from the web-app into it that it can
bypass apache and go straight to the database. That way I could verify
whether, once apache is removed as the bottleneck, the database could keep
up.

If that proved hard to do because the database-specific code is too mingled
in with the cgi-specific parts of the code, I would try to deploy a copy of
the web-app to the test server. Then the load testing script would split
up the cgi work to two different servers, but all of the DB work would
converge back to one server, allowing you to increase the load on the DB
beyond what you could otherwise do.

I was thinking if somehow I can set the high priority of the first 200
threads (if it is possible), these transactions are guaranteed. For the
rest, it may just depends on if there is extra rooms.

I don't know how you can do that, and I also don't see what it would get
you if you could. You already know that there is no extra room there.


Xho