Tests using Memory Managers optimized for best performance ...
1) RTL (standard in Delphi 7)
2) FastMM 4.56 (optimized)
3) BucketMem_ASM (optimized)
4) Nexus DB MM V3
OS used (on all PCs):
Windows XP Pro
Client PCs used (13):
3 x Pentium III at 650 MHz with 384 MB RAM
10 x Pentium III at 667 MHz with 256 MB RAM
Server PC used (1):
1 x Dual-core AMD X2 at 4,4 GHz with 2 GB RAM
- CPU: AMD Athlon64 X2 4400+ "box" 2x1024KB L2 Cache
(200 MHz FSB, S.939)
- RAM: 2048 MB DDR PC3200/400 - CL 2,5 Corsair Twinx XMS
- Board: MSI K8N SLI-F, S.939 NVIDIA Nforce4 SLI, ATX
- Graphics: MSI NX6600LE TD256E NVIDIA 6600LE, 256MB, PCIe
- Hard-drives: 2 x Samsung HD080HJ P80, 80GB 7200, 8MB Cache
All PCs were connected to one 24-port 100 MBit full-duplex switch.
All 13 Client PCs were running the RTC SDK AppClient Demo with the Multiple
Connection Flood test, using 300 connections in Multithreaded mode (pool
size set to 16 Threads) with automatic compression and encryption to
constantly flood the Server with remote function calls (total 3.900
connections).
Server was running the RTC SDK AppServer Demo in multithreaded mode (using
16 Threads) with automatic encryption and compression.
Here is the function used to check Memory usage
(written by Pierre le Riche, the author of FastMM4):
----------------
uses Windows;
function Get_AddressSpaceUsed: Cardinal;
var
LMemoryStatus: TMemoryStatus;
begin
{Set the structure size}
LMemoryStatus.dwLength := SizeOf(LMemoryStatus);
{Get the memory status}
GlobalMemoryStatus(LMemoryStatus);
{The result is the total address space less the free address space}
Result := (LMemoryStatus.dwTotalVirtual - LMemoryStatus.dwAvailVirtual)
shr 10;
end;
---------------
This function uses only a Windows API call and is Memory Manager
independent.
Log files were created by AppServer Demo while executing the tests.
Successful request was logged after the Server has sent a complete response
to the client, log file written for every 5.000 requests.
All Data is in CSV format (using ";" as value separator) and can be opened
in MS Excel to generate Graphs.
Here are the most interesting sections from Test Results,
complete Test Results are available from the Attachements group.
--------------
1) FastMM 4.56 - optimized
2005-12-24 01:30:43; Time (sec); Memory (MB); Requests; Avg req/sec; Curr
req/sec
2005-12-24 01:30:46; 2; 122,348; 5000; 2037,49; 2037,49
2005-12-24 01:30:48; 4; 124,848; 10000; 2461,236; 3107,52
2005-12-24 01:30:49; 5; 127,348; 15000; 2601,457; 2935,995
2005-12-24 01:30:51; 7; 129,848; 20000; 2688,895; 2990,431
2005-12-24 01:30:53; 9; 132,348; 25000; 2725,687; 2883,506
2005-12-24 01:30:54; 10; 134,848; 30000; 2746,75; 2857,143
2005-12-24 01:30:56; 12; 137,348; 35000; 2761,995; 2857,143
2005-12-24 01:30:58; 14; 138,598; 40000; 2770,467; 2831,257
2005-12-24 01:31:00; 16; 141,098; 45000; 2771,789; 2782,415
2005-12-24 01:31:01; 18; 143,598; 50000; 2770,544; 2759,382
2005-12-24 01:31:03; 19; 146,098; 55000; 2765,07; 2711,497
2005-12-24 01:31:05; 21; 147,348; 60000; 2756,593; 2666,667
2005-12-24 01:31:07; 23; 149,848; 65000; 2745,86; 2623,295
2005-12-24 01:31:09; 25; 152,348; 70000; 2736,62; 2621,919
2005-12-24 01:31:11; 27; 154,848; 75000; 2721,039; 2520,161
2005-12-24 01:31:13; 29; 156,098; 80000; 2720,441; 2711,497
2005-12-24 01:31:15; 31; 158,598; 85000; 2705,111; 2481,39
2005-12-24 01:31:17; 33; 161,098; 90000; 2690,261; 2460,63
2005-12-24 01:31:19; 35; 162,348; 95000; 2678,395; 2481,39
2005-12-24 01:31:21; 37; 164,848; 100000; 2664,393; 2423,655
<SNIP> After running for 30 minutes ...
2005-12-24 02:00:45; 1801; 209,848; 3830000; 2126,079; 2091,175
2005-12-24 02:00:47; 1803; 209,848; 3835000; 2126,052; 2105,263
2005-12-24 02:00:50; 1806; 209,848; 3840000; 2126,135; 2192,021
2005-12-24 02:00:52; 1808; 209,848; 3845000; 2126,218; 2192,021
2005-12-24 02:00:54; 1810; 209,848; 3850000; 2126,191; 2105,263
2005-12-24 02:00:57; 1813; 209,848; 3855000; 2126,217; 2146,844
2005-12-24 02:00:59; 1815; 209,848; 3860000; 2126,227; 2134,016
2005-12-24 02:01:01; 1817; 209,848; 3865000; 2126,255; 2147,766
2005-12-24 02:01:03; 1820; 209,848; 3870000; 2126,319; 2176,752
2005-12-24 02:01:06; 1822; 209,848; 3875000; 2126,382; 2176,752
2005-12-24 02:01:08; 1824; 209,848; 3880000; 2126,355; 2105,263
2005-12-24 02:01:11; 1827; 209,848; 3885000; 2126,363; 2133,106
2005-12-24 02:01:13; 1829; 209,848; 3890000; 2126,372; 2133,106
2005-12-24 02:01:15; 1831; 209,848; 3895000; 2126,327; 2092,05
2005-12-24 02:01:18; 1834; 209,848; 3900000; 2126,426; 2206,531
<SNIP> After running for 60 minutes ...
2005-12-24 02:30:44; 3601; 209,848; 7635000; 2120,244; 2119,542
2005-12-24 02:30:47; 3603; 209,848; 7640000; 2120,216; 2077,275
2005-12-24 02:30:49; 3605; 209,848; 7645000; 2120,225; 2134,016
2005-12-24 02:30:52; 3608; 209,848; 7650000; 2120,242; 2146,844
2005-12-24 02:30:54; 3610; 209,848; 7655000; 2120,205; 2065,262
2005-12-24 02:30:56; 3612; 209,848; 7660000; 2120,186; 2091,175
2005-12-24 02:30:59; 3615; 209,848; 7665000; 2120,231; 2192,021
2005-12-24 02:31:01; 3617; 209,848; 7670000; 2120,166; 2025,111
2005-12-24 02:31:04; 3620; 209,848; 7675000; 2120,129; 2064,41
2005-12-24 02:31:06; 3622; 209,848; 7680000; 2120,073; 2038,32
2005-12-24 02:31:08; 3624; 209,848; 7685000; 2120,036; 2064,41
2005-12-24 02:31:11; 3627; 209,848; 7690000; 2120,1; 2222,222
2005-12-24 02:31:13; 3629; 209,848; 7695000; 2120,026; 2012,882
2005-12-24 02:31:16; 3632; 209,848; 7700000; 2119,998; 2077,275
2005-12-24 02:31:18; 3634; 209,848; 7705000; 2119,943; 2038,32
<SNIP> Closing the Test ...
2005-12-24 02:44:19; 4415; 209,848; 9335000; 2114,345; 2146,844
2005-12-24 02:44:21; 4417; 209,848; 9340000; 2114,273; 1988,072
2005-12-24 02:44:23; 4419; 209,848; 9345000; 2114,313; 2192,021
2005-12-24 02:44:26; 4422; 209,848; 9350000; 2114,271; 2037,49
2005-12-24 02:44:28; 4424; 209,848; 9355000; 2114,236; 2051,703
2005-12-24 02:44:31; 4427; 209,848; 9360000; 2114,209; 2064,41
2005-12-24 02:44:33; 4429; 209,848; 9365000; 2114,182; 2064,41
2005-12-24 02:44:35; 4432; 209,848; 9370000; 2114,147; 2051,703
2005-12-24 02:44:38; 4434; 209,848; 9375000; 2114,12; 2064,41
2005-12-24 02:44:40; 4436; 209,848; 9380000; 2114,071; 2025,111
2005-12-24 02:44:43; 4439; 209,848; 9385000; 2114,096; 2162,63
2005-12-24 02:44:45; 4441; 209,848; 9390000; 2114,076; 2077,275
2005-12-24 02:44:48; 4444; 209,848; 9395000; 2114,019; 2012,882
2005-12-24 02:44:50; 4446; 209,848; 9400000; 2113,955; 2000
2005-12-24 02:44:50; 4446; 209,848; 9400577; 2113,951; 2053,381
------------
2) BucketMem_ASM - optimized
2005-12-24 00:08:04; Time (sec); Memory (MB); Requests; Avg req/sec; Curr
req/sec
2005-12-24 00:08:07; 2; 148,637; 5000; 1904,762; 1904,762
2005-12-24 00:08:08; 4; 152,191; 10000; 2261,42; 2782,415
2005-12-24 00:08:10; 6; 154,75; 15000; 2430,331; 2857,143
2005-12-24 00:08:12; 8; 157,434; 20000; 2485,398; 2666,667
2005-12-24 00:08:14; 10; 159,992; 25000; 2496,006; 2539,36
2005-12-24 00:08:16; 11; 162,676; 30000; 2532,928; 2735,23
2005-12-24 00:08:18; 13; 165,234; 35000; 2539,544; 2579,979
2005-12-24 00:08:20; 15; 168,789; 40000; 2544,691; 2581,311
2005-12-24 00:08:22; 17; 170,477; 45000; 2535,211; 2461,841
2005-12-24 00:08:24; 19; 173,035; 50000; 2521,687; 2406,16
2005-12-24 00:08:26; 21; 176,59; 55000; 2510,613; 2405,002
2005-12-24 00:08:28; 23; 178,84; 60000; 2503,233; 2424,83
2005-12-24 00:08:30; 25; 180,836; 65000; 2501,443; 2480,159
2005-12-24 00:08:32; 28; 184,082; 70000; 2484,737; 2286,237
2005-12-24 00:08:34; 30; 186,641; 75000; 2470,356; 2285,192
2005-12-24 00:08:36; 32; 189,887; 80000; 2461,538; 2336,449
2005-12-24 00:08:39; 34; 192,445; 85000; 2448,227; 2253,267
2005-12-24 00:08:41; 36; 193,879; 90000; 2444,789; 2387,775
2005-12-24 00:08:43; 39; 197,125; 95000; 2430,04; 2192,021
2005-12-24 00:08:45; 41; 199,121; 100000; 2419,667; 2238,138
<SNIP> After running for 30 minutes ...
2005-12-24 00:38:04; 1800; 251,547; 3635000; 2019,164; 2038,32
2005-12-24 00:38:07; 1802; 251,547; 3640000; 2019,19; 2038,32
2005-12-24 00:38:09; 1805; 251,547; 3645000; 2019,303; 2105,263
2005-12-24 00:38:11; 1807; 251,547; 3650000; 2019,398; 2091,175
2005-12-24 00:38:14; 1810; 251,547; 3655000; 2019,301; 1950,839
2005-12-24 00:38:16; 1812; 251,547; 3660000; 2019,484; 2162,63
2005-12-24 00:38:19; 1814; 251,547; 3665000; 2019,51; 2038,32
2005-12-24 00:38:21; 1817; 251,547; 3670000; 2019,483; 2000
2005-12-24 00:38:24; 1819; 251,547; 3675000; 2019,595; 2105,263
2005-12-24 00:38:26; 1822; 251,547; 3680000; 2019,498; 1950,839
2005-12-24 00:38:29; 1824; 251,547; 3685000; 2019,489; 2012,882
2005-12-24 00:38:31; 1827; 251,547; 3690000; 2019,514; 2038,32
2005-12-24 00:38:34; 1829; 251,547; 3695000; 2019,574; 2064,41
2005-12-24 00:38:36; 1832; 251,547; 3700000; 2019,529; 1987,281
2005-12-24 00:38:39; 1834; 251,547; 3705000; 2019,606; 2078,138
<SNIP> After running for 60 minutes ...
2005-12-24 01:08:04; 3600; 250,984; 7290000; 2024,816; 2012,882
2005-12-24 01:08:07; 3602; 250,984; 7295000; 2024,772; 1963,094
2005-12-24 01:08:09; 3605; 250,984; 7300000; 2024,833; 2118,644
2005-12-24 01:08:12; 3607; 250,984; 7305000; 2024,79; 1963,094
2005-12-24 01:08:14; 3610; 250,984; 7310000; 2024,799; 2038,32
2005-12-24 01:08:17; 3612; 250,984; 7315000; 2024,782; 2000
2005-12-24 01:08:19; 3615; 250,984; 7320000; 2024,826; 2092,05
2005-12-24 01:08:22; 3617; 250,984; 7325000; 2024,817; 2012,072
2005-12-24 01:08:24; 3620; 250,984; 7330000; 2024,792; 1988,072
2005-12-24 01:08:27; 3622; 250,984; 7335000; 2024,74; 1950,839
2005-12-24 01:08:29; 3625; 250,984; 7340000; 2024,696; 1963,094
2005-12-24 01:08:32; 3627; 250,984; 7345000; 2024,671; 1988,072
2005-12-24 01:08:34; 3630; 250,984; 7350000; 2024,724; 2105,263
2005-12-24 01:08:37; 3632; 250,984; 7355000; 2024,68; 1963,094
2005-12-24 01:08:39; 3635; 250,984; 7360000; 2024,62; 1939,488
<SNIP> Closing the Test ...
2005-12-24 01:23:03; 4499; 250,422; 9090000; 2020,372; 2442,599
2005-12-24 01:23:05; 4501; 250,422; 9095000; 2020,529; 2352,941
2005-12-24 01:23:08; 4503; 250,422; 9100000; 2020,503; 1975,504
2005-12-24 01:23:10; 4506; 250,422; 9105000; 2020,457; 1938,736
2005-12-24 01:23:13; 4508; 250,422; 9110000; 2020,46; 2025,932
2005-12-24 01:23:15; 4511; 250,422; 9115000; 2020,413; 1939,488
2005-12-24 01:23:18; 4513; 250,422; 9120000; 2020,409; 2012,072
2005-12-24 01:23:20; 4516; 250,422; 9125000; 2020,405; 2012,882
2005-12-24 01:23:23; 4519; 250,422; 9130000; 2020,351; 1927,525
2005-12-24 01:23:26; 4521; 250,422; 9135000; 2020,298; 1927,525
2005-12-24 01:23:28; 4524; 250,422; 9140000; 2020,273; 1975,504
2005-12-24 01:23:31; 4526; 250,422; 9145000; 2020,276; 2025,111
2005-12-24 01:23:33; 4529; 250,422; 9150000; 2020,216; 1916,443
2005-12-24 01:23:36; 4531; 250,422; 9155000; 2020,163; 1927,525
2005-12-24 01:23:36; 4532; 250,422; 9156082; 2020,158; 1978,062
-------------
3) Nexus DB MM V3
2005-12-24 02:57:00; Time (sec); Memory (MB); Requests; Avg req/sec; Curr
req/sec
2005-12-24 02:57:03; 2; 138,68; 5000; 1818,182; 1818,182
2005-12-24 02:57:05; 4; 143,242; 10000; 2018,978; 2269,632
2005-12-24 02:57:07; 7; 144,117; 15000; 2087,102; 2238,138
2005-12-24 02:57:09; 9; 145,055; 20000; 2122,692; 2237,136
2005-12-24 02:57:12; 11; 147,992; 25000; 2122,061; 2119,542
2005-12-24 02:57:14; 14; 150,492; 30000; 2109,853; 2050,861
2005-12-24 02:57:16; 16; 155,242; 35000; 2101,345; 2051,703
2005-12-24 02:57:19; 19; 157,805; 40000; 2093,254; 2038,32
2005-12-24 02:57:21; 21; 157,617; 45000; 2082,466; 2000
2005-12-24 02:57:24; 24; 160,805; 50000; 2076,584; 2025,111
2005-12-24 02:57:26; 26; 162,492; 55000; 2068,136; 1987,281
2005-12-24 02:57:29; 29; 166,555; 60000; 2060,086; 1975,504
2005-12-24 02:57:31; 31; 167,805; 65000; 2051,314; 1951,6
2005-12-24 02:57:34; 34; 171,742; 70000; 2043,796; 1950,839
2005-12-24 02:57:37; 36; 173,367; 75000; 2034,781; 1916,443
2005-12-24 02:57:39; 39; 174,992; 80000; 2030,148; 1963,094
2005-12-24 02:57:42; 41; 178,68; 85000; 2026,85; 1975,504
2005-12-24 02:57:44; 44; 181,867; 90000; 2021,064; 1927,525
2005-12-24 02:57:47; 47; 183,742; 95000; 2015,915; 1927,525
2005-12-24 02:57:50; 49; 186,117; 100000; 2009,404; 1893,222
<SNIP> After running for 30 minutes ...
2005-12-24 03:27:02; 1802; 219,68; 3075000; 1706,29; 1666,667
2005-12-24 03:27:05; 1805; 220,242; 3080000; 1706,209; 1657,825
2005-12-24 03:27:08; 1808; 219,93; 3085000; 1706,158; 1675,603
2005-12-24 03:27:11; 1811; 219,93; 3090000; 1706,093; 1666,667
2005-12-24 03:27:14; 1814; 218,93; 3095000; 1705,983; 1640,958
2005-12-24 03:27:17; 1817; 218,992; 3100000; 1705,83; 1616,031
2005-12-24 03:27:20; 1820; 220,242; 3105000; 1705,825; 1702,417
2005-12-24 03:27:23; 1823; 219,742; 3110000; 1705,701; 1632,387
2005-12-24 03:27:26; 1826; 218,555; 3115000; 1705,564; 1624,431
2005-12-24 03:27:29; 1829; 218,68; 3120000; 1705,472; 1649,621
2005-12-24 03:27:32; 1832; 218,367; 3125000; 1705,364; 1640,958
2005-12-24 03:27:35; 1835; 218,18; 3130000; 1705,301; 1666,667
2005-12-24 03:27:38; 1838; 218,617; 3135000; 1705,31; 1711,157
2005-12-24 03:27:41; 1841; 218,805; 3140000; 1705,233; 1657,825
2005-12-24 03:27:44; 1844; 219,555; 3145000; 1705,127; 1641,497
<SNIP> After running for 60 minutes ...
2005-12-24 03:57:01; 3600; 215,93; 6120000; 1699,646; 1693,193
2005-12-24 03:57:03; 3603; 215,68; 6125000; 1699,648; 1702,417
2005-12-24 03:57:06; 3606; 215,117; 6130000; 1699,657; 1711,157
2005-12-24 03:57:09; 3609; 215,305; 6135000; 1699,652; 1693,193
2005-12-24 03:57:12; 3612; 215,43; 6140000; 1699,654; 1701,838
2005-12-24 03:57:15; 3615; 216,867; 6145000; 1699,656; 1702,417
2005-12-24 03:57:18; 3618; 215,805; 6150000; 1699,643; 1684,069
2005-12-24 03:57:21; 3621; 215,742; 6155000; 1699,645; 1701,838
2005-12-24 03:57:24; 3624; 215,68; 6160000; 1699,64; 1693,193
2005-12-24 03:57:27; 3627; 215,867; 6165000; 1699,627; 1684,069
2005-12-24 03:57:30; 3630; 216,43; 6170000; 1699,622; 1693,193
2005-12-24 03:57:33; 3633; 215,367; 6175000; 1699,602; 1675,603
2005-12-24 03:57:36; 3636; 216,117; 6180000; 1699,59; 1684,069
2005-12-24 03:57:39; 3639; 215,555; 6185000; 1699,577; 1684,069
2005-12-24 03:57:42; 3642; 215,68; 6190000; 1699,572; 1693,193
<SNIP> Closing the Test ...
2005-12-24 04:12:47; 4546; 216,555; 7735000; 1701,162; 1675,042
2005-12-24 04:12:50; 4549; 216,742; 7740000; 1701,163; 1702,417
2005-12-24 04:12:53; 4552; 216,93; 7745000; 1701,158; 1693,193
2005-12-24 04:12:55; 4555; 216,617; 7750000; 1701,153; 1693,193
2005-12-24 04:12:58; 4558; 216,242; 7755000; 1701,142; 1684,069
2005-12-24 04:13:01; 4561; 215,867; 7760000; 1701,148; 1711,157
2005-12-24 04:13:04; 4564; 215,742; 7765000; 1701,149; 1702,417
2005-12-24 04:13:07; 4567; 215,305; 7770000; 1701,143; 1692,62
2005-12-24 04:13:10; 4570; 214,867; 7775000; 1701,144; 1702,417
2005-12-24 04:13:13; 4573; 214,617; 7780000; 1701,145; 1701,838
2005-12-24 04:13:16; 4576; 214,555; 7785000; 1701,122; 1666,667
2005-12-24 04:13:19; 4579; 214,93; 7790000; 1701,134; 1720,578
2005-12-24 04:13:22; 4582; 214,555; 7795000; 1701,141; 1711,157
2005-12-24 04:13:25; 4585; 214,305; 7800000; 1701,107; 1649,621
2005-12-24 04:13:27; 4587; 214,805; 7804152; 1701,114; 1714,286
-------------
3) RTL MM (Delphi 7 default Memory Manager)
2005-12-24 04:18:35; Time (sec); Memory (MB); Requests; Avg req/sec; Curr
req/sec
2005-12-24 04:18:38; 2; 129,82; 5000; 1675,603; 1675,603
2005-12-24 04:18:40; 5; 151,82; 10000; 1684,352; 1693,193
2005-12-24 04:18:44; 9; 173,82; 15000; 1578,947; 1403,312
2005-12-24 04:18:48; 13; 195,82; 20000; 1461,241; 1194,172
2005-12-24 04:18:53; 18; 219,82; 25000; 1325,627; 966,744
2005-12-24 04:18:59; 24; 243,82; 30000; 1206,806; 833,333
2005-12-24 04:19:07; 32; 265,82; 35000; 1091,09; 692,617
2005-12-24 04:19:15; 40; 288,82; 40000; 998,826; 627,431
2005-12-24 04:19:23; 48; 309,82; 45000; 925,45; 582,886
2005-12-24 04:19:33; 58; 336,82; 50000; 858,369; 519,481
2005-12-24 04:19:43; 68; 352,82; 55000; 797,83; 467,858
2005-12-24 04:19:55; 80; 372,82; 60000; 741,601; 417,746
2005-12-24 04:20:09; 93; 389,82; 65000; 691,835; 383,23
2005-12-24 04:20:23; 108; 410,82; 70000; 646,186; 347,826
2005-12-24 04:20:40; 125; 430,82; 75000; 595,976; 285,453
2005-12-24 04:21:02; 147; 430,82; 80000; 543,929; 235,471
2005-12-24 04:21:23; 168; 430,82; 85000; 504,592; 233,918
2005-12-24 04:21:47; 191; 431,82; 90000; 468,789; 212,486
2005-12-24 04:22:12; 217; 431,82; 95000; 437,693; 199,497
2005-12-24 04:22:37; 242; 433,824; 100000; 411,655; 193,237
<SNIP> After running for 30 minutes ...
2005-12-24 04:47:54; 1759; 607,828; 275000; 156,272; 94,983
2005-12-24 04:48:48; 1813; 613,828; 280000; 154,412; 93,322
2005-12-24 04:49:42; 1867; 618,828; 285000; 152,631; 92,727
2005-12-24 04:50:36; 1921; 621,828; 290000; 150,921; 92,113
2005-12-24 04:51:31; 1976; 628,828; 295000; 149,268; 91,273
2005-12-24 04:52:26; 2031; 630,828; 300000; 147,676; 90,65
2005-12-24 04:53:22; 2087; 630,828; 305000; 146,132; 89,788
2005-12-24 04:54:17; 2142; 633,828; 310000; 144,672; 89,888
2005-12-24 04:55:13; 2198; 633,828; 315000; 143,29; 89,988
2005-12-24 04:56:09; 2254; 636,828; 320000; 141,97; 89,838
2005-12-24 04:57:05; 2310; 639,828; 325000; 140,668; 88,643
2005-12-24 04:58:01; 2366; 639,828; 330000; 139,431; 88,717
2005-12-24 04:58:56; 2421; 639,828; 335000; 138,319; 90,626
2005-12-24 04:59:52; 2477; 639,828; 340000; 137,246; 90,318
2005-12-24 05:00:47; 2532; 639,828; 345000; 136,226; 90,473
<SNIP> After running for 60 minutes ...
2005-12-24 05:18:33; 3598; 646,828; 440000; 122,276; 88,838
2005-12-24 05:19:29; 3654; 646,828; 445000; 121,781; 89,812
2005-12-24 05:20:24; 3709; 646,828; 450000; 121,314; 90,447
2005-12-24 05:21:20; 3765; 646,828; 455000; 120,847; 89,736
2005-12-24 05:22:15; 3820; 646,828; 460000; 120,398; 89,99
2005-12-24 05:23:11; 3876; 646,828; 465000; 119,941; 88,914
2005-12-24 05:24:08; 3933; 646,828; 470000; 119,49; 88,496
2005-12-24 05:25:04; 3989; 647,828; 475000; 119,075; 89,76
2005-12-24 05:26:00; 4045; 647,828; 480000; 118,655; 88,889
2005-12-24 05:26:56; 4101; 647,828; 485000; 118,249; 89,038
2005-12-24 05:27:52; 4157; 647,828; 490000; 117,861; 89,361
2005-12-24 05:28:48; 4213; 647,828; 495000; 117,489; 89,762
2005-12-24 05:29:44; 4269; 647,828; 500000; 117,118; 89,236
2005-12-24 05:30:39; 4324; 647,828; 505000; 116,766; 89,762
2005-12-24 05:31:35; 4380; 647,828; 510000; 116,415; 89,31
<SNIP> After running for 5 Hours ...
2005-12-24 09:17:48; 17953; 667,891; 1720000; 95,801; 87,359
2005-12-24 09:18:47; 18011; 667,891; 1725000; 95,77; 86,137
2005-12-24 09:19:44; 18069; 667,891; 1730000; 95,74; 86,604
2005-12-24 09:20:41; 18126; 667,891; 1735000; 95,715; 87,767
2005-12-24 09:21:38; 18183; 667,891; 1740000; 95,691; 87,816
2005-12-24 09:22:35; 18240; 667,891; 1745000; 95,665; 87,55
2005-12-24 09:23:32; 18297; 667,891; 1750000; 95,641; 87,792
2005-12-24 09:24:29; 18354; 667,891; 1755000; 95,616; 87,792
2005-12-24 09:25:26; 18411; 667,891; 1760000; 95,591; 87,432
2005-12-24 09:26:24; 18469; 667,891; 1765000; 95,565; 87,193
2005-12-24 09:27:21; 18526; 667,891; 1770000; 95,539; 87,217
2005-12-24 09:28:18; 18583; 667,891; 1775000; 95,515; 87,622
2005-12-24 09:29:15; 18640; 667,891; 1780000; 95,492; 88,179
2005-12-24 09:30:12; 18697; 667,891; 1785000; 95,469; 87,767
2005-12-24 09:31:08; 18753; 667,891; 1790000; 95,447; 88,35
<SNIP> Closing the test, after running for 7 Hours ...
2005-12-24 11:46:44; 26889; 667,891; 2510000; 93,344; 89,061
2005-12-24 11:47:40; 26945; 667,891; 2515000; 93,336; 89,762
2005-12-24 11:48:37; 27001; 667,891; 2520000; 93,327; 88,692
2005-12-24 11:49:33; 27058; 667,891; 2525000; 93,317; 88,84
2005-12-24 11:50:29; 27114; 667,891; 2530000; 93,308; 88,864
2005-12-24 11:51:25; 27170; 667,891; 2535000; 93,299; 88,938
2005-12-24 11:52:22; 27227; 667,891; 2540000; 93,289; 88,717
2005-12-24 11:53:18; 27283; 667,891; 2545000; 93,279; 88,033
2005-12-24 11:54:15; 27340; 667,891; 2550000; 93,268; 88,154
2005-12-24 11:55:12; 27397; 667,891; 2555000; 93,255; 87,313
2005-12-24 11:56:10; 27455; 667,891; 2560000; 93,241; 86,486
2005-12-24 11:57:07; 27512; 667,891; 2565000; 93,231; 88,082
2005-12-24 11:58:03; 27568; 667,891; 2570000; 93,222; 88,938
2005-12-24 11:58:59; 27624; 667,891; 2575000; 93,214; 89,311
2005-12-24 11:59:50; 27675; 667,891; 2579509; 93,207; 89,535
Complete Test Results are available from the Attachements group!
--
Danijel Tkalcec
http://www.deltasoft.hr/rtc/author.htm
The same files are also available here (not zipped):
http://www.deltasoft.hr/rtc/MMTest/AppServerBucket16T.csv
http://www.deltasoft.hr/rtc/MMTest/AppServerFastMM16T.csv
http://www.deltasoft.hr/rtc/MMTest/AppServerNexus16T.csv
http://www.deltasoft.hr/rtc/MMTest/AppServerRTL16T.csv
Worst possible results were achieved using the standard Delphi Runtime
Library (awful performance with highest memory usage).
Btw ... my test applications were compiled using Delphi 7. And if I'm not
mistaken, D2006 uses (or will use) FastMM as the default Memory Manager.
> Btw ... my test applications were compiled using Delphi 7. And if I'm
> not mistaken, D2006 uses (or will use) FastMM as the default Memory
> Manager.
It does indeed
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Borland made a great choice with FastMM :o)
Many thanks to the FastCode project and ...
Excellent job, Pierre! =:o]
What means optimized? Can you provide a set of compiler switches?
> Borland made a great choice with FastMM :o)
>
> Many thanks to the FastCode project and ...
I think its great they recognised some more outside coding which makes
such a marked improvement to their product and incorporated it for us
all to benefit.
> Excellent job, Pierre! =:o]
very excellent!
"FastMM4Options.inc" file modified to:
// speed-up multithreaded applications
{$define AssumeMultiThreaded}
// use FastMove for optimized memory move operations
{$undef UseCustomVariableSizeMoveRoutines}
The rest of the file was the original version,
which is included in the FastMM 4.56 distibution.
--------
BucketMM_ASM optimization
"BucketMem_ASM.pas" file modified to:
// speed-up multithreaded applications
{$undef USEISMULTITHREAD}
// use FastMove for optimized memory move operations
{$define USESYSTEMMOVE}
The rest of the file was the original BucketMem_ASM distribution.
-------
For single-threaded applications, performance will be better with default
options for threading. In other words, if your application is not
multi-threaded, do not modify the default settings for "AssumeMultiThreaded"
in FastMM4 and "USEISMULTITHREAD" in BucketMem_ASM.
FastMove was used as the 2nd unit in project's uses clause and has resulted
in 5-10% speed improvement in my prior tests, so I guess it had the same
impact on the last tests. Modifications done to FastMM and BucketMem
compiler directives have enabled the use of FastMove by the Memory Manager.
One picture says more than a thousand words :o)
FastMM 4.56 didn't really suffer from using 512 Threads (less than 5%
overall application performance loss, where most of it was caused by
additional CPU thread-switching), while memory usage stayed the same (209 MB
with 16 Threads compared to 240 MB with 512 Threads; additional 31 MB was
used by Windows to keep 496 more Stacks in RAM).
In other words, FastMM 4.56 kept the same performance and used the same
ammount of memory in both tests (using 16 and 512 Threads).
The worst thing that happened in this test was that Delphi 7 Runtime Library
MM (standard) has started reporting EOutOfMemory errors very soon (after
only 600.000 processed requests), because it has already used up 2 GB RAM
and obviously needed more.
Please check the Attachments group for the Graphical representation of Test
results and/or LOG files created while running the tests.
In a productive environment, if you connected 4.000 PCs in a LAN to one RTC
SDK Server, your Server would be able to process a LOT MORE than 4.000
requests per second.
In other words, one of the bottlenecks in my tests are slow Client PCs (667
MHz), which now have to work with 300 connections to simulate 300 PCs in a
LAN, which is most certainly not normal for client applications. Another
bottleneck is each Client PCs overflooded IP Stack (Network card), which
causes a lot of connections to drop. Even activating the Connection Limiter
(available in the RTC SDK) to serialize WinSock API Calls on the Client PC
will result in 30% faster performance.
This should be 10% - 30% and depends on current network load.
If you use Fast MM 4.56 with the RTC SDK, the problem won't be the CPU used
by RTC SDK or FastMM. Your Server's performance will depend on the speed of
your code (or other components you use to process input and generate output)
and hardware in use.
Btw ... automatic compression/decompression reduces performance in LAN,
because it uses Client and Server PC's CPU to compress/decompress data. But,
it will most likely increase performance over the Internet, especially when
larger ammounts of data are being sent/received (for example, working with
Datasets).
Automatic Encryption with RTC SDK uses an algorithm that does in-place
encryption/decryption (algorithm is pretty simple), so there is no memory
allocations or data copying involved. Worst-case scenario using automatic
encryption with RTC SDK could be a 1% performance degradation because of
higher CPU usage.
Using 13 Client PCs to flood the Server with requests.
13 conn = 1 connection per Client PC
130 conn = 10 connections per Client PC
650 conn = 50 connections per Client PC
1.300 conn = 100 connections per Client PC
3.900 conn = 300 connections per Client PC
In other words, in about 3 ms ...
1) client prepares a remote function call
2) client sends this call as a request to the server
3) server receives the request
4) server executes a remote function
5) remote function prepares the result
6) server sends the result back to the client
7) client receives the Result
8) client prepares the data and calls the Result event
Thanks *very* much for these tests. Great work!
**********************************
* Merry Xmas & a happy new year. *
**********************************
Regards,
Ronaldo
> Tests using Memory Managers optimized for best performance ...
Thank you very much for the very informative tests. I especially like the
graphs.
Best Regards,
Pierre
Where can I get the FastMove unit ?
Oleg Subachev
All Memory Managers and the FastMove unit are part of the FastCode B&V MM
Validation and Benchmark package, which can be downloaded here:
http://fastcode.sourceforge.net/challenge_content/MemoryManager.html
What I'm doing in my tests is going to extremes, which will probably *NEVER*
happen in any normal application (not even Servers) running in a productive
environment. But, being a perfectionist, I expect my Servers to handle *ANY*
load, no matter how high it may be. And to achieve this, using the best
Memory Manager is essential.
In that hase, having something to help you find Memory Leaks in your
applications is even more important than increasing your applications
performance. And that's where "Memory Leak Reporting" with FastMM comes in
handy. It can generate a log file (on appliction close) with a list of all
leaked memory blocks and a stack-trace of where each leaked memory block was
allocated, so you can easier pin-point the places where your memory is being
spent needlessly.
How does Nexus scale with increasing numbers of threads (and/or CPU's)
compared to FastMM4?
Best regards
Dennis Kjaer Christensen
All Data and Graphs are available here:
http://www.deltasoft.hr/rtc/tests.htm
Rounded to 100 req/sec ...
FastMM with 16 Threads = 2.100 req/sec, 209 MB
FastMM with 512 Threads = 1.900 req/sec, 240 MB
NexusMM with 16 Threads = 1.700 req/sec, 210 - 220 MB
NexusMM with 512 Threads = 1.500 req/sec, 290 - 530 MB
> FastMM with 16 Threads = 2.100 req/sec, 209 MB
> FastMM with 512 Threads = 1.900 req/sec, 240 MB
Performance drops 9.5 % and mem usage increases 15 %
> NexusMM with 16 Threads = 1.700 req/sec, 210 - 220 MB
> NexusMM with 512 Threads = 1.500 req/sec, 290 - 530 MB
Performance drops 11.8 % and mem usage increases 38 - 141%
I would say that FastMM4 scales much better ;-)
FastMM4
Best regards
Danijel,
Pardon me for asking a silly question:
- if you get more throughput with less memory using 16 threads, why would
you want to consider even using 512 threads? Does this suggest that
somewhere between 1 and 512 threads there is an optimum value?
David
This limit is set using one global variable:
RTC_THREAD_POOL_MAX
It can be set to a different value for each application before calling
"Server.Listen".
In this test, Clients are virtualy flooding the Server with requests, so
that most Threads are occupied full-time. In a normal productive
environment, even if you allow RTC to use 512 Threads, it will most likely
have less than 20 Threads working at the same time. And since Thread pool in
RTC is growing on-demand, threads won't even be created if there is no work
to do for them.
Having the abbility to work with more Threads at the same time is
interesting for Servers which have to process a number of long-running
requests. When there are free Threads available in the pool, long-running
requests won't block the rest of the communication.
So, the decision is simple:
"How many parallel threads do you want to allow at peak times"?
I've set up the Default value to 256, which is what most Web Servers use.
--
Danijel Tkalcec
http://www.deltasoft.hr/rtc/author.htm
Please note that those are average values rounded DOWN to a full 100.
To calculate the correct change, you should use the exact data.
Also ... as I stated already in another thread, 31 MB of additional RAM is
needed to keep 496 more Stacks for running Threads (I have lowered the max
stack size to 64K in my apps). This means that FastMM4 used 0% more RAM,
since the additional 31MB were allocated by Windows to store Stacks.
So you are saying that, under normal use, having the extra inactive
threads available ready for an I/O completion is a benefit?
David
With the RTC SDK, yes.
But, I wouldn't go as high as 512 Threads.
This was an extreme, just to see how MMs would behave.
OK, thanks. Another of those "understand the application" things!
David
In a way I'd say yes. What you see is most likely the fact that a default
non-blocking TCP server hits a limit of connections it can handle. Adding more
processors will push that limit up. This limit is the reason for all high
performance TCP servers using IOCP which minimizes the use of threads and thus
swtiching time and contention.
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm
I don't quite follow you, Hannes.
I am handling the same number of connections with 16 as with 512 threads, so
I'm not forced to use 512 threads to handle a high number of connections. I
can also use 4 Threads, if I don't want more than 4 remote functions to be
running at the same time.
I'm not talking about 4 working connections, but 4 remote function calls
being executed. Receiving and Sending of data for any number of connections
can be handled from a single thread with non-blocking communication, same as
with IOCP.
The only difference between IOCP and "standard" non-blocking is that IOCP
issues WSARecv calls to check if there is data available for reading, while
non-blocking receives a message from Windows when data has arrived. I doubt
that IOCP would be able to handle a much higher number of requests, using
the same scenario.
Note that I am using the HTTP protocol (adds some overhead to each request),
client is preparing the request by "constructing the object tree" which is
serialized, compressed and encrypted before being sent to the Server. Then,
Server is encryption, decompressing and deserializing received data to
create the same object tree and make it available to all remote functions
being called. Remote functions then construct another object tree, which is
again serialized, compressed an encrypted before being sent back to the
client.
The highest burden on the CPU is not thread-switching, but
compression/decompression, encryption/decryption and object
serialization/deserialization. If thread-switching had big impact, then
using 512 threads istead of 16 would result in a much higher speed
degradation. I'd say that using 30 times more threads (16 vs. 512) would
result in lot more than 9% performance degradation. Remember that my Server
is handling the exact same number of connections with 16 as with 512
threads.
IOCP was designed by Microsoft to make it easier on developers to implement
high-performance Servers using blocking mode. But, you can achieve the same
performance using non-blocking mode, if your design can handle it.
In any case, I'd be happy to test any Client/Server application in my LAN,
doing similar tasks, to make a direct comparison to the RTC SDK.
13 Clients, each of them using 300 connecetions in multithreaded mode are
sending this nested remote function call to the Server:
with Data.NewFunction('add') do
begin
with NewFunction('A','add') do
begin
asInteger['A']:=random(1000000);
asInteger['B']:=random(1000000);
end;
with NewFunction('B','mul') do
begin
asInteger['A']:=random(1000000);
asInteger['B']:=random(1000000);
end;
end;
In other words, client is calling something like this:
res := RPC_add ( RPC_add ( random(1000000), random(1000000) ),
RPC_mul ( random(1000000), random(1000000) ) );
This is a nested remote function call, which means that results from nested
"add" and "mul" function calls will be passed to the "add" function, which
will prepare the final result, which is then sent back to the client.
Server has only 2 remote functions:
procedure TAppSrv_Module.AddFuncExecute(Sender: TRtcConnection;
Param: TRtcFunctionInfo; Result: TRtcValue);
begin
Result.asFloat:=Param.asFloat['A']+Param.asFloat['B'];
end;
procedure TAppSrv_Module.MulFuncExecute(Sender: TRtcConnection;
Param: TRtcFunctionInfo; Result: TRtcValue);
begin
Result.asFloat:=Param.asFloat['A']*Param.asFloat['B'];
end;
All communication is going through HTTP, using automatic compression and
encryption. If it's possible to implement something comparable using some
other component set, I'd be happy to run a test and publis results.
This not only allows you to call remote functions from within remote
functions, but it's so flexible that you could send a complete script to be
processed by the server, provided there is a remote function implementet for
each function you will be using in your script.
Best comparison to this would be sending an PL/SQL script to a Database
server for processing, then receiving one or more datasets as a result.
Btw ... this counts as 1 request.