Speed can refer to:
- The number of web pages per second that
you can display without causing the server to slow down
excessively.
- The amount of time that the user waits for content
to appear.
To fix speed type #1 you should use mod_perl where needed.
Usually, based on an analysis of your traffic flow, you
will need performance improvements for only some of your
CGIs.
To fix speed type #2 there are many tricks, many of which
do not seem to be widely used. Here are a few:
- Optimize the size of image files, for example by
reducing the number of colors in a gif file or the
amount of compression in a jpeg.
- Include the size
tags for the image files so that the browser can do the
layout before loading the image.
- Set $|=1 so that your script sends output as soon as
it is ready.
- Your CGI should call print two or three times. This is
because print is *very* slow. People tend to have many more print
statements in a CGI, and they are often the cause of
performance problems.
The way to avoid calling print too often is to buffer up
a bunch of output into a string and print that. I have
seen print cause more performance problems than perl objects.
- Your first CGI print statement should generate enough
content in the browser to get the reader started.
The reader won't really care if the rest of the
load takes a few seconds longer.
- Don't use layouts with tables nested to many levels
inside of tables, at least in the first print statement.
This takes a long time for the browser to render. Most
browsers won't render anything at all for a table until
the close of the outermost table.
- Don't use a lot of little graphic buttons. Try to
keep graphics down to three images, up to seven is
reasonable. Any more should be somewhere in your web
page where waiting for them won't annoy the reader.
- Disk reads should not be a problem for loading modules.
Any file that is often-used will get cached by any decent
operating system. Loading large perl modules can be slow for
other reasons, but this is fixed by using mod_perl.
To make your code friendly to porting to mod_perl,
you should:
- use strict;
- Don't declare any variables outside of subroutines
in the modules that you write.
- Leave time in the schedule for lots of testing and
fixing things in your mod_perl program. Mod_perl is
worthwhile as a performance advantage, but it requires
more work to do correctly. It is much less forgiving
of sloppy coding practices than CGI.
- Use a computer than can hold lots of RAM. You will
be able to make speed/memory tradeoffs in mod_perl, until
you run out of sockets for more RAM. In my last project
I was able to justify lots of RAM because it was
the cheapest way to increase performance.
- Make sure your web server is Apache running
on Linux or some sort of Unix.
There are many, many more tricks for making a fast
dynamic web site. It is an interesting topic and I
hope that you build speedy ones!
It should work perfectly the first time! - toma
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.