What server would be required to handle 10000 peak time line item
transactions (2 line items transmitted) from POS terminals scattered
throughout the country?

What would be the requirements for the server & what would be the
price?

---

Request for Question Clarification by webadept-ga on 09 Jun 2002 10:48 PDT

legolas-ga's comments below have very good points to them. Before I
could give you a more defined answer I would need to know if the POS
system is talking to its own server software package or are you going
to use a real database for the information gathering.
 
DB2, Informix, MSQL, or even MySQL are examples of "real" databases.
These engines would easily take in the information at the speeds far
greater than 10,000 actions a minute, and a reasonable well built
server. The operating system is a factor as is the method of
communications, as legolas-ga has given the example of Internet IP
connection. Secure connections could slow you down a bit, but that
won't be a mater of the server, most likely it would be the clients
slowing things up.
 
However, if the POS system you are running has its own "sever
database" system, then I would need to know what the POS system is,
and I'll warn you now that its difficult to get around proprietary
system requirements. If you have purchased a proprietary package, you
may be stuck with their system requirements, even though other routes
might be faster or less expensive.
 
Let us know as soon as you can if you are able to pick the database
engine or if you are using proprietary system software.
 
webadept-ga 

---

Clarification of Question by mhugo-ga on 10 Jun 2002 07:54 PDT

Basically a magnetic stripe card would be swiped at a Verifone Tranz
330 POS terminal capturing the account number. The supplier would then
enter in a numeric code corresponding to a item number. The account
number and item code would then be transmitted to a central server. We
anticipate roughly 10,000 simultaneous peak transactions could occur
from these POS terminals that are scattered throughout the country.
The POS terminals will leverage their internal modem and communicate
via wireline to the central server (not via internet).
 
With this established, I would be quite confident that we could pick
our own database engine. Does this impact your previous comments? Will
the server need a number of modem ports for this to work? 

I assume you mean that you are to be adding 10,000 rows to a database
within one hour? or one minute? or, even one second?

Also, the operating system used will be a large part of the answer. If
you were using, say, Linux to power the backroom server and using
MySQL with InnoDB (to handle transactional processing), I would fully
anticipate any off-the-shelf, half-way decent PC to be able to handle
the load. You'd probably want about 512MB of RAM, a reasonably fast
harddrive, and a fast CPU. The most challenging part of this whole
setup is the infrastructure you are using and connecting all the POS's
to the main server (which I would recommend doing via. the internet
and some sort of secured channel).

Total cost of the server should be in the order of $2500 or so (you do
NOT need the super-duper servers that some companies will try to sell
you). You DO need a tape-backup though. Using Linux will save you on
the cost of software. Setup/install will be the most expensive part
most likely, but, you'd need to find a techie in your area that is
experienced in POS and Linux.

I can't possibly fathom how you would have 10,000 transactions at the
same time by using dial-up modems. If that's the case, you would need
on the order of 20,000+ telephone lines, 20,000+ modems, cooling
systems that would cost a fortune, and setup/maintenance costs which
should make your profits look a tad negative.

I can't give you the 'answer' yet, since google hasn't finished the
last step of my application process, however, I can tell you that to
handle 10,000 transactions at the same time is fairly easy to
accomplish with a server with about 1Gig of RAM, I'd do a RAID array
of striped SCSI drives (for speed and reliability) (10kRPM min), and
Linux running as the OS (using PostgreSQL or MySQL (w/InnoDB)). The
system is the easy part. The hard part in this is, fairly obviously, a
completely innapropriate plan to connect the clients to the server.

Sorry..