Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker Performance Degradation with One Million Photos #22

Closed
hsa00000 opened this issue Jan 10, 2025 · 1 comment
Closed

Docker Performance Degradation with One Million Photos #22

hsa00000 opened this issue Jan 10, 2025 · 1 comment

Comments

@hsa00000
Copy link
Owner

hsa00000 commented Jan 10, 2025

Describe the bug
Significant performance degradation occurs when running the repository One-Million-Photo Demo using Docker.

To Reproduce
Steps to reproduce the behavior:

  1. Compile Urocissa from source and add one million photos to the album. (This can be done by accessing the endpoint /put/generate_random_data?number=1000000 and modifying the backend config.json file to set disableImg to true.)

  2. Access the album via the web interface and observe the log:

    2025-01-10T12:23:55Z INFO Urocissa::public::utils
      15.96 µs Query cache not found. Generate a new one.
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
     560.00 ns Filter items
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
     168.10 ms Compute layout
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
     120.00 ns Locate data
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
      17.44 µs Write cache into memory
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
       2.28 µs Create JSON response
    2025-01-10T12:23:55Z INFO Urocissa::public::utils
     168.40 ms (total time) Get_data_length complete
    
  3. Start Urocissa using Docker (run the script bash run_urocissa_docker.sh to launch).

  4. Access the album via the web interface and observe the log:

    2025-01-10T12:25:52Z INFO Urocissa::public::utils
      19.40 µs Query cache not found. Generate a new one.
    2025-01-10T12:25:52Z INFO Urocissa::public::utils
     440.00 ns Filter items
    2025-01-10T12:25:56Z INFO Urocissa::public::utils
       4.41 s Compute layout
    2025-01-10T12:25:56Z INFO Urocissa::public::utils
     520.00 ns Locate data
    2025-01-10T12:25:56Z INFO Urocissa::public::utils
        2.88 µs Write cache into memory
    2025-01-10T12:25:56Z INFO Urocissa::public::utils
       19.08 µs Create JSON response
    2025-01-10T12:25:56Z INFO Urocissa::public::utils
       4.41 s (total time) Get_data_length complete
    

    Observed a performance degradation of over 20x (168.40 ms vs 4.41 s), primarily in the Compute layout step, which makes Urocissa unusable at this scale of one million photos.

Expected behavior
Even with potential performance overhead from Docker on Linux, the performance difference should not be this significant.

Desktop (please complete the following information):

  • OS: Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-45-generic aarch64)
  • Version: Urocissa 0.8.0, Docker version 27.4.1
  • Disk usage: 79.0% of 37.23GB
  • Memory usage: 39% of 4GB
@hsa00000 hsa00000 added help wanted Extra attention is needed and removed help wanted Extra attention is needed labels Jan 10, 2025
@hsa00000
Copy link
Owner Author

The performance issue has been addressed in 8799acb by replacing the base Linux image in the Docker container from Alpine to bookworm-slim, a Debian-based image. Ubuntu-based images have also been tested and found to work as a solution. The root cause is suspected to be Alpine's use of musl instead of glibc, which led to significant performance degradation.

While this change resolves the issue, it comes at the cost of increasing the Docker image size from approximately 50MB to 180MB. If a method to achieve similar performance using glibc on Alpine becomes available in the future, switching back to Alpine may be reconsidered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant