ANN: Memory Manager Tests - Detailed Results

[Danijel Tkalcec [RTC]]

* Full LOG files posted to Attachments group *

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

[Danijel Tkalcec [RTC]]

Merry Christmas! :o)

[Danijel Tkalcec [RTC]]

You can download complete Test Results as ZIP file here:
http://www.deltasoft.hr/rtc/MMTest/AppServerTest16T.zip

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

[Danijel Tkalcec [RTC]]

Winner in my RTC SDK Tests was FastMM 4.56 (achieved the best performance
with lowest memory usage).

Worst possible results were achieved using the standard Delphi Runtime
Library (awful performance with highest memory usage).

[Danijel Tkalcec [RTC]]

Btw ... Max Stack Size reduced to 64KB.
This means that for those 16 running threads,
only 1 MB of RAM was used for all Stack.

[Danijel Tkalcec [RTC]]

"Danijel Tkalcec [RTC]" wrote:
> Winner in my RTC SDK Tests was FastMM 4.56 (achieved the best performance
> with lowest memory usage).
>
> 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.

[Liz]

Danijel Tkalcec [RTC] wrote:

> 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

[Danijel Tkalcec [RTC]]

"Liz" wrote:
>
> Danijel Tkalcec [RTC] wrote:
>> 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

Borland made a great choice with FastMM :o)

Many thanks to the FastCode project and ...

Excellent job, Pierre! =:o]

[Max]

Danijel Tkalcec [RTC] wrote:
>
> 1) RTL (standard in Delphi 7)
> 2) FastMM 4.56 (optimized)
> 3) BucketMem_ASM (optimized)
> 4) Nexus DB MM V3
>

What means optimized? Can you provide a set of compiler switches?

[Liz]

Danijel Tkalcec [RTC] wrote:

> 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!

[Danijel Tkalcec [RTC]]

---------
FastMM4 optimization

"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.

[Danijel Tkalcec [RTC]]

Graphical representations of collected Test Results
(Performance and Memory needs) are now available in Attachments.

One picture says more than a thousand words :o)

[Danijel Tkalcec [RTC]]

New Test Results available, using the same RTC SDK AppClient/AppServer Demo,
but this time allowing AppServer to use 512 Threads instead of 16.

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.

[Danijel Tkalcec [RTC]]

Please note that those are FLOOD TESTS using 3.900 connections from 13
Client PCs (300 connections per PC)!

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.

[Danijel Tkalcec [RTC]]

"Danijel Tkalcec [RTC]" wrote:
> 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.

[Danijel Tkalcec [RTC]]

Let me put it another way ...

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.

[Danijel Tkalcec [RTC]]

Results using the Multiple-conncetion Flood Test with 13 - 3.900 connections
with AppClient Demo to call remote functions on AppServer Demo (RTC SDK
Demos) posted to Attachments group.

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

[Danijel Tkalcec [RTC]]

With 13 clients and the avg speed of 4.500 requests per second (check
results), every time a client has sent a request to the server, response
came back to the client in less than 3 ms.

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

[Ronaldo Souza]

Danijel,

Thanks *very* much for these tests. Great work!

**********************************
* Merry Xmas & a happy new year. *
**********************************

Regards,
Ronaldo

[Pierre le Riche]

Hi Danijel,

> 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

[Oleg Subachev]

> // use FastMove for optimized memory move operations

Where can I get the FastMove unit ?

Oleg Subachev

[Danijel Tkalcec [RTC]]

"Oleg Subachev" wrote:
>> // use FastMove for optimized memory move operations
>
> Where can I get the FastMove unit ?

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

[Danijel Tkalcec [RTC]]

Before everyone using Delphi or BCB with the standard Memory Manager starts
to panic because of bad results produced by my tests, I'd like to say that
I've always used the standard Memory Manager for writing my Client and
Server applications and those applications are still working nicely. So,
Delphi's standard MM included in versions before D2006 is good enough for
99% of all applications.

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.

[Danijel Tkalcec [RTC]]

Btw ... if your application is running Out Of Memory, it is fairly possible
that you have Memory Leaks. In that case, simply changing a Memory Manager
won't solve your problems, unless you find out where your memory is
dissapearing.

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.

[Dennis]

Hi

How does Nexus scale with increasing numbers of threads (and/or CPU's)
compared to FastMM4?

Best regards
Dennis Kjaer Christensen

[Danijel Tkalcec [RTC]]

"Dennis" wrote:
> How does Nexus scale with increasing numbers of threads (and/or CPU's)
> compared to FastMM4?

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

[Dennis]

Hi

> 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

[David J Taylor]

Danijel Tkalcec [RTC] wrote:
> "Dennis" wrote:
>> How does Nexus scale with increasing numbers of threads (and/or
>> CPU's) compared to FastMM4?
>
> 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

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

[Danijel Tkalcec [RTC]]

"Danijel Tkalcec [RTC]" wrote:
> 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.

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".

[Danijel Tkalcec [RTC]]

"David J Taylor" wrote:
> 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?

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

[Danijel Tkalcec [RTC]]

"Dennis" wrote:
> Hi
>
>> 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%

Please note that those are average values rounded DOWN to a full 100.
To calculate the correct change, you should use the exact data.

[Danijel Tkalcec [RTC]]

"Dennis" wrote:
>> 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 %

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.

[David J Taylor]

So you are saying that, under normal use, having the extra inactive
threads available ready for an I/O completion is a benefit?

David

[Danijel Tkalcec [RTC]]

"David J Taylor" wrote:
> So you are saying that, under normal use, having the extra inactive
> threads available ready for an I/O completion is a benefit?

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.

[David J Taylor]

Danijel Tkalcec [RTC] wrote:
> "David J Taylor" wrote:
>> So you are saying that, under normal use, having the extra inactive
>> threads available ready for an I/O completion is a benefit?
>
> 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

[Hannes Danzl[NDD]]

> - 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?

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

[Danijel Tkalcec [RTC]]

"Hannes Danzl[NDD]" wrote:
>> - 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?
>
> 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.

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.

[Danijel Tkalcec [RTC]]

Let me explain what this Test is doing.

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.

[Danijel Tkalcec [RTC]]

Using remote functions with RTC SDK, you "pack" any number of remote
function calls in a single request and all of them will be sent to server in
one "package", processed completely on the server-side and all results will
be returned back to the client in a another single package.

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.

[Danijel Tkalcec [RTC]]

> 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) ) );

Btw ... this counts as 1 request.