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.

Sign up for GitHub

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

fix frontend 500 error when probing service #79

Merged
merged 1 commit into from
Apr 23, 2024
Merged

fix frontend 500 error when probing service #79

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion charts/dify/templates/deployment.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -241,6 +241,9 @@ spec:
httpGet:
path: /apps
port: http
httpHeaders:
- name: accept-language
value: en
initialDelaySeconds: 30
timeoutSeconds: 5
periodSeconds: 30
Expand All @@ -250,7 +253,10 @@ spec:
httpGet:
path: /apps
port: http
initialDelaySeconds: 1
httpHeaders:
- name: accept-language
value: en
initialDelaySeconds: 30
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initialDelaySeconds of 30 seconds is too long for the frontend's readinessProbe. Next.js starts up very quickly, usually completing within a few seconds. With initialDelaySeconds set to 30, it takes at least 30 seconds for the frontend to become available. reduce the initialDelaySeconds to 3 seconds?

Copy link
Contributor Author

@LeoQuote LeoQuote Apr 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making this configurable? I experienced unavailability for at least 20 seconds

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making this configurable? I experienced unavailability for at least 20 seconds

In my case, the langgenius/dify-web container took less than one second to reach readiness after starting.

2024-04-24T06:17:49: PM2 log: Launching in no daemon mode
......
06:17:50 0|dify-web  |  ✓ Ready in 210ms

It's important to note that in Kubernetes, the time taken for container scheduling and image pulling is not included in the health check calculations.

timeoutSeconds: 5
periodSeconds: 5
successThreshold: 1
Expand Down
Loading