Scalability
Scalability refers to the ability to add more workload. In general, additional workload is caused by the increase in customers. Scalability is a complex problem, and the author has discussed in depth in the articles that have been available [1]. In the future, this discussion will be simplified, and the author will discuss scalability in the context of the problem encountered in the next three years. The author will further simplify this discussion, and only consider the cost of running business and database layers, although similar results may be similarly analyzed.
Let us assume that Moneybroker's business model requires that 10 payments per day this year, next year is 1 million, and later is 10 million. What are the related costs of the J2EE / UNIX solution or .NET platform / Windows solution?
In order to judge MonryBroker's machine size required in the next three years, we need a standard for transaction performance. The industrial standard benchmark for transaction-proactive throughput is specified by the so-called Transaction Performance Council (TPC) association, which is called TPC-C based. TPC members include companies in Sun, IBM, Oracle, BEA, Microsoft and Most of the sales intermediate / database layers.
The TPC-C benchmark is evaluated a system that the highest workload of the system is available. The measurement unit defined by the TPC-C reference is TPMC, which represents the number of transactions per minute (Transactions Per Minute). In addition to this reference, the transaction processing of transactions in the distributed order input system environment will not be discussed. The reference description can be obtained in the TPC website [2].
In MoneyBroker, the number of TPC-C has made its platform a user choice, and it is facing two issues.
The first question is that the transaction processing specified in TPC-C is completely different from MoneyBroker transaction processing. This requires MoneyBroker to completely review TPC-C specification, guess how much TPC-C transactions in workload can be comparable to a MoneyBroker. We assume that MoneyBroker calculates a transaction with 10 TPC-C, thereby having a large number of surplet for handling errors.
The second question is that there is no J2EE developer has publicly published its own TPC-C number. This makes MoneyBroker difficult to calculate the throughput implemented by J2EE, namely AIX. Interestingly, although all important J2EE developers have submitted TPC-C benchmarks, no developers have submitted TPC-C based on their J2EE technology.
For example, there are 6 benchmarks for IBM's WebSphere technology (including one brand of IBM companies in J2EE technology). However, if someone studys the result of WebSphere, it will find that there is no reference code to use Java, and there is no reference to use any WebSphere J2EE performance. In fact, these benchmarks use IBM's traditional ENCINA transaction monitoring technology, which is included in total WebSphere brand. Similarly, BEA has used its traditional Tuxedo technology to run their benchmark, and Tuxedo technology is part of its WebLogic brand, but is not included in J2EE.
Since we don't have J2EE performance numbers, we must estimate the relevant performance of J2EE implementation. Since J2EE is based on a traditional transaction monitoring program (the developer has already determined the baseline), it will still increase the Java programming language. The overhead of Java virtual machines and EJB (middle layers) is a relatively reasonable speculation that J2EE will be able to complete 50% of the non-J2EE system (such as Tuxedo performance). Therefore, the author will use a 50% adjustment factor to estimate the throughput of J2EE.
Below we use TPC-C information to analyze MoneyBroker behavior. MoneyBroker is trying to determine which system is purchased. Obviously, MoneyBroker wants to spend as few funds as possible, but it is still convinced that the throughput required for customer usage reaches peaks, and it is also aware of its system to expand to meet the needs of the next three years. This year, MoneyBroker needs to handle 100,000 transactions every day. This is equivalent to handling 70 transactions per minute, with a peak to handle 700 pens per minute. Since a MoneyBroker transaction handle is equal to 10 TPMC transactions, this is about 7000 when the workload reaches peaks. Next year, this number increased by 10 times to 70000 TPMC, and the number increased by 10 times, reaching 700,000 TPMC.
So, in the next three years, what expenditures (including hardware and software) are required (including hardware and software)? Let us start from the possible spending of J2EE / UNIX, so the author will consider which one of the best represents J2EE / UNIX systems in IBM's AIX operating system, WebSphere, and Oracle 8i systems. For this configuration, there are 6 benchmarks. Press TPMC from the lowest to the highest order, and J2EE adjustment (previously discussed), the results are as follows:
the company
system
TPMC
Total system cost
BULL
Escala T610 C / S
16,785
$ 1,980,179
IBM
RS / 6000 Enterprise Server F80
16,785
$ 2,026,681
BULL
Escala EPC810 C / S
33,375
$ 3,037,499
IBM
RS / 6000 Enterprise Server M80
33, 375
$ 3,097,055
BULL
Escala EPC2450
110,403
$ 9,563,263
IBM
IBM EServer PSeries 680 Model 7017-S85
110,403
$ 9,560,594
If we consider some representative .NET platform systems (there are too many systems, it is impossible to consider, but the numbers are very consistent), the results are as follows:
the company
system
TPMC
Total system cost
Dell
PowerEdge 4400
16,263
$ 273,487
Compaq
ProLiant ML-570-6 / 700-3P
20,207
$ 201,717
Dell
PowerEdge 6400
30,231
$ 334,626
IBM
Netfinity 7600 C / S
32,377
$ 443,463
Compaq
ProLiant 8500-X550-64P
161,720
$ 3,534,272
Compaq
ProLiant 8500-x700-64p
179,658
$ 3,546,582
Compaq
ProLiant 8500-X550-96P
229,914
$ 5,305,571
Compaq
ProLiant 8500-x700-96p
262,244
$ 5,305,571
Compaq
ProLiant 8500-700-192P
505, 303
$ 10,003,826
You can understand the choices facing MoneyBroker. This year it only needs a 7000 TPMC system. In the UNIX market, this will cost approximately $ 2 million, while in the .NET platform market, it takes $ 2.73 million. MONEYBROKER will need a 70000 TPMC system, which takes $ 9.5 million in the J2EE / UNIX market, while in the .NET platform market, it takes $ 3.5 million. In the late years, MoneyBroker needs a 700,000 TPMC system. Among these systems, there is no one to be 700,000 TPMC, but the nearest system until there is a 10 million USET platform system. If a comparable J2EE / UNIX machine exists, it is estimated that it takes $ 47.5 million. Obviously, if the cost of the system is an important consideration, compared with J2EE, the .NET platform has a great advantage. It is expected that the same function is to be obtained, and the cost of spend is 5 to 10 times the cost of the .NET platform. If a working unit spends 10 cents on the .NET platform, the same work unit may need to spend 50 cents to $ 1 in J2EE / UNIX.
The author needs to point out again, although these .NET platform benchmarks are the actual baseline of the actual machine, there is no truly existence in these J2EE benchmarks. These benchmarks are extrapolation benchmarks, and the actual system does not necessarily get these results. Before the J2EE developer issued their reference number, we must remember that there is no J2EE platform that has been demonstrated to handle these high workloads without cost.
Architecture support
When creating a large e-commerce solution, no one wants to start from the beginning. Instead, I hope to create a solution based on the e-commerce architecture that has been fully defined. Using such a architecture can greatly reduce the development cost, it may be lowered by at least 10 times.
The .NET platform includes a so-called Commerce Server e-commerce architecture. At this point, there is no architecture that is neither a proportional developer in J2EE space. Using J2EE, you should assume that you need to create your new e-commerce solution from your head. Paul Harmon seems to agree to this evaluation and say:
In addition, no matter which [J2EE] developer is selected, if you expect a perfect e-commerce application that allows you to implement it quickly, you will have a frustrated experience. [3]
If you use MS Commerce Server as your e-commerce base, it is most likely that there is a great impact on the cost of the development system. Commerce Server is especially suitable for retail business. Such an e-commerce system should carefully consider this technology.
. .com is obtained).
[2] Please refer to the specification or formal benchmark result of www.tpc.org.
[3] Building a Large, Integrated, Multi-EJB Server System, Paul Harmon the http://www.cutter.com/consortium/consultants/phbio.html Architecture / e-Business E-Mail Advisory, Cutter Consortium August 23, 2000
