14 Replies Latest reply on Nov 23, 2009 5:41 PM by Todd Puckett

    Search speed performance

    Jason Capriotti

      Enterprise is great.....but whenever you replace an older system.....you hear from users about any shortcomings it has compared to the old system.


      One is search speed. Searching for PDFs of our drawings takes around 6-10 seconds in Enterprise on our test server. There are about 70,000 PDFs being searched. In the legacy home built system it takes about 1 second. First thing the users noticed of course.


      So does this search time sound right for something that only returns around 10 files? What on the server affects search time most? This is a test system and the server is little older (2007). The memory on it is pushing 2.7gb total usage which seems a little high....most of it is SQL (1.8gb)


      Test Server

      Windows server 2003 (32bit)

      (2x) Xeon Dempsey 5050 3ghz

      4gb ram

      SQL 2008

      Enterprise 2009 sp4


      Production Server

      Windows server 2003 (64bit)

      (1x) Xeon Gainstown 2.53ghz

      12gb ram


      Legacy system (20 years old)

      IBM AIX (Operating system)

      IBM FS570

      Database is Interbase


        • Re: Search speed performance
          Devon Sowell

          Hi Jason-


          Is the SQL Server/Database on it's own partition/disc and the Archive Server on a different partition/disc? That's the set up I like to use. I'm offsite this week away from Enterprise.



          • Re: Search speed performance
            Are you using the default "Complete Search" card? I have not done any testing, but creating a simpler search might make it faster.
            • Re: Search speed performance
              Lucas Dexter


                  There are many things that will speed up and slow down the search.  The search card itself has little if nothing to do with speed.


                   The first line of attack for speeding up SQL searches is a fast processor.  Like I have mentioned in other posts, SQL is a processor HOG!  I would suggest dual quad cores in the database server if you can afford it.  You and your users will appreciate it.  We just upgraded our database server to dual quad cores with 12 GB of ram from a single dual core processor with 8GB of ram and the difference is like night and day!  It is money well spent, believe me.  To test what the processor is going through, open the task manager and monitor your CPU usage on the server while doing a search.  You will be surprised how the processor utilization jumps when performing searches.


                   Also, on the back end, EPDM is hard coded to search in both directions when you enter something in the search field.  For example, if you search on "01", EPDM searches everything with "01" in it, forward and backward.  It is actually like typing *01* in a normal Windows search.  My friend Jeff Barker from PCMC showed me a trick that actually cut our search times by 60% and actually puts less strain on the processor while performing searches.  You can add a "*" before or after your search criteria to force EPDM to only search in one direction.  For example, our users usually know the first several digits of a part number, so they enter 0108* which will search on anything that begins with 0108.  By adding the star after the search criteria, I have actually gotten searches down to 0.0 seconds!  Adding the "*" works so well, I added it to our custom search forms so users do not have to type it every time.


              Test it our and let me know what you think.


              Another thing that effects searches is the number of fields in the data cards.  Make sure you have the least amount of fields in the data cards that you need.  This makes a big difference as well.


              Good luck!



                • Re: Search speed performance
                  Jason Capriotti

                  I guess I need a baseline. Searching typically take around 5 seconds when typing in a drawing number. It is beter on the production server which has more horsepower.


                  Right now we are just dealing with PDF files of our drawings, about 76,000 located in 40,000 folders. The PDF files are not revision controlled per the Enterprise revision system, instead we create a new PDF for each revision. This is so we can handle manufacturing effectivity through the workflow state. So the folders have the drawing number and inside each folder is all revisions of that drawing.


                  I found one speed issue was regarding a variable on the card. When a revision goes to the "Archived" state, we set a variable called "ISArchived"=1. In the search card, this field is set to be unchecked by default so all the files in the "Archived" state are not shown by default. This makes the search take twice as long as setting it to the neutral state (The square) which takes about 3 seconds. I guess the more variables you search on can take longer in some cases.


                  I tried the * and = for searching on drawing number but it doesn't seem to make much difference.

                    • Re: Search speed performance
                      Todd Puckett

                      If you're wanting to see what other users are getting for search times...

                      I used the Complete Search card and searched the entire vault (624,00 files).  I don't think file type would matter but I searched for a known pdf and received 19 results in 1.9 seconds.  Searching for a spefic pdf file name in quotes had 1 result in 4.5 seconds.


                      Our database server is running 2005 SQL Server x64 on Window 2003 x64 standard.  This server has a dual core Xeon 2.5 GHz processor and 6 Gb RAM. (it's a virtual server so we can make changes as needed).