navigation (1)Skip section navigation (2)
FreeBSD Man Pages
- ERR_set_mark(3), ERR_pop_to_mark(3)
- set marks and pop errors until mark
- Blocks until all processes in the communicator have reached this routine
- Allegro 5 API
- Allegro 5 API
- read from a stream until a boundary string is matched
- block until a grace period and all callbacks have been dispatched
- defer function execution until a grace period
- block until a grace period has been detected
- glFinish(3), "glFinish(3)
- block until all GL execution is complete
- 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
- run until a D-Bus name appears on the session bus
- tclmidi command to block until playing or recording a MIDI song finishes
- Blocks the calling process until all processes in a group have called it
- 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
- Locks the local X display until a password is entered. xlock#(1) "" "xlock(1)"
- Lock X display until password supplied, leaving windows visible
- Defer Inflating Of Columns Until They Are Used
- extract data from Macintosh BinHex files ALPHA WARNING: this code is currently in its Alpha release. Things may change drastically until the interface is hammered out: if you have suggestions or objections, please speak up now!
- Try running a block of code until success with a configurable retry logic
- read lines until all blocks are closed
- Defer computing parts of output until the end of the request
- n .SH "SYNOPSIS <condition name=""usable_encryption_certificate_already_exists"" class=""OpenXPKI::Server::Workflow::Condition::CheckExistingCertificate""> <param name=""cert_profile"" value=""I18N_OPENXPKI_PROFILE_USER_FSE""/> <!-- minimum number of days until expiration --> <param name=""min_remaining_validity"" value=""90""/> </condition>" .SH "SYNOPSIS <condition name=``usable_encryption_certificate_already_exists'' class=``OpenXPKI::Server::Workflow::Condition::CheckExistingCertificate''> <param name=``cert_profile'' value=``I18N_OPENXPKI_PROFILE_USER_FSE''/> <!-- minimum number of days until expiration --> <param name=``min_remaining_validity'' value=``90''/> </condition>" Header "SYNOPSIS <condition name=usable_encryption_certificate_already_exists class=OpenXPKI::Server::Workflow::Condition::CheckExistingCertificate> <param name=cert_profile value=I18N_OPENXPKI_PROFILE_USER_FSE/> <!-- minimum number of days until expiration --> <param name=min_remaining_validity value=90/> </condition>"
- Role for delaying method calls until idle time
- Don't use operators like "not", "!~", and "le" within "until" and "unless"
- Write "while(! $condition)" instead of "until($condition)"
- Delay the loading of .psgi until the first run
- defer generation of subroutines until they are first called
- postpone load of modules until a function is used
- buffer data from stdin until EOF, then write to stdout
- break small images up into separate files