Table of Contents
Tuning FotoWeb and Index Manager for performance
07. August 2026
Table of Contents
Introduction
Users expect a site to load in 2 seconds or less, and research shows they tend to abandon a site that doesn't load within 3 seconds. Google has conducted extensive testing on user behavior related to page load times, and the results show that users tend to navigate away from a site if it becomes less responsive.
With this in mind, system administrators in a Fotoware DAM must be aware of the hardware requirements, configuration, and regular maintenance tasks, and know how to configure the system effectively.
Fotoware system - hardware requirements
Different types of applications have different requirements: some are CPU-intensive, some are memory-intensive, and others are highly I/O-intensive. A Fotoware system requires all three.
The following table explains why.
| Resource | Why? |
|---|---|
| CPU | Calculations, especially rendition and transcoding tasks. |
| Memory |
Image and video subsampling (large files, large calculations). Caching of immediate objects. Keeping database indexes readily available. |
| IO |
Network bandwidth - Speed of delivery to clients and the number of concurrent users. Disk bandwidth - time to load and serve data (renditions, metadata, and so on) and speed of the database. |
Reducing latency
Latency is the time interval between when a user performs an operation and when they see the response to that action. It should not be confused with interface sluggishness, although sluggishness can be a symptom of high network latency. Bandwidth and latency are not always connected; a high-bandwidth network may be able to push enormous amounts of data quickly, but with considerable latency, a system built on such a network can still be perceived as slow by users due to its prolonged response time.
Key points for reducing latency
- Faster networks
- Is fiber an option?
- In extreme cases, shorter network cables?
- Reduction of middleware
- Can firewalls, proxies, routers, and/or switches be bypassed? Such components inevitably introduce network latency. With only a few connector points, this may not be noticeable; however, in large network environments, they can have a significant impact on performance.
- Faster CPUs
- SSD Drives
- Prefer unencrypted over encrypted protocols
A real-life FotoWeb performance example
Disclaimer
The test results below are meant as an example only and reflect the performance of this specific system. Actual performance relies on several factors, including, but not limited to, the system's hardware and software configuration.
Using the Apache benchmarking tool, Fotoware has conducted a real-life performance test to measure the delivery speed of uncached and cached content from FotoWeb.
TEST IMAGE
File size: 7552 Kb
Dimensions: 5184 x 3456 px (18 megapixels)
Resolution: 240.00 PPI
Benchmarking hardware: Lenovo T430 portable - Intel i7 2.9 GHz, 16GB memory, Dual SSD
Uncached loading results
The screenshot below shows the time it takes to load the uncached image (red text, right-click the image and select Open image in new tab to view a larger version).
How does this scale?
Browsers typically open eight connections to load content, and users may experience delays when content is not cached.
| 1 core | 4 cores | 8 cores | 16 cores | |
|---|---|---|---|---|
| 1 User | 0.8 | 0.2 | 0.1 | 0.1 |
| 10 Users | 8 | 2 | 0.5 | 0.25 |
| 100 Users | 80 | 40 | 20 | 10 |
| 1000 Users | 800 | 400 | 200 | 100 |
Time is in seconds
Results when content is already cached
These are the results of cached content delivery, using the same Apache benchmarking utility to deliver a single file (red text; right-click the image and select Open image in new tab to view a larger version).
How does that scale?
| 1 core | 4 cores | 8 cores | 16 cores | |
|---|---|---|---|---|
| 1 User | 0.024 | 0.006 | 0.003 | 0.0015 |
| 10 Users | 0.24 | 0.06 | 0.03 | 0.015 |
| 100 Users | 2.4 | 0.6 | 0.3 | 0.15 |
| 1000 Users | 24 | 6 | 3 | 1.5 |
Time is in seconds
What to do if there is a lot of uncached content in the archives?
In certain environments, such as those that receive large image feeds, there may be significant portions of uncached content at any given time. To compensate for such content, the solution is to add more hardware:
- Faster disks
- Faster CPUs
- More CPUs
Another option is to add more Index Manager servers to help the system keep up with the incoming file flow.
Fotoware 8.0 architecture - dos and don'ts
The chart below shows the system architecture in Fotoware version 8.0. Select the image to open a larger version.
The key point is that FotoWeb requires low-latency access to both MongoDB and Index Manager. They should be on the same LAN and not be constrained by any firewalls. Often, a firewall can significantly slow down performance, and performance can vary considerably depending on several factors. At times, it may work just fine, while at other times, performance may be sluggish. Because troubleshooting such issues can be challenging, we recommend running these components on the same LAN and ensuring minimal latency between them.
Strongly discouraged configurations
The chart below illustrates a system in which a firewall filters communication between FotoWeb/MongoDB and Index Manager, and between Index Manager and the storage system on the other end. Index Manager relies on being able to push metadata to MongoDB (the FotoWeb metadata database), and introducing latency at that level can negatively affect performance. Additionally, client communication from FotoWeb, which runs on ports 7000/7001 by default, will need to be routed through the firewall, potentially affecting how users perceive client performance.
Finally, the last chart shows a configuration where a firewall has been placed between FotoWeb and the MongoDB instance. This configuration should be avoided, as it introduces latency for many core functions in FotoWeb, likely resulting in performance issues.
Recommendations
Ideally, any firewall on the system limits incoming traffic from the internet to the FotoWeb server, for instance, by allowing only ports 80 and/or 443. Performance-wise, it is best to place the entire system - FotoWeb, Index Manager, and file storage- in the DMZ zone so the servers can communicate freely without firewall restrictions.
Configuring Index Manager for use with FotoWeb
To reduce the possibility that users execute queries that generate a lot of server processing and/or extremely large results, you can remove the option to use wildcard characters at the beginning of the search string.
- In the Index Manager app, go to Indexes and open the Advanced tab for the relevant index.
- Select Disable leading search characters
For more information, see Disabling leading search characters.
Configuring FotoWeb for optimal searching
From the Tools menu (cogwheel icon), go to Site Configuration > Searching.
A system administrator can configure FotoWeb to only allow searches to return a certain number of hits. This prevents users from running extremely wide queries that take a long time to process and reduces server traffic when users scroll through their results in the thumbnail grid.
Additionally, it's good practice to set a search timeout as low as possible, so that if Index Manager fails to deliver a search result within the specified timeframe, you can determine that the performance issue is related to Index Manager.
If the search timeout period is too long, the server's capacity to serve results to a large number of concurrent users will be reduced.
For more information about searching in FotoWeb, see Searching in FotoWeb.
Example: Index Manager performance benchmarking
| SATA instance | SSD instance | |
|---|---|---|
| CPU | 8 vCPUs, AMD Opteron 2,1 GHz | 8 vCPUs, AMD Opteron 2,1 GHz |
| RAM | 30GB | 30GB |
| Disks | RAID 10-protected SATA | RAID 10-protected SSD |
| Index size | 100,475 JPEGs | 100,475 JPEGs |
Indexing speed
This table shows the time it took to index the roughly 100,000 files on the two systems. Cache warming is the process of creating low-resolution thumbnail caches for indexed assets that can be delivered to clients.
| SATA instance | SSD instances | SSD gain | |
|---|---|---|---|
| Indexing | 18m 50s | 11m 11s | -38% |
| Cache warming | 13m 20s | 5m 31s | -58% |
As the table shows, reading metadata (the indexing process) requires significant I/O, and generating thumbnails during cache warming is even more I/O-Intensive.
Query speed
For these tests, the Index Manager cache was disabled to show actual disk I/O performance.
| SATA instance | SSD instance | SSD gain | |
|---|---|---|---|
| Single result | 10 ms | 5 ms | -50% |
| ~4k results | 100 ms | 50 ms | -50% |
| ~40k results | 750 ms | 450 ms | -40% |
| ~100k results | 1800 ms | 1200 ms | -22% |
As the table shows, searching is also IO-intensive. The servers were equally equipped, apart from the storage system. From a user's perspective, anything below 100 ms will be perceived as instant. Note that the times reported here are the search times as recorded by Index Manager; therefore, any network latency will affect how long it takes for the resulting thumbnails to appear on the client's screen.
Naturally, the size of the result set also affects the query's performance, so educating users on how to create meaningful queries is crucial. Using taxonomies to help users filter archive content is also valuable in this regard.
Tools for analyzing Index Manager performance
Index Manager 8.0 has tools to measure its performance using Windows utilities. For more information, see Analyzing Index Manager performance.