Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
ERR_set_mark(3), ERR_pop_to_mark(3)
set marks and pop errors until mark
MPI_Barrier(3)
Blocks until all processes in the communicator have reached this routine
al_wait_cond_until(3)
Allegro 5 API
al_wait_for_event_until(3)
Allegro 5 API
boundary_fopen(3)
read from a stream until a boundary string is matched
ck_epoch_barrier(3)
block until a grace period and all callbacks have been dispatched
ck_epoch_call(3)
defer function execution until a grace period
ck_epoch_synchronize(3)
block until a grace period has been detected
glFinish(3), "glFinish(3)
block until all GL execution is complete
greed(6)
eat a game field until you run out of moves
gyes(1), yes(1)
output a string repeatedly until killed
layingsiege(7), Siege(7)
An HTTP/HTTPS stress tester was designed orignally as a internet usage simulator. In short, its role was to simulate the activity of many simultaneous users hitting a HTTP server. We were debugging some java code and during that process we arrived at a point where the code could withstand an acceptable number of users hitting a single URL but it could not withstand the seemingly random activity that characterizes many users hitting many URLs on a webserver. In order to debug the problem in a lab environment, I developed a program that simply read a bunch of URLs ( we used images, scripts, static html, jsps, etc. ) into memory and hit them randomly. The result was a success. We were able to break the code in the lab, an occurance which ultimately allowed us to fix it and put it into production. As the developers code improved, siege improved until we ultimately had good java code and a pretty decent regression tool. It was helpful for us, I hope it is helpful to you. In order to feel comfortable putting code into production, you need a way to measure its performance and to determine its threshold for failure. If you break your database pool at 250 simultaneous users and you average less then one-hundred simultaneous users and the code performs favorably, you can feel good about putting it into production. At the same time, if you should monitor trends in your site's activity and prepare for the moment when your traffic starts to near your threshold for failure. As a webdeveloper or websystems administrator you have little to no control over your user group. They can visit your site anytime day or night. Your domain name could resemble a popular site, yoohoo.com? And when was the last time marketing informed you about an approaching advertising blitz? You must be prepared for anything. That is why stress and performance testing is so important. I would not recommend putting anything into production until you have a good feel for how it will perform under duress
libowfat_io_waituntil(3), io_waituntil(3)
wait for events
mc-wait-for-name(1)
run until a D-Bus name appears on the session bus
midiwait(n)
tclmidi command to block until playing or recording a MIDI song finishes
pvm_barrier(3)
Blocks the calling process until all processes in a group have called it
samechflags(1)
change file flags samechmod change file modes samechown change file owner and group samecp copies the first file of a pair of duplicate files samedelay delays line output until the files are no longer in use sameln links duplicate files together samemv moves the first file of a pair of duplicate files samerm remove the last of a pair of duplicate files
xlock(1)
Locks the local X display until a password is entered. xlock#(1) "" "xlock(1)"
xtrlock(1)
Lock X display until password supplied, leaving windows visible
home | help