Assume there exist a document library and three different folders on that,

Folder A

Folder B

Folder C

When search for the term “Folder”, expected results would be

Folder A, Folder B, Folder C

But the actual results contains only Folder A. means even Folder B and Folder C indexed, those will not get included in search results.

Assessment

When finding the root cause for this,

First check whether all these items indexed as expected. Perform a search against the full name or full URL for Folder A, Folder B and Folder C. If these three items getting appear in search results, then it proves that Folder A, Folder B and Folder C already indexed as expected.

To check the indexed details in more detailed manner, contact Microsoft Customer Support. 

Use Search Query Tool to find out what exact  results getting returned here. This tool will give more flexibility to enable/disable query time settings to play with and identify the root cause here.  

Get Search Query Tool from https://sp2013searchtool.codeplex.com/releases/view/119335

When querying with Trim Duplicate option (enable) and check the search results.  Only Folder A will appear in search results.

Then perform the same with out Trim Duplicate Option (disable).

Folder A, Folder B and Folder C will appear in search results.

Conclusion

Even with different URLs and Folder names, SharePoint consider these three entries as duplicates.  Because when calculating there document signature for each of these items, it falls in to a same range.

Workaround

As a workaround, while keeping trim duplicate enabled, can achieve the expected search results by implementing the below configuration changes,

1) For Search Results Web Part or Content Search Web Part

2) Select Edit Web Part

 3) Select Change Query Builder -->  Refiners

 4) Under “Group Results” , go to “Group By” , then select “Show all properties“ and then select DocumentSignature

 5) Then select a number for “Show these results” (select the highest here as 10)

 6) After above changes try the same query as “Folder”, all the expected results as Folder A, Folder B and Folder C will be available among the results.

 The above will act as an workaround for the scenario discussed here. 

Following are some of the basic best practices to be consider when Design and Deploying a SharePoint 2010 farm to full fill a given business need.

Limited- Server Farm Deployment

A) Single Server

 1) Only for Training and Testing purposes

2) Support up to 100 users

3) All the server roles are deployed in single node (web, application and database)

 B) Two server farm

     1) Web and Application server roles are deployed in a single server

     2) Database role is in another server

     3) Can support up to 10,000 users

 Small Farm deployment 

A)  Two - Tier topology

a) The above will have two tiers with 3 servers.

b) Important thing here is query components were deployed in web server roles also with Application server.

B)   Three Tier Topology optimized for search

a)     This will have dedicated Application server, due to the fact that moderate service usage is expected.

b)     Also there exists a dedicated database for search to optimize the usage

c)     This will support up to 10 million users.

Medium Farm Deployment

a) In general this will optimized for search for up to 40 million individual items Each of the services will going to provide by different server roles should be scaled based on amount of content and growth rate

b) If the search volume will going to get extend then deploying another search farm will help to keep the requirements aligned.

c) In general the number of web servers going to add to this medium farm will depend on expected number of users for this.

d) As a rule of thumb I assume 1 web server for every 10,000 users with proper resource utilization of hardware requirements will provide perfect expected performances in Web Front End level.

Large Farm deployments

a) If anyone thinking about this, then the service utilization requirements which includes search are in highest enterprise level.

b) Therefore the best practice would be to group services and associated databases based on their characteristics.

c) For an example group of web servers to manage incoming requests and another set for crawling and administration

d) In general the key concept of the above topology is to have more dedicate set of servers for same characteristics.

While going through the document processing pipeline, FAST Search Server for SharePoint 2010 recognizes more than 80 different languages in common in encodings. In general the metadata belongs to the document contains all the details relates to the text language and the encoding style used. However if it cannot find in metadata then the text language will get determined automatically in side the document processing pipeline in language detector stage. This specific language information is used to select the appropriate language-specific dictionaries and algorithms during item processing.

But in some cases the automatic detection will not be able to determine the language and character set of an incoming document in cases where the incoming document does not have enough characters to detect the correct language or the document contains more than one language in side to represent the text information. To overcome this issue Microsoft has released the April 2012 Cumulative Update for FAST Search for SharePoint 2010 which allows you to define a fallback language and character set when automatic detection of the language and encoding fails.

URL for April CU 2012 https://support.microsoft.com/kb/2598329

In general if automatic detection is not possible, the fallback language is set to unknown and default character set is set to iso-5589-1. But with the April CU 2012 introduced the opportunity to set the fallback language manually. As a result of "unknown" fallback language, will observer that the expected results are not getting returned.  For an example if the fallback language detected as "unknown" and indexed and will assume this document contains some content written in "Russian Language" and in FAST Search Center some one querying for a word exists in side this document. (against a Russian word) What will happen is the query server will not return expected results even though the document and its relevant contents were indexed already. The reason is it cannot match any document which contains the search keyword and labeled as a document which contains "Russian Language" text.

However as mentioned earlier with April CU 2012 users have the ability to set the default fallback language as they wish when they are certain that what type of language texts  they are planning to index and use in side their FAST Search environment.

Following are the steps to follow to set the default fallback language manually,

1) On the FAST Administration node, create a new XML file called LanguageAndEncodingDetectionProperties.xml under %FASTSEARCH%\etc\config_data\DocumentProcessor\ containing the following:

    <properties>
      <language fallback=”<YOUR_FALLBACK_LANGUAGE>” />
      <charset fallback=”<YOUR_FALLBACK_ENCODING>” />
    </properties>

    For the fallback language, please use the code identified for the language at the following URL: Linguistic features per language (FAST Search Server 2010 for SharePoint) . For the fallback character set, please use the preferred MIME name for the encoding specified here: Character Sets

    Note: You must choose both a fallback language and a fallback character set.

2) Save your configuration file.

3) Once your new configuration is ready, issue the following command on every server hosting document processors:

      psctrl reset

4) Reefed your documents.

Also if any one plans to disable or update the fallback language and relevant char set, following is the recommended way of doing it,

1.On your FAST administrative node update or delete %FASTSEARCH%\etc\config_data\DocumentProcessor\LanguageAndEncodingDetectorProperties.xml as appropriate.
2.Restart the configserver:     nctrl restart configserver

3.This step and all subsequent steps must be run on each server running document (item) processors. Identify all running procservers by running the following: nctrl status

4.Stop all processors: nctrl stop procserver_<id>
   Where <id> is an integer value. You must run this command for every procserver entry.

5.Delete the directory %FASTSEARCH%\var\configserver-cache\procserver.

6.Start all procservers: nctrl start procserver_<id>

Article on below URL describes the features in SharePoint 2010 Products that have been deprecated or removed from SharePoint 2013. Deprecated features are included in SharePoint 2013 for compatibility with previous product versions. These features will be removed in the next major release of SharePoint Products. All the details on this article relates to SharePoint Foundation 2013 and SharePoint Server 2013 both.

https://technet.microsoft.com/en-us/library/ff607742.aspx