Define a multithreaded threshold when building a SaaS application

Back to Cloud Island: All SaaS users are happy. Because they can get a quick response. Because the only control that these users have is control over access to the application, they do not worry about whether the application has a multithreaded routine or how many cores in the cloud are used to accelerate multithreading in parallel. The problem application was successfully migrated from the internal multithreaded COBOL legacy system.

Of course, one day, the speed of SaaS applications slows down and slows down, until the user can't stand it. It was only then that they discovered:

Only one core is operating normally, and the rest of the core has failed.

SaaS subscriptions are limited to two cores, not all four cores.

The SaaS application has recently been upgraded with multithreaded bugs.

Failover plan failed.

At the same time, the island's functional department, the development team of people gather together to think about a variety of solutions, want the system to resume operation.

This article helps you explore multithreaded performance issues, which I've experienced the first time I've encountered multiple threads (in short, I'll try to minimize the damage). This article then looks at whether the multithreaded control model cloud users are accessing in Java and COBOL, and creates a concise built-in multithreaded support. This article is intended to show you what positive measures the vendor can take to stop the damage, solve the problem, recover the system, and notify the customer.

Multithreading performance

The more cores in the CPU, the better the multithreading will be when executing the program code directives, but the core quantity used is not the only factor that determines the execution of multithreaded software. Another factor is that it is not always feasible to use an algorithm to complete thread parallelism for a task or process. The computation of some threads has been parallelization in the previous step, and may result in a sequential outcome.

Given that applications are dispersed in modules, each is designed to perform a task or process. In a module, you can have 6 almost parallel single threads. We assume that:

A is a thread 1,b is a thread 2,c is a thread 3,d is a thread 4,e is a thread 5,f is a thread 6

Results r0, R1, and R2 are computed as a combined parallel thread of two separate threads, as follows:

R0 = a + b
R1 = C + D
R2 = e + F

However, adding all three parallel thread results (R0,R1 and R2) results in a sequential result g this is not a new parallel thread, as follows:

g = r0 + r1 + R2

All contiguous parts must wait for a prepared signal to be sent by the parallel thread in the previous step. The more contiguous parts of a program, the less benefit you get from multi-core.

Other factors that affect multithreading algorithms include:

The THREAD compiler option limit for COBOL.

The limitations of the Java multithreaded programming.

Decompose defects in tightly coupled COBOL programs into loosely coupled SaaS applications.

Cloud user control.

Multithreading threshold is missing.

The first time I encountered a thread

More than 10 years ago, when I first used host COBOL, I considered interacting with a non-COBOL language. I had a discussion with a professor and planned to take this as a topic on the subject of COBOL interface performance. I shared the idea of parallel threads getting subroutines in program code.

To figure out what would affect performance, I experimented with the Mini Cobol/fortran interface based on the "Fortran Interface for CODASYL Database Task Group specification" (see Resources). Fortran was the popular language at the time. At that time, COBOL did not have the THREAD option as we do now. Compared to the large processors we see today, the maximum capacity of the processors was also very small.

In my experiment, I found that some COBOL data types do not have a Fortran equivalent. When the application no longer needs data or the object exists on disk, I invoke the subroutine to bypass the memory limit as needed, and then release the data or objects when they are not needed and automatically delete the data that is no longer needed.

Each subroutine performs one or more tasks. In some tasks, several threads are evaluated as a parallel thread (R0 = thread A + thread B). All contiguous parts are waiting for the parallel thread in the previous step to send a ready signal. Waiting is short.

If we had a cloud at the time, we could develop a SaaS application using a multithreaded routine on a platform that is running on a multi-core virtual machine, a service (PaaS).