The following notes were written by Andy Powell, UKOLN, and posted to the list-elib Mailbase list.
The areas of server performance and security came up briefly at the technical day last Friday but were not discussed in too much detail. Here are some (very) hastily knocked together notes based in part on things said at the meeting together with some pointers for further information. (My experience is with UNIX (SunOS/Solaris mainly). Perhaps others can chip in with issues relating to other O/S's or with other issues relating to UNIX - I'm sure I've missed things.
The 'uptime' command will give a general indication of the load on your server. Graphic tools ('perfmeter' on Suns for example) may give a better feel for how your server is doing but to really see what is happening use a combination of 'ps', to show the processes that are running, 'vmstat' to give a summary of memory usage, etc (and if necessary 'netstat' and 'iostat').
The 'top' command is a very useful curses based tool for giving a detailed picture of what a machine is doing. (See the URL ftp://ftp.groupsys.com/pub/top or check HENSA UNIX).
Consider your memory requirements - as a rule of thumb, the more memory your server has the better :-)
Consider the location of your server on the network. Is the route between your server and your users across a busy local area network? As the traffic on the server increases discuss your service with Computer Centre or whoever looks after the network.
Consider the layout and usage of disks on your server. Share traffic across disks and disk controllers where possible.
If you really want to find out about tuning UNIX then 'System Performance Tuning' by Mike Loukides is a good read. It covers both BSD and SysV based systems. (See the URL http://www.ora.com/catalog/spt/noframes.html)
Check your O/S and/or hardware supplier documentation. If you (or your
site) has a maintenance contract with Sun for example, then there will be
various performance related white papers available from the SunSolve site
I expect.
Don't dismiss solutions based on Linux running on PCs out of hand :-).
Someone at the meeting raised a question mark about the performance of NT on DEC Alpha's. OSF UNIX peforms better???
Web server software. For UNIX, Apache seems to be the server of choice. (See the URL http://sunsite.doc.ic.ac.uk/packages/apache/). Older server software, the CERN httpd version 3.0 for example, tends to perform badly so avoid it. A detailed comparison of Web servers is available at the URL http://www.webcompare.com/.
CGI scripting. If you're using Perl then see the guidelines towards the back of the 'Programming Perl' book on efficiency. (See the URL http://www.ora.com/catalog/pperl2/noframes.html). Remember that there is an overhead associated with each process that the machine has to start up so don't start sub-shells unnecessarily. For security reasons be careful with the arguments that you pass to any sub-shells that you do start.
Some servers offer alternative APIs which may well give better performance (I think) - this may be worth investigating.
Don't run daemons from 'inetd' - run them stand-alone. (If you do run things from 'inetd' under older version of SunOS then watch out for a bug on busy servers which causes inetd to hang every so often).
Very busy servers, particularly those serving requests to end-users across slow networks, may hit problems with the 'TCP listen backlog' under some O/S's. (Basically this is a limitation that the O/S places on the number of connections in the TCP startup phase at any one time). See http://egate.lut.ac.uk/caching/other/#listen1 from Martin Hamilton's caching pages for more details.
Don't forget dependencies that your service may have on external servers - DNS for example???
And on the security front...
There are plenty of resources on the Web. For information specifically related to security and the Web see:
For general UNIX security see http://www.ukerna.ac.uk/newsfiles/janinfo/cert/cert.html. Consider running COPS or SATAN? See http://www.ukerna.ac.uk/newsfiles/janinfo/cert/JANET-CERT/SATAN.html
Don't forget to archive your system so that you can recover should things go wrong.
Every JANET site should have one or two JANET CERT reps who will receive timely notification of security alerts - probably someone in the Computer Centre. It may be worth finding out who your rep is. (For example, at the meeting on Friday someone mentioned that there had been an unusual number of probes to the Web server the night before from a UKERNA address. This was the JANET CERT probing all UK AC Web servers to see if they suffered from a well known hole in one of the CGI scripts commonly supplied with certain Web server software - the probes had previously been announced to the JANET CERT site contacts).
Hope this is useful...
Andy Powell --
UK Office for Library and Information Networking
University of Bath, Bath, BA2 7AY, UK Voice: +44 1225 323933
http://homes.ukoln.ac.uk/~lisap/ Fax: +44 1225 826838