Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
12 Cards in this Set
- Front
- Back
|
What defines performance? - Optimising the environment server (ie: hardware, software system, internal and external caching, load balancing) - Optimising the web server software (tuning) - Optimising network bandwidth ('connection throughput) - Other factors |
Two kinds of servers: Development server and Production server Development server: - Configuration designed for maximal information on error - May be sharing other non-web applications - Often has perimeter security only - Usually not visible to the outside world - 'Reasonable' backup strategies - Server and support application has full diagnostic logging - PRIMARILY SET UP TO MAXIMISE DIAGNOSTICS - may be switchable between dev and prod configs - may have typical website content instead of all of it SIDE NOTE: A development server is a type of server that is designed to facilitate the development and testing of programs, websites, software or applications for software programmers. It provides a run-time environment, as well as all hardware/software utilities that are essential to program debugging and development. |
|
|
Production server: - Configuration is speed optimised for your kind of web content - Usually a dedicated machine or load-balancer cluster - Strong security throughout - Well connected to the network - Frequent and offsite backups with fallbacks - Server and support applications optimised and with 'sufficient' logging. Some logging is always important for security and audit. - PRIMARILY OPTIMISED TO MINIMISE OVERALL LATENCY - Specifically set up to optimise 'qualities' - May include additional support structures such as caches SIDE NOTE: A production server is a type of server that is used to deploy and host live websites or Web applications. It hosts websites and Web applications that have undergone extensive development and testing before they are validated as production ready. A production server may also be referred to as a live server. |
Support applications: - Database support - internal, such as as in a content management (CMS) - external (including a separate DB server) MySQL, Oracle, MS SQL server - Enterprise support - interpreted languages integrated into server itself - also other apps -Support structures - output cache, proxy cache - load balancer |
|
|
Defining web server performance: - The web is slow. It is imp to decrease the latency between when they user requests a document and when they receive it - Identifiable bottlenecks : * network latency between the client and the server * poor server performance related to the server hardware * slow response from the web server bc of heavy load * slow response from the web server bc of server side overloads In terms of measuring performance, we will look at web traffic, benchmarking, log analysis, monitoring OS |
Defining performance: burstiness of web traffic - it is not uncommon for web traffic to experience increases of up to ten-fold over average - In configuring a web server it should be considered whether we will be able to handle average load, and the peak load |
|
|
Defining performance: server qualities: - we want to test the following qualities of a server: * scalability - how performance scaled with volume * stability - how long between failure to deliver * Speed - in terms of response time Web servers should have the quality of: * Correctness (how closely the web server software conforms to the HTTP standard) * Reliability (how long the web server will urn without human intervention) |
slide 13 pic |
|
|
Measuring performance: benchmarking - benchmarking involves running test software on a system and measuring how it performs, against the same test software on different systems, and with different networking parameters - To test a web server - test requests are sent by web client software to stimulate web traffic on the server - To evaluate performance we measure values like: requests per second, throughput, latency, concurrency, error response |
|
|
|
Method for run benchmarks tests: 1. Configure the web server 2. Run the benchmark test 3. Record the results 4. Change variables based in analysis of results 5. Repeat steps 1 to 4 We want to benchmark: * A typical server (this includes hardware such as amount of RAM, software such as the software architecture) * A typical environment - benchmark a wide range of files served by the web server (these may include static files, dynamic scripts that read or write to a database. The benchmark test: - the general aim of any benchmark test is to provide the desired quality values in as 'real' a situation as possible. - In our case its to provide values of requests per second, response time, error rate. - IMPORTANT CONSTRAINT: the response time to a client must not be more than a reasonable value, usually between 5 and 10 seconds. - After this time the user will give up on the page , or hit the refresh button which adds load to the web server Benchmarking issues: - A web server has a default performance set up (for eg: a certain number of start up child processes). It may be necessary to restart the server after each test - Most OS have main memory caching - it may be necessary to flush this cache after each test |
To run a benchmark test for requests per second do the following: 1. Run the initial test to determine what values of RPS will saturate the web server. This becomes the upper bound value for the test 2. Select an appropriate and realistic lower bound for the RPS value 3. Select an appropriate step value 4. Run the test at each step value for RPS and record the request per seconds, the response time, the error state 5. Graph these values |
|
|
Logging: - integral part of running a web server - logs should be kept for all errors that occur during the operation of a web server - good approach : log all messages during development, and critical one during operation. - These are called error logs - Logs should be kept for every request that is made to the web server - called request logs or access logs - these are useful - they can be analysed to gauge the effectiveness of the web site design, to determine where users are located, t assess the performance of the web server |
|
|
|
Using log information: - valuable tool for investigating performance - apache server log is written out in the common log format - The log is stored in the logs directory in the following format |
|
Calculating throughput: |
|
|
|
Tuning tips: Eliminating DNS lookup: HostNameLookUps - turn it off, as it adds latency to every request bc it requires a DNS lookup to complete before the request is finished |
Avoid per directory configuration AllowOverride - Wherever in your web server document root you allow overrides (using .htacess file) the web server will attempt to open .htaccess for each filename component - Given this instance DocumentRoot /www/htdocs AllowOverride all then when a request is made for URI /index.html, Apache will attempt to open /.htaccess, www/ .htaccess, and /www/htdocs/ .htaccess Similar solutions as for Options FollowSymLinks - For highest performance use AllowOverride None everywhere in your file system |
|
|
Reduce control content negotiation: -if you don't need negotiation turn it off, especially if you want to squeeze performance from a box. For eg: DirectoryIndex index - Use complete list of options DirectoryIndex index.cgi index.php index.html where you list the most common choice first |
Optimise logging: - Logging uses significant amounts of the disk and the CPU, therefore it should be minimised where possible - Web servers maintain 2 logs - errors logs and access logs - Instead of turning of the access log, a better solution is to log to a separate disk - Error log should always be maintained so log this to a separate disk as well, or a separate server using the system log daemon - Amount of info that error log logs can be minimised |
|
|
- Consider tuning PHP scripts, these things can be memory hogs - Tune tables in a database, optimise queries |
done |
