The first thing companies ask themselves when they need to implement a new piece of software or feature, is about hardware requirements: “What are the specifications?” or even “Will our servers support it?”. Another common scenario where the same doubts arise is when an IT manager starts receiving complaints regarding poor system performance from its users. At this point, the following question arises: “Is our environment (server) still suitable for the current demand?”<\/p>\n\n\n\n
These are very common questions, but due to several involved factors, finding answers is not always as simple as it may seem. To address this, it’s essential to understand Hardware Sizing, or Sizing in short.<\/p>\n\n\n\n
But first, let’s grasp the concept of Software Sizing.<\/p>\n\n\n\n
To discuss Hardware Sizing, we need to have a brief understanding of Software Sizing, which involves quantifying the size of software (or a part of it). In this case, we’re talking about determining the size of the software, not the effort invested in developing it. Some ways to measure software size include analyzing Function Points (FPs) or Lines Of Code (LOC). The size and complexity of a software piece are crucial factors for hardware sizing.<\/p>\n\n\n\n
And what is Hardware Sizing?<\/p>\n\n\n\n
A simple definition of Hardware Sizing is: “An approximation of the hardware resources needed to support a software implementation”.<\/p>\n\n\n\n
Like any theoretical model, it’s important to note that this is an approximation of reality but often yields much more reliable results than a mere “guess.” More importantly, supporting the software implementation means it should not only run but run with adequate performance and meet user needs.<\/p>\n\n\n\n
Depending on the project or software to be implemented, various approaches can be taken when it comes to Hardware Sizing, always involving the analysis of factors such as:<\/p>\n\n\n\n
\u25cf Routine complexity: Predicting which complex routines will require more processing power (software sizing is highly applicable here).<\/p>\n\n\n\n
\u25cf User count: The more users (especially concurrent users), the greater the processing and storage volume required.<\/p>\n\n\n\n
\u25cf Transaction volume: Knowing the complexity of function “X,” how many times will it be used?<\/p>\n\n\n\n
\u25cf Storage: How much space will each initiated transaction occupy (referring to database and hard disk storage)?<\/p>\n\n\n\n
\u25cf Growth: What is the expected software usage growth for the next few years? What is a safe margin to have hardware reserves to extend the investment’s lifespan?<\/p>\n\n\n\n
These factors can be estimated from scratch or based on historical data from an existing environment. Combining these factors allows establishing a calculation basis that determines the appropriate hardware, justifying and safeguarding any hardware investment.<\/p>\n\n\n\n
As mentioned, each software project may require a different approach to sizing. Hardware and software providers have various articles on the correct sizing of their products (Dell servers,<\/p>\n\n\n\n
SQL Server and Oracle databases, for example). Market methodologies for this type of measurement also exist, such as TPC-C (Transaction Processing Performance Council \u2013 Benchmark C), which we commonly use in our clients’ sizing projects.<\/p>\n\n\n\n
Methodologies for Hardware Sizing<\/p>\n\n\n\n
The TPC-C methodology is a benchmark for online transaction processing (OLTP). In this benchmark, combinations of servers and databases from various manufacturers are measured, determining the transaction index they support. In essence, with the methodology and the factors mentioned above, it’s possible to calculate an approximate necessary index. This calculation can then be compared with already measured equipment to determine the required hardware or assess the suitability of current hardware.<\/p>\n\n\n\n
Another method of Hardware Sizing is to conduct synthetic tests with the application through load testing. Automated testing tools (such as JMeter) can be used to determine how many simultaneous transactions a simple processor can support. If the simple station supports 100 simultaneous transactions but it’s determined that there will be 1000 concurrent users, it’s known that to handle 1000 simultaneous transactions, equipment with 10 times the computing power of the simple processor is needed. This type of study (pre-implementation when the application has not yet been deployed) can greatly assist in accurate hardware sizing.<\/p>\n\n\n\n
In conclusion<\/p>\n\n\n\n