Date: Mon, 2 Jul 2001 18:51:21 +0300 From: teo@gecadsoftware.com To: <freebsd-questions@freebsd.org> Subject: Re: Is it possible to get more power from a FreeBSD system running Apache/MySQL/PHP ? Message-ID: <20010702185121.D11890@gecadsoftware.com> In-Reply-To: <PHEBIOJOBJJLIIJCOINKCEJODMAA.nadir@attractive.com>; from nadir@attractive.com on Mon, Jul 02, 2001 at 03:13:24PM %2B0200 References: <PHEBIOJOBJJLIIJCOINKCEJODMAA.nadir@attractive.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Nadir!
On Mon, 02 Jul 2001, Nadir@Attractive wrote:
> I have few questions:
>
> 1. Anyone knows if Apache 2.0 can handle more visitors than Apache 1.3.x
> in the current configuration that we have?
Apache 2.0 is suppose to be multithreaded, and the preliminary benchmarks
I saw were promising, but Apache 1.3 is tough enough.
> 2. Can I optimize the FreeBSD system that we currently have even further
> to get more power of the server?
I have not much experience w/ FreeBSD (newcomer to it) but I can share some
of my experience
> 3. The MAXUSERS configuration parameter is set to 256, and this is the
> kernel's setting now. If I set it to be larger, say 1024, will it yield
> better results?
that is one of the points.
you'll have to recompile the kernel for that, and don't worry, you'll
get an improved version, cuz you'll keep in only what you need.
then take a look at sysctl. You have several paramenters that can be
adjusted, namely number of open files per process, size of network buffers
etc. You'll have to tune it for your configuration (e.g. for network
performance you have several tool in FreeBSD for that, check the packages)
> 4. Personally I think that this server can do MUCH better, and maybe the
> server's configuration is inaccurate, or insufficient. Any suggestions
> where to start?
1. Tune Apache
2. Tune MySQL
3. Tune PHP
1. Apache
- Check Apacheweek.com. I think there I saw once some recomandations
e.g.
HostnameLookups On - do you really need to have the hostnames in the logs?
remember that this mean a DNS query for each client. Turn it off, and
have the logs analized offline, if you want the FQDNs of the visitors
ExtendedStatus On - another resource consuming directive. Turn it off
on production servers.
FollowSymLinks - try to avoid it; if you don't have any symlinks, taek it
out.
Another tricks for high trafic would be:
Logging - what do we actually need logged? There are a lot of pages out there
designed with Dreamwaver or other tools that produce thousands of mages,
and a complete page has a correspondent in lots of entries in the logs,
99.99% of them regarding images.
I bet a check on request is faster than a disk write, so
SetEnvIf Request_URI "\.(gif|jpe?g)$" dont_log=1
CustomLog /var/log/www/www.ravantivirus.com-access_log common env=!dont_log
Headers - there aren't much, but they are something
http.conf - ServerTokens ProductOnly
php.ini - expose_php = off
Images delivery -
I've heard about a nice trick to speed up images delivery.
You set up a separate sever for images, e.g.
for www.foobar.com, have images.foobar.com, which only delivers images
this should be a separate server, namely a trimmed down Apache,
statically link which eventually to use MapFile to map most requested
files (e.g. the one from menus etc.) or thttpd, a faster server for
statical content.
Note that if you set a cookie it will be sent along even in the requests
for images, so if you have lots of big and yummy cookies, they will
eat bandwidth on each of that miriad of requests for the fancy menus your
designer(s) made.
Having a separate domain for images cuts them out, cause they won't be
sent anylonger (for an obvious reason, i.e. different "domain")
2. PHP
- Compile PHP statically into Apache (--with-apache, not --with-apxs)
so you'll save php loading time.
- Your process grew that big because the memory allocated by PHP isn't
return to the system, so the httpd process grows in time. You may try
to use --with-memory-limit when configuring php to impose a memory limit
or better:
- when doing large queries, don't fetch them into arrays, but just
use mysql_fetch_array() as you need and don't forget
mysql_free_result() at the end.
- have a code review and profiling, to see where it spends more time
and which scripts eat up lots of memory. Generally, it's because of db
queries.
1+2. Compressed output
- can be done either with mod_gzip.c or with a Rewrite trick or at PHP
level; long story and interesting :)
on short, for clients that say "Accept-Encoding: gzip" in request headers
you can send compressed content.
PHP as of 4.0.5 (IIRC) has a working ob_gzhanlder, and you can do it at
PHP level.
3. MySQL
- I don't have much experience w/ MySQL tunning parameters, so not much to
say on it;
- under support-files in MySQL distribution you have some samples of
my.cnf for different needs. Take a look, it might be that my-large.cnf
or my-huge.cnf can suit your needs (just copy it to /etc/my.cnf)
- other stuff I remember is that MySQL performs better on "reads", so try
to avoid inserts or use LOW_PRIORITY. Optimize your most common tables
often (use isamchk), you'll "feel" the difference. Pay special atention to
indexes (read "optimization tricks" from mySQL manual - spoiler: have an
index for any field appearing in where clauses)
4. Network
Probably other FreeBSD wizards have tips on tunning network throughput
hope it helps.
-- teodor
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010702185121.D11890>