2

I am writing an application for a client that says he will have 20 orders / day and that will increase to 200 within 2 years.

He wants to have his own local server for that and wants me to suggest him a PC specification that may supply his needs for N years say 7~10.

The database will be mariadb.

What data do I need to look at to evaluate that?

My initial idea is to generate data to cover for 300 daily records for a year and then calculate based on that.

I will be writing an app that writes dummy data to the db using N connections to emulate concurrent insert, reads, etc, not sure if this is a good way to do this either. What are your advice?

But I am not sure how I would calculate memory, cpu and disk io into the equation only the disk space.

How can I calculate the memory cpu and disk io for this purpose to know say what sort of HD/SSD/M2 or cpu and memory that it would require?

2
  • Get enough disk to handle twice your data.
  • If you can afford enough RAM for the data, I/O is unlikely to be a problem.
  • If the data is much bigger than RAM, then the performance of the disk may be a critical factor. (Today's SSDs make this rarely an issue.)
  • If the queries are CPU-bound, then focus on indexing (especially "composite" indexes) and reformulation of the queries. I rarely find a CPU-bound that can't be helped that way.
  • Most systems are happy with 1 or 2 cores; it is rare to need more than 16.
  • 100 queries per second is a Rule of Thumb. Below that, virtually any server will suffice for virtually any application. Above 100, you need to do more planning. Switching from HDD to SDD and/or better indexes are the usual quick fixes. (Many production systems happily run at over 1000 qps.)

Please dig deeper into your app. So far, it seems to come in at much below 100 qps, so any server will probably be fine.

2

300 orders per day for 10 years is about a million rows. Assuming 10KB of data per sale (probably will be a lot less), that's 10GB of disk space. As for how to check your assumptions about disk usage and throughout, you will need to write some test scripts to create those million sales and measure latency for each transaction with an increasing number of concurrent connections.

A Raspberry Pi would be adequate for a volume of data that small.

My advice is to start with an Oracle free tier VM and see if it is responsive enough for you. If it isn't, get a VM from Scaleway for €3/month. Or, if your client is really welded to the idea that he must have the server on site, get a Raspberry Pi.

Whatever solution you go with, make sure you have reliable, frequent backups.

In terms of how to work out the resources, work out how many transactions an order creates. If it is 1 transaction, and you have 300 orders per day, that is 300 transactions per day. 300 transactions per second would be relatively low throughput.

What you really need to test is response time when somebody is using the system. With such low throughput, your requirements will be dictated by response latency, not throughput for 300 transactions per day.

  • That's interesting I was planning on testing it on a raspberry pi4 and yes the client is fixed on wanting a physical server, he also have a NAS for backups. But I am still curious to know how I would define I have enough memory/cpu/io to handle the task and also projections of what is a good HD size to last that long – Guapo Jun 20 '20 at 21:37
  • 1
    300 orders per day for 10 years is about a million rows. Assuming 10KB of data per sale (probably will be a lot less), that's 10GB of disk space. As for how to check your assumptions about disk usage and throughout, you will need to write some test scripts to create those million sales and measure latency for each transaction with an increasing number of concurrent connections. – Gordan Bobic Jun 20 '20 at 22:45
  • And if 10GB runs slow, then you are probably missing an index. Do not jump to the conclusion that size determines speed. – Rick James Jun 21 '20 at 17:14
1

A simple standard computer Core i5 / Ryzen 5, so that you can administer it in comfort. Standard PC components guarantee that replacement and repair is quite easy manageable, by almost everyone. More important is a good strategy for backup and restore/ disaster recovery.

A VM on a fast computer makes only fun to work with, when there is enough power for the VM else every administration task takes forever. Backup and restore is easier because VMs are files, and can be copied easily. But there you also need a disaster recovery solution and a backup strategy for the VMs server. Everything fails in 7 to 10 years.

If the company already works with a server and VMs/docker the decision should go to the VM, when there is a administrator with knowledge in backup and restore.

Having servers with the customer always must include a service contract, to check if the hardware doesn't show signs of age or problems. Like I said, everything fails.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.