You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Performance of the sendEach, sendEachAsync methods is too slow. #941
After updating to version 9.2.0 of the firebase-admin-java, I experienced performance issues and had to rollback to a previous version.
The performance of sendEachAsync is several to tens of times slower compared to sendAllAsync.
I don't understand why there is a decision to not provide a batch API anymore, forcing a migration to sendEach or sendEachAsync without any alternatives.
Shouldn't the SDK be provided at a reasonable level with equivalent performance?
Moreover, it does not even use HTTP/2 connections.
Why are all the performance and resource cost issues caused by SDK v9.2.0 passed onto the users?
I believe the batch API should be maintained until an alternative (API) that can match the performance of the existing batch API is developed.
I would like to hear Firebase position on this matter.
same issues: ( and no solution yet ) :) I hope a solution before 20 june 2024 because it is the deadline for old api removal. The solution should be implemented already because developers needs sometimes to implement to their systems. There is less than 2 months.
For large-scale systems, FCM is now way too expensive for deployment cost after deprecating Batch API. In our scenario, our push notifications are intense and traffic is huge and continuous. With the new API endpoint, we found that the performance is too bad unless we deploy many machines to handle the traffic.
For this issue, I would like to know if the FCM team has any suggestions or not because not every scenario is suitable to use Topic.
Reacted by jbeccardi, Ares, jwagun, 지완, Green and xiaolongbao
I'm trying to apply new apis but tt has absolutely serious problem of my projects.
Compare to legacy, it costs too much seconds to get a response.
Please reply any solution except using topic.
We also faced similar situation. We then moved away from firebase-admin-java SDK and have our own implementation where we use HTTP/2 and multiplexing. For now this works for us.
Activity
google-oss-bot commentedon May 2, 2024
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
emindeniz99 commentedon May 6, 2024
same issues: ( and no solution yet ) :) I hope a solution before 20 june 2024 because it is the deadline for old api removal. The solution should be implemented already because developers needs sometimes to implement to their systems. There is less than 2 months.
#834
#849
raychongtk commentedon May 9, 2024
For large-scale systems, FCM is now way too expensive for deployment cost after deprecating Batch API. In our scenario, our push notifications are intense and traffic is huge and continuous. With the new API endpoint, we found that the performance is too bad unless we deploy many machines to handle the traffic.
For this issue, I would like to know if the FCM team has any suggestions or not because not every scenario is suitable to use Topic.
jwagun commentedon Jun 18, 2024
Any update on this performance issue?
Kyupile commentedon Jun 18, 2024
I'm trying to apply new apis but tt has absolutely serious problem of my projects.
Compare to legacy, it costs too much seconds to get a response.
Please reply any solution except using topic.
georgeaniljohn commentedon Jul 2, 2024
We also faced similar situation. We then moved away from firebase-admin-java SDK and have our own implementation where we use HTTP/2 and multiplexing. For now this works for us.
honorhs commentedon Jul 8, 2024
Do you have any update on this? @lahirumaramba @jonathanedey
moda666 commentedon Aug 22, 2024
Is this issue resolved?
xiaolongbao321 commentedon Sep 14, 2024
Is this issue resolved?
Mzakimohammed commentedon Sep 20, 2024
👍🤗
jonathanedey commentedon Oct 9, 2024
HTTP/2 support has now been added with the release of v9.4.0.
See our wiki for more information on this change.