Closed kierangirvan closed 7 hours ago
Hi @kierangirvan
The be
container is responsible for all the aggregations while fe
for its representation.
Please, check if the p90 data is being returned from the BE in the developer tools in your browser.
On my local (and working) instance, I see the following:
Yet on the cloud hosted instance, I see the following:
In the FE logs I can see the 500 being returned:
And in the BE, it shows the following exception:
It looks like the query for a scenario is failing, could you, please, try to run the following query in the hosted instance DB:
SELECT * FROM jtl.scenario
WHERE name = $2 AND project_id = (SELECT id FROM jtl.projects WHERE project_name = $1);
where $2 is the scenario name, and $1 is the project name.
Output from the cloud hosted DB:
id | name | project_id | threshold_enabled | threshold_error_rate | threshold_percentile | threshold_throughput | analysis_enabled | delete_samples | zero_error_tolerance_enabled | keep_test_runs_period | generate_share_token | label_filter_settings | label_trend_chart_settings | extra_aggregations | apdex_settings | min_test_duration
--------------------------------------+-------------------+--------------------------------------+-------------------+----------------------+----------------------+----------------------+------------------+----------------+------------------------------+-----------------------+----------------------+-----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------+-------------------
6e40e4ce-48e8-4480-aba3-dd6ac3731b55 | e2e_all_soak_test | 28162ab7-523a-474d-9a14-84669f54b051 | f | 5 | 5 | 5 | t | f | f | 0 | f | [] | {"p90": true, "p95": true, "p99": true, "errorRate": true, "avgLatency": false, "throughput": false, "virtualUsers": true, "avgResponseTime": false, "avgConnectionTime": false} | f | {"enabled": false, "satisfyingThreshold": 100, "toleratingThreshold": 400} | 5
And this is from my local instance, the name of the scenario is different but thats expected:
id | name | project_id | threshold_enabled | threshold_error_rate | threshold_percentile | threshold_throughput | analysis_enabled | delete_samples | zero_error_tolerance_enabled | keep_test_runs_period | generate_share_token | label_filter_settings | label_trend_chart_settings | extra_aggregations | apdex_settings | min_test_duration
--------------------------------------+-----------------------+--------------------------------------+-------------------+----------------------+----------------------+----------------------+------------------+----------------+------------------------------+-----------------------+----------------------+-----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------+-------------------
f02fba1c-933b-428f-bc33-dc5fee16bdd1 | e2e_all_peak_perf | 2fbdce07-e3da-4ec5-aa78-53af5b913cb3 | f | 5 | 5 | 5 | t | f | f | 0 | f | [] | {"p90": true, "p95": true, "p99": true, "errorRate": true, "avgLatency": false, "throughput": false, "virtualUsers": true, "avgResponseTime": false, "avgConnectionTime": false} | f | {"enabled": false, "satisfyingThreshold": 100, "toleratingThreshold": 400} | 5
Output looks similar from what we can see.
We have also reinstalled the DB, now running 2.4.1-pg13, previously it was on 2.15.2-pg14 and that seems to have sorted the 500s being returned by the FE, and the error message we observed no longer is being reported. But the 90th percentile is still not showing.
Any thoughts?
@kierangirvan I've pushed a fix addressing this issue. Please try to pull the latest
FE image.
@ludeknovy pleased to confirm that pulling the latest FE has fixed the scenario view of the 90th percentile. However, on the project view (where it shows a trend over each scenario), this is still blank for the 90th:
Recently, I've changed the property on BE side, but the trends’ chart I forgot to update, while the other parts were updated and working fine.
So your local version processed the data before that change in processing, so it was still using the old property, thus working fine.
@ludeknovy pleased to confirm that pulling the latest FE has fixed the scenario view of the 90th percentile. However, on the project view (where it shows a trend over each scenario), this is still blank for the 90th:
I will fix it during today as well.
Fixed 🤞
We have deployed the latest FE and indeed this is now resolved. Thanks as always @ludeknovy
Describe the bug We have recently provisioned the JTL reporter into a new ECS deployment, running on fargate. We have successfully uploaded a basic kpi.jtl and from the logs we can see its been successfully processed. But the scenario trends is not showing the 90th percentile:![image](https://github.com/ludeknovy/jtl-reporter/assets/1891193/ee5af945-71bc-42af-a786-dc0eaab4ab70)
Oddly, on the same version, launching the containers locally, it works fine with the exact same kpi.jtl:![image](https://github.com/ludeknovy/jtl-reporter/assets/1891193/f0edfe98-8a31-4cfa-b507-e71828d22e15)
I can confirm that the scenario trends on both instances are identical i.e.![image](https://github.com/ludeknovy/jtl-reporter/assets/1891193/49943817-a7df-41e6-a8bd-4421785d9116)
We have attempted to toggle the 90th on/off, but no joy. This also makes the Project view of the scenarios a little odd i.e.:![image](https://github.com/ludeknovy/jtl-reporter/assets/1891193/b2b6e737-3492-4b5a-b292-4c0fac99af3b)
When it should look like this:![image](https://github.com/ludeknovy/jtl-reporter/assets/1891193/ed685026-779b-42ac-b2bb-34336faf6689)
Expected behavior The 90th percentile should be visible on the scenario trend and project overview of all scenarios.
Screenshots See above.
Additional context As previously mentioned, the logs do not show anything alarming, but can share if required. Also the version we are running is the latest i.e. v4.10.2 Obviously with this working on a local installation, it does point to an issue with how we've provisioned this in AWS, but if you could shed some light on what container would be responsible for calculating and displaying this metric that would be amazing.