Conseils d'infrastructure pour les notifications push multi-plateforme

Question

Nous prévoyons d'introduire des applications Push pour nos applications mobiles (pour les téléphones et tablettes Android, iPhone, iPad et Blackberry).

Toutes les 15 minutes, nous obtenons un nouvel ensemble de données. Ces données sont stockées dans une base de données MySQL. Nous vérifions ensuite si ces données correspondent aux abonnements de nos utilisateurs (les données sont basées sur l'emplacement, de sorte qu'un utilisateur s'abonne à des notifications pour un ou plusieurs emplacements). Tous les utilisateurs avec des données correspondantes doivent ensuite être informés via le service push de leur plate-forme respective.

La capacité du serveur n'est pas un problème. Nous utilisons principalement PHP et préférerions rester avec, mais sommes prêts à aller avec d'autres langues si nécessaire.

Mes questions sont les suivantes:

1. Pouvez-vous me donner des conseils sur la technologie à utiliser sur le côté serveur? Il devrait très bien évoluer (je m'attends à beaucoup d'abonnements sur les plates-formes), idéalement fonctionner avec les passerelles push communes et être assez rapide pour gérer toutes les notifications avant que le prochain lot de données entre en jeu.

2. la vitesse de livraison de ces notifications. Disons que nous avons 500 000 abonnements et que les données correspondent à 50%, ce qui signifie que nous aurions besoin de pousser 250 000 notifications en 15 minutes. Avez-vous de l'expérience avec des nombres élevés et des notifications push?

Merci beaucoup, Mark.

Answer 1

Bien que PHP soit génial pour générer du contenu Web dynamique, je pense qu'il manque certaines fonctionnalités essentielles pour effectuer des opérations en arrière-plan haute performance comme celle-ci. J'irais avec un langage qui supporte le multi-threading (ma préférence personnelle me conduirait à C# 4.0, mais cela dépend aussi de votre plate-forme serveur). Si vous disposez d'une prise en charge multithread, vous pouvez écrire des threads qui chargent les données de la base de données et, pendant le chargement, d'autres threads envoient des notifications. Assurez-vous de pouvoir configurer la quantité de threads utilisée pour chaque partie de la transaction, afin de limiter les performances si nécessaire.

Si un serveur ne peut pas effectuer le travail, vous pouvez envisager de partitionner vos données sur plusieurs serveurs. J'imagine que le moyen le plus rapide de le faire est d'assigner des blocs d'enregistrements à différents serveurs. Un dernier mot de conseil, obtenez un environnement de test où vous pouvez simuler votre problème et faire des tests de stress. Pendant les tests de stress, ne vous arrêtez pas à votre objectif de 500.000, mais continuez au moins dix fois. Ce sera beaucoup plus efficace pour trouver les points faibles de votre logiciel à l'avance. En outre, il serait très utile d'être en mesure d'étrangler certains paramètres matériels, tels que memorey, IO disque, IO réseau et CPU. En simulant une faible quantité sur l'un d'entre eux, vous avez une idée de la façon dont le logiciel va se comporter dans certaines conditions. Cette expérience vous aidera si vous rencontrez des problèmes de performance en production et vous aidera à trouver les exigences matérielles.