[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [mv] upgrade server spec
On Mon, 27 Sep 1999 macky@staktrading.com wrote:
> ****** message to minivend-users from macky@staktrading.com ******
>
> Hi All,
>
> I have a server running minivend which has started stalling during busy times. Using the top command, perl will be
> occupying 100% cpu and sit there for a few mins. All other requests queue up behind it until they time out.
>
> I am running 2x PIII 550 cpu,s , 384mb sdram, ultra wide scsi on an asus motherboard.
Lucky you!
We have a P-II 400 with 256MB of RAM that was quite sluggish until I
realized that Linux was not recognizing most of the memory. It thought
that it had only 64MB of memory, not 256. When I added the appropriate
entries to LILO, the server immediately started responding much more
quickly. MV and MySQL use a lot of memory when they are running under
load.
Make sure your OS is finding all the memory. Under Linux, dmesg will tell
you what the OS thought it found when it booted up.
> I would like to be able to use another system of similar spec to load balance or cluster to share the load over several
> servers. Has this been done with minivend??
It is not hard if you take over the order number generation system. That
is really the only problem with having separate machines.
Even round-robin DNS tricks should enable you to scale. The main issue
you will run into is with the databases you are using. If you cannot come
up with a scheme to maintain database integrity and coherence while
scaling to multiple machines, you will have a problem.
You have to look at issues like:
1) can more than one machine use the same order number? If so, will it
break anything to have duplicate order numbers (it usually does!).
2) What is the maintenance cost of maintaining separate databases vs. a
single (but potentially performance-bound) one? All my products are in a
shared database on a separate server. If you have a lot of products,
keeping the old system of flat files and maintaining them can get ugly as
you scale to more and more machines.
3) what is an acceptable level of reliability and availability? Clusters
often do better than single machines. SMPs give you a lot of CPU, but if
even one CPU has a problem, you lose the entire machine.
In a past life as an e-Commerce consultant with IBM, I usually went for a
pile of boxes and then carefully tuned the data placement so that the most
heavily used data was cached locally. With tools like MySQL, that usually
means writing a lot of your own code, but it isn't that hard.
Certain data must be coherent across all servers. Order numbers are
usually one of the most important things to keep track of. If two
machines generate an order with the same order number, you are probably
going to have some problems.
One of the nicest feature of a pile of PCs is that if one dies, the others
just keep going.
Segregating your data into various levels of stability helps. If you
don't change your products or prices very often, you could probably
manually replicate the products database onto each server. If you run a
big store (or stores) where products change often, you should make sure
that you fully understand all the details of how you can replicate the
data and how you can maintain coherency.
> If not, would it be worth upgrading to twin xeon chips or using an alpha instead?
I prefer lots of cheap machines to one expensive one.
Best,
Kyle
