File upload freezes/delays/timeouts if there is a large count of image files. Due to Redis do all preview folder scanning.

Steps to reproduce

1. Enable previews and caching/locking (Redis). Put some 50k image files in different folders & different users.
2. Create previews. (For each image file NC creates a folder in _appdata_xyzw/preview)
3. Upload new files through NC web or any third-party WebDAV client.
4. Upload process freezes shortly after beginning of upload. The more images (=preview folders) are total (across all users), the longer are freezes. Even errors due timeouts when preview folders counts reached 150k and/or several users are active.

Expected behaviour

There should be no such delays/all preview folder scanning/locking.

Actual behaviour

Every time when files are accessed (even at thumbnail size), Redis server starts a process and make a 7 commands for every folder under preview folder regardless of user or files in particular folder. When files are accessed through web only for viewing it is almost unnoticeable except if some preview/thumbnail isn't loaded until Redis is finished. But when new files are uploaded, Redis process freezes upload.
I run Redis monitoring and save results to a file (redis-cli monitor > filename.log).
At every access/upload Redis made 7 commands for each folder under preview like that:

1511216011.732781 [0 127.0.0.1:42534] "INCRBY" "97e0744ba0fb92ff41f34a80803a7a9a/lockfiles/592f193f4d372a748dc3d125a676d4f2" "1"
1511216011.732828 [0 127.0.0.1:42534] "EXPIRE" "97e0744ba0fb92ff41f34a80803a7a9a/lockfiles/592f193f4d372a748dc3d125a676d4f2" "3600"
1511216011.733305 [0 127.0.0.1:42534] "WATCH" "97e0744ba0fb92ff41f34a80803a7a9a/lockfiles/592f193f4d372a748dc3d125a676d4f2"
1511216011.733348 [0 127.0.0.1:42534] "GET" "97e0744ba0fb92ff41f34a80803a7a9a/lockfiles/592f193f4d372a748dc3d125a676d4f2"
1511216011.733393 [0 127.0.0.1:42534] "MULTI"
1511216011.733463 [0 127.0.0.1:42534] "DEL" "97e0744ba0fb92ff41f34a80803a7a9a/lockfiles/592f193f4d372a748dc3d125a676d4f2"
1511216011.733471 [0 127.0.0.1:42534] "EXEC"

If there is a 150k preview folders it takes up to 2 minutes on i3 CPU (more than a 1 M commands, 100 MB). These keys don't resides in Redis memory and every time files are accessed/uploaded, Redis starts the process again. Regardless of how many files/folders actual user have, Redis do it for all preview folders.

Server configuration detail

Operating system: Linux 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64

Webserver: Apache/2.4.18 (Ubuntu) (fpm-fcgi)

Database: mysql 10.0.31

PHP version: 7.0.22-0ubuntu0.16.04.1
Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, session, standard, cgi-fcgi, mysqlnd, PDO, xml, apcu, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, iconv, igbinary, imagick, imap, intl, json, ldap, exif, mcrypt, memcache, mysqli, pdo_mysql, pdo_sqlite, Phar, posix, pspell, readline, recode, redis, shmop, SimpleXML, soap, sockets, sqlite3, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 12.0.3 - 12.0.3.3

Updated from an older Nextcloud/ownCloud or fresh install: fresh

Where did you install Nextcloud from:

Enabled:
 - activity: 2.5.2
 - bruteforcesettings: 1.0.2
 - comments: 1.2.0
 - dav: 1.3.0
 - federatedfilesharing: 1.2.0
 - files: 1.7.2
 - files_pdfviewer: 1.1.1
 - files_sharing: 1.4.0
 - files_texteditor: 2.4.1
 - files_trashbin: 1.2.0
 - files_versions: 1.5.0
 - files_videoplayer: 1.1.0
 - firstrunwizard: 2.1
 - gallery: 17.0.0
 - groupfolders: 1.1.0
 - issuetemplate: 0.3.0
 - logreader: 2.0.0
 - lookup_server_connector: 1.0.0
 - nextcloud_announcements: 1.1
 - notifications: 2.0.0
 - oauth2: 1.0.5
 - password_policy: 1.2.2
 - previewgenerator: 1.0.7
 - provisioning_api: 1.2.0
 - serverinfo: 1.2.0
 - sharebymail: 1.2.0
 - systemtags: 1.2.0
 - theming: 1.3.0
 - twofactor_backupcodes: 1.1.1
 - updatenotification: 1.2.0
 - workflowengine: 1.2.0
Disabled:
 - admin_audit
 - encryption
 - federation
 - files_external
 - registration
 - survey_client
 - user_external
 - user_ldap

{
    "instanceid": "ocvyoyj09sk8",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "REMOVED"
    ],
    "datadirectory": "\/var\/www\/clients\/client0\/web2\/web\/data",
    "overwrite.cli.url": "https:\/\/REMOVED",
    "dbtype": "mysql",
    "version": "12.0.3.3",
    "installed": true,
    "memcache.local": "\\OC\\Memcache\\Redis",
    "filelocking.enabled": true,
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "localhost",
        "port": 6379,
        "timeout": 0
    },
    "mail_from_address": "cloud",
    "mail_smtpmode": "php",
    "mail_smtpauthtype": "LOGIN",
    "mail_domain": "REMOVED",
    "skeletondirectory": "",
    "filesystem_check_changes": 1,
    "default_language": "lv",
    "loglevel": 1,
    "preview_max_x": 1500,
    "preview_max_y": 1000,
    "preview_max_scale_factor": 2,
    "maintenance": false,
    "dbname": "------",
    "dbhost": "127.0.0.1",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "trashbin_retention_obligation": "30, 30",
  
}

Start by tracing previewgenerator and file upload/WebDAV access with the Redis locking settings in config/config.php. Reproduce the issue with many preview folders and inspect Redis activity; done means uploads no longer scan unrelated preview folders or freeze and time out.