You ran the load test, the numbers looked good, and the release went out. Then production slowed down anyway. If that sounds familiar, the problem usually is not the test itself. It is the gap between the test and the real world. Here are the five gaps I see most often, and how to close them. 1. The test environment is smaller than production This is the most common one. Your staging environment has two app servers while production has eight, or the test database holds a fraction of the real data. Smaller environments respond differently under load , and the results do not scale in a straight line. Fix: make the test environment as close to production as you can, and where you cannot, write down the differences. A result with known gaps is useful. A result that pretends the gaps do not exist is not. 2. The test data is too clean Test data is usually tidy. The same hundred users, the same product IDs, the same search terms, and everything already in cache. Production data is messy. User...
One common dilemma for performance testers is deciding whether to run Vusers as processes or threads. To make an informed choice, it’s important to first understand the distinction between a process and a thread. 1. Process : A process is an instance of a computer program being executed, with its own dedicated virtual address space. Multiple processes can run simultaneously, but each process operates independently and does not share its memory address space with others. Example : If you open Notepad, you’ll see a process named notepad.exe in the task manager under the Processes tab. Opening another instance of Notepad will create a second notepad.exe process. Each process has its own memory space, and communication between processes happens through mechanisms like inter-process communication (IPC). 2. Thread : A thread exists within a process and shares the process’s memory address space with other threads. Multiple threads within the same process can access shared memory, and when o...