playframework / playframework/play1
problem with large project very long response times on mod==DEV on Windows
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.6k
- Forks
- 671
- Avg merge
- 12d 15h
- Merged PRs (30d)
- 1
Description
Play Version 1.8.0 --> JDK 17
problem with large project very long response times on production version on windows
the response time of one request slows down from 5ms to 150ms on linux and on windows from 8ms to 5.5sec
To Reproduce
Steps to reproduce the behavior:
get this project https://github.com/jacol84/bigPlay.git and skip to 5 step
- create new project in plya
play new - change Appliaction.java index method
public static void index() {
renderText("aaaa");
}
- create 50k file.java in ./project/app/com/mik
my example
package com.mik;
public class Class1 {
public static void main(String[] args) {
System.out.println("Hello from Class1");
}
}
- run on windows / or linux
play run - send a request and measure the response time
this project is my github https://github.com/jacol84/bigPlay.git
this result respon :
this result on DEV working
on windows (~5,5sek)
on linux(~150ms)
a project without additional files(~5ms)
Expected behavior
I would expect a response of around 10ms
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: Windows 10 and 11
- JDK 17
- i use WSL to linux test
Additional context
the problematic method is play.Play#detectChanges when measuring
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the slowdown with the linked bigPlay project on Windows 10/11 using JDK 17, with 50k Java files and play run. Start by investigating play.Play#detectChanges and compare request timings with Linux and a small project. Done means identifying the Windows-specific cause and bringing the large-project response time close to the expected 10ms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100