10 replies to this topic

[Ross Bevin]

We are in the process of purchasing a new ProIV/SQL server. It will run 64 bit versions of ProIV 7.1 and SQL Server Standard 2008 R2. The server runs our in-house manufacturing system of around 60 users. It will have 48 GB RAM, RAID 1 OS, RAID 10 Pro-ISAM/Temp files, RAID 10 SQL Database & RAID 10 SQL Logs (all 15,000 RPM drives).

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




Thanks

PS: I have also posted this on the ProIV Forum site.

[Kevin English]

Ross,
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?
--
Kevin English

[Kevin English]

i guess another possibility for being multi threaded is having the server process handle multiple client connections simultaneously. If that's the case, then you should probably ignore my previous post.
--
Kevin English

[DARREN]

i cannot comment on the configuration of the machine but I am aware that PROIV Version 7 is faster than previous versions. Significant improvements have been made in the area of performance especially in the area of memory management and session footprints. So if nothing else, you should see an increase in performance by just going to this version. Do you use memory file sorting ??

[Ross Bevin]

Hi Kevin,


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.

Regards

Ross

http://forum.proiv.com/posts/list/437.page#930

[Ross Bevin]

Hi Darren,


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

Regards
Ross

[DARREN]

From my recollection when I worked at PROIV, accessing data in memory files was estimated to be 100 faster than that from a pro-isam file. They also have the advantage of being session based so you can 'clear' them without affecting other users/sessions and therefore negates the need to have the terminal id (or some other identifier) present to make the rows unique to the session - a practice often used with pro-isam work/scratch files. Because they are session based the disadvantage is that you cannot see the contents of the memory file for a given session from any other session e.g. using a file browser etc. but this is not really an issue as long as you are confident in the mem files population.

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.

Regards

Darren

Attached Thumbnails

• 

[Ross Bevin]

Hi Darren,

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.



Thanks
Ross

[Kevin English]

BLOCKSIZE should be set to 8912 (well that is what we configured ours to).

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

Edited by Kevin English, 16 March 2012 - 08:35 PM.

[DARREN]

Good catch. The documents state 8192. Just fat fingered the entry. Fixed now.

Thanks

Darren

[Ross Bevin]

Hi Darren,

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?

Thanks
Ross