ProIV Performance - Are More Processor Cores/Threads Better Than Clock
Posted 14 March 2012 - 09:50 PM
The network guys have given me the choice of the following 2 processors:
2 x Xeon X5675 6 Cores 12 Threads 12 MB Cache 3.46 GHz
2 x XeonE7-2830 8 Cores 16 Threads 24 MB Cache 2.13 GHz
I understand that ProIV is multi-threaded but I can't find any information on what its limitations or preferences are.
1. Given the above configuration,will I get better ProIV performance with the faster processor (X5675) or am Ibetter to go for more cores, threads and cache (E7-2830)?
2. Given the above configuration,will I get better SQL Server performance with the faster processor (X5675) oram I better to go for more cores, threads and cache (E7-2830)?
PS: I have also posted this on the ProIV Forum site.
Posted 14 March 2012 - 11:33 PM
I'm going to go out on a limb here and hazard a guess based on the way I know that a similar tool works. Any performance issues will almost certainly be SQL Server related and not PRO-IV related,
except possibly in the way that PRO-IV creates sql stmts. So choosing the configuration that makes SQL Server run the best will probably be your best choice. 60 users is not really very many and doesn't really say anything about the number of transactions typically performed. I can't comment on what will make SQL Server perform the best. I'd be surprised if your users could tell the difference between your 2 possible configurations.
I'm interested in what way is PRO-IV multi-threaded. What do the different threads do? I can envision a thread that reads network requests from the client and a thread that does the server side processing, but what else can be separated into threads? You can't run 2 separate functions at the same time in 2 different threads, can you?
Posted 15 March 2012 - 01:23 PM
Posted 15 March 2012 - 02:08 PM
Thanks for your reply. Yes you are probably correct regarding SQL. As you can see by my specs I think we have given SQL what it requires as far as disk configuration and memory goes. I have asked the same question on a couple of SQL forums but have yet to receive a reply. As for ProIV I did receive a reply from Jamie Gibson on the ProIV Forum Site (click the link below). He says that a ProIV session only uses one core but of course with many uses running having multiple cores makes a difference.
Posted 15 March 2012 - 02:27 PM
Thanks for your reply. As you can see from my reply to Kevin, Jamie Gibson has provided some good insight into how ProIV handles multiple cores. I'm quite excited about our move to a new server and environment. Currently we are running 32 bit versions of Windows 2003 Server, SQL Server 2005 and ProIV 126.96.36.199. I'm expecting a huge increase in performance with the move to 64 bit Windows 2008 R2 Server, SQL Server 2008 R2 and ProIV 7.1, More so for this upgrade because we have spent more time in determining what SQL likes to have in a server. As for your question on "memory file sorting" are you asking whether or not we use temporary memory files or if we sort temporary memory files? We do not use memory files but I am planning on doing some bench mark tests to see if we should. I did do some testing 5 years ago but didn't see a big difference in report processing speed; not enough to change. Also since our current server only has 12 GB RAM (not bad for a 60 user environment) I'm afraid that it may impact SQL's performance. So, I would be interested to hear more from you on whether or not we should switch our temp ProISAM files over to memory files or not. Keep in mind I have configured the server for the ProISAM file folder to have it's own dedicated RAID 10 array. This new server will have 48 GB RAM so I think there is plenty to go round. Please tell me more on your experience with memory files.
Posted 16 March 2012 - 02:33 PM
We also use the memory file sort feature. When the memory file sort feature IS NOT turned on then PROIV will create a physical sort file to store the results of a sort within a cycle and drive off that. With the memory file sort feature turned on a physical sort file is not created and instead is created virtually. The advantage to this, aside from an increase in performance, is that physical sort files are not left behind if a session terminates abnormally.
The memory sort file section can be added to the pro4v(x).ini file via the control panel configuration under the PROIV Virtual Machine | Virtual Machine Settings | Add section to pro4v(x)
The Section should be Database
The Identifier should be set to SORTFILE
Once submitted a second configuration page is displayed. The FILETYPE should be set to MEMORY and the BLOCKSIZE should be set to 8912 (well that is what we configured ours to). Additional info can be found in the PROIV on-line manuals under the Topic ID: 720293
I have attached a screen shot of our config.
Posted 16 March 2012 - 06:22 PM
Thanks for all the info on memory files. I wonder if the reason I didn't see the performance gain (when i tested this feature 5 years ago) was due to to not having the memory sort option enabled. I'm definately going to do some performance testing. Since I will have a server with 50 GB of RAM I should have no fear of running out. I will post the results once I have them.
Posted 16 March 2012 - 08:35 PM
If it weren't for the screen shot, I would have assumed it was a typo. Certainly it should be 8192, or some other multiple of the OS block size, shouldn't it?
BLOCKSIZE should be set to 8912 (well that is what we configured ours to).
Edited by Kevin English, 16 March 2012 - 08:35 PM.
Posted 16 March 2012 - 10:40 PM
I have just completed some basic tests on my PC and don't see a huge difference in performance with memory files. Here are the specs of my PC.
HP Pavilion HPE
Intel Core i7 CPU 3.2 GHz 12 MB L3 Cache
Barracudaź XT SATA 6Gb/s 3TB Hard Drive 64 MB cache
8 GB RAM
Windows 7 Ultimate x64
SQL Server Standard 2008 R2 x64
ProIV 7.1.9 x64
I have a report function that builds a temp file and later sorts it when it builds the output. I ran tests running just 1 report and tests running 6 reports simultaneously.
File Type Sort File Time 1 Report Time 6 Reports
PRO-ISAM DISK 57 Secs 108 Secs
MKY DISK 55 Secs 108 Secs
PRO-ISAM MEMORY 56 Secs 112 Secs
MKY MEMORY 55 Secs 100 Secs
With the 6 sessions writing and reading to the same temp file I would have expected a much bigger increase in performance when set to MKY. When the file was set to PRO-ISAM it accumulated 26 MB of data when running 6 reports simultaneously. Could the reason why I'm not seeing a big difference due to the HDD caching the data?
Did you do any benchmark tests before you changed over to memory files and if so what difference did you see?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users