Hi!
We are a hardware store(similiar to usa's home depot) here in venezuela.
We have 14 stores that moves a very heavy load of traffic.
Many of our retails runs in a home brew POS that uses mysql. Then sales
are uploaded to a bigger in-store server and then move to the central
office. The prices, promotions and offers are constantly replicated to
the stores, so imagine it has a lot of traffic.
For performance, the single most important factor seems to be a fast io
hardware and a good properly configured os, instead of more ram and
processor.
We currently compile all our software, and run our db in linux boxes(you
didn't specify a os)
We compile our db using
"-O3 -march=i686 -mcpu=i686 -funroll-loops -fomit-frame-pointer
-fno-rtti -fno-exceptions -felide-constructors"
Our servers are compiled static, it seems to be a little faster than a
shared server, but your millage may actually vary.
Our kernels are also compiled in a similar fashion. We specially add
similar cflags and cxxflags to the above, modifing the Makefile in the
kernel tree. Also a pair of tricks are also used inside the kernel, we
rise the SEMNI value from 128 to 512 and the LOG_BUF_LEN from 16384 to
65536 in each server.
We also tweak a few runtime kernel variables, chages in the sysctl.conf:
added:
# Improve file system performance
vm.bdflush = 100 1200 128 512 500 6000 500 0 0
# Improve virtual memory performance
vm.buffermem = 80 10 60
# Improve and better control swapping into the system
vm.freepages = 383 766 1149
# Increase swap bandwidth system performance
vm.kswapd = 1024 32 16
# Increase number of pages kernel reads in at once
vm.page-cluster = 16
# Improve files memory mapping and generic caching
vm.pagecache = 8 25 85
# Improve number of page tables keeps in a per-processor cache
vm.pagetable_cache = 35 60
# Improve the number of open files
fs.file-max = 16384
We also compile and use our own ssl binaries, we do not use the distros
version.
One thing to note is the fact that poor code will produce poor
performance so check your code and your sql. We do not run mysql and
apache on the same server, you shoudn't do that neither.
What is your set up? OS? Are you using any speed-up technology like zend
optimizer with your server? PHP can be a big resource eater, so find out
where is the bottle neck, if it is mysql, calculate well your load and
create a propper configuration in your my.cnf, add a good balance of
harware and a few of the tweaks mentioned above. May i recommend Gehard
Mourani's book on "Securing and Optimizing RH Linux"? it is available at
tldp.org, for free under "guides", it's intended for RH only, but it
also works on suse and debian(and any other) if you know the way around
your distro.
Hope this works, regards
On Thu, 2004-01-15 at 13:23, mysql wrote:
> Hi Gurus,
> I'm currently building an application which is expected
> to take very high loads. What the app does is essence is
> to 'log' and incoming entry into MySQL, do something then updates
> the 'log' entry.
>
> To test MySQL in handling high load, I used siege
> on another server to send 1000 HTTP GET requests to my php
> script which then does as described above. The results that I'm
> getting is not encouraging as it seems that MySQL is not able
> to capture the 1000 entries.
>
> I've tried doing some of the tuning from the net but so
> far to no avail. Does anyone know what is the critical tuning method
> needed for MySQL to be able to handle loads like this?
>
> Thank you very much!
--
|...........................................................|
|____ _____ ____ _ |Victor Medina M |
|\ \ \| ____| _ \ / \ |Linux - Java - MySQL |
| \ \ \ _| | |_) / _ \ |Dpto. Sistemas - Ferreteria EPA |
| / / / |___| __/ ___ \ |[EMAIL PROTECTED] |
|/_/_/|_____|_| /_/ \_\|ext. 325 |
| |geek by nature - linux by choice |
|...........................................................|
...................................................................
"Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots.
So far, the Universe is winning."
Rich Cook
