Hardware suitability test

[jeknepley]

In a vein similar to Microsoft's evaluation of a PC to determine whether its hardware suite (CPU, disk storage, GPU, .... the whole 9-yards) is up to the task of running a specific version of Windows, this should be an option for prospective users of IM as well. It would be nice to know - at least in some relative sense, maybe a score from 1-10 - how well suited the tested PC and its peripherals (especially storage) are suited to the task of running IM5.

This would be more than just helpful - and would avoid a ton of frustration, unhappy customers and support requests - if users knew at least approximately how their system(s) would fare with IM5 BEFORE finding out the hard way.

Possible?

[jch2103]

This isn't what you're looking for, but see https://www.photools.com/community/index.php?topic=2102.0.

[Mario]

Well, I develop and use IMatch on a 4 year old Dell PC, with 8 GB RAM, internal RAID disks and four processors.
Many of my testers use IMatch 5 on laptops or similarly slow machines.

IMatch is not resource hungry. It usually consumes between 300 and 600 MB of RAM, works happily even on computers with one one or two processors (slower of course). Any computer capable of running Window 7 or Windows 8 will run IMatch 5 fast.

I even test IMatch 5 on a single CPU system with Windows 7 (Virtual Box) and it runs there OK. Not a system I would use to work with 50,000 files database, but still. And of course if the initially ingest has been done, IMatch is quite fast even on this slowest possible machine.



In light of your other posts from today, please consider:

1.  You have a database with 170,000 (!) files.
For other DAM vendors this would be an "enterprise solution" and they will ask you to setup a separate server system, dedicated hardware and the like.
There are many stock photo agencies out there which sell photos world-wide and have not half the amount of files you use.

2.  Your files are on a rather slow NAS box. Worst case (slowest scenario) for the initial ingest of images.

3.   The log in your other post indicates that IMatch is currently writing back data to 170,000 files (!) on your slow NAS, which has really bad response times for this task.

Rewriting the metadata for 170,000 files would be an massive task even on internal and very fast hard disks. Doing the same on a NAS box will render your computer unusable for quite some time. There is no free lunch and writing back data over a NAS for this number of files will keep any computer busy for hours and maybe days.

4.   See my tip in the other post about how to reduce the load IMatch produces on your system and NAS box so you can work with other applications and IMatch. Provide the information I requested there for additional input.

[jeknepley]

First of all - I replied to your request for data yesterday. My reply included a question about getting the log file to you because of its size - I included a suggestion. Nothing heard since. I know you're busy but you've responded to others in General Discussion since and I was replying to your request for a better log file.

My DB doesn't have 170,000 (!) files (or did you mean 170,000 factorial  ). I know that's what you saw in the screen shot of the I&A panel (which still goes blank by the way as I reported yesterday). As you know, that figure reflects what the I&A queue always shows at the start of ingesting - basically twice the actual number of image (final) files. It counts down to the actual number of image files as it reads the metadata - after which it actually starts adding files (which are 1/2 the starting queue length shown before metadata is read). My actual total is closer to 1/2 of the figure you cited!

I'm trying to track down the source of the problem starting with the NAS - which you already agreed was NOT a rather slow NAS box based on the Synology specs I provided. Now you say it is slow. Which is it? And believe it or not I am trying your tips, as well as other tidbits found on the help & forums. Further I reported to you on the comparison test I did with a direct connected hard drive vs. the NAS for exactly the same task (NAS 2x as slow - not nearly as bad you seem to be suggesting for a "slow NAS"). Also, several times you've suggested auto write-back as the problem - but I've told you & showed via screenshot that's not the case - auto is disabled. If I got the benefit of the doubt - i.e., not an overly slow NAS and not auto write-back - what might be the problem? Maybe the debug log file I'm trying to send (but need a reply) holds the secret but my General Discussion posts are no longer acknowledged.

If part of the problem is the size of my current 93,969 file (actual count) DB as you suggest (enterprise?) then it's good to know before I invest more time, effort & expense trying to use IM5 productively.

I'll bow out of this discussion at this point because it seems we're not able to close the understanding gap. It seems maybe you tire of this discussion also - so better for both of us to take a break. Thanks for your attempts to help. I'll investigate on my own until such time as I give up and move on - or find a solution. No sense in us taking up each other's time without making any progress. 

[jeknepley]

This isn't what you're looking for, but see https://www.photools.com/community/index.php?topic=2102.0.

Helpful none the less. Thanks very much.

[Mario]

Im not sure what you mean. This discussion seems to have spread over several threads and I lost track.

Did you send or attach a log file from your new attempt? I'm still waiting for it because I still don't know what your system is doing that brings the performance down. A 100,000 files database is large but not that large. I regularly create these in the background for my tests.

Your first log file when I recall correctly contained mostly 2 megabytes of ExifTool error messages and warnings. Which _looked_ like IMatch was writing back data but since the log was neither complete nor in debug mode I could not tell.

So I asked you to create a new DB, set the log to debug, check that you don't make IMatch write back in the background to get a clear look at what's happening. Díd you do that? I'm waiting for this.

[herman]

Did you send or attach a log file from your new attempt?

Mario, just in case you missed it, the logfile is attached here.

[Mario]

That's the problem when the same things are discussed in multiple tracks.
I'm flooded in emails, community postings and I cannot keep everything in my head. 99% of my brain capacity goes into development and bug fixes