Construire un blog de galerie d'images avec Symfony Flex: tests de données

Cet article fait partie d'une série sur la construction d'un blog de galerie multi-images hautes performances utilisant Symfony Flex. (Consultez le référentiel ici.)

Dans l'état précédent, nous avons configuré un projet Symfony de base, créé les appareils initiaux et a fait fonctionner l'application. Cet article se concentre sur le remplissage de la base de données avec un ensemble de données réaliste pour l'analyse comparative des performances. Nous couvrirons également la mise en place d'une suite de tests phpunit.

Objectifs clés:

• Tirez parti de Symfony Flex pour un développement efficace et une optimisation des performances d'un blog de galerie multi-images.
• Implémentez le traitement par lots de la doctrine pour une gestion efficace de la mémoire pendant le chargement du fixation de données.
• Optimiser la gestion des images en présélectionnant les images et en les réutilisant pour réduire la consommation de ressources.
• Effectuer des tests de performances approfondis à l'aide du siège (via Docker) pour simuler les interactions utilisateur du monde réel.
• Établir un cadre de test Phpunit robuste avec des tests fonctionnels et de fumée pour assurer la fiabilité de l'application.

Génération d'un ensemble de données plus grand:

Après le développement initial, la création d'un ensemble de données plus large est cruciale pour les tests de performances réalistes. Alors que les petits luminaires conviennent au développement, les tests de performance nécessitent un volume de données beaucoup plus important. Augmenter simplement la constante COUNT dans nos classes de luminaire (comme indiqué ci-dessous) est inefficace et peut entraîner des erreurs d'épuisement de la mémoire:

<code class="language-php">// src/DataFixtures/ORM/LoadUsersData.php
const COUNT = 500;
// src/DataFixtures/ORM/LoadGalleriesData.php
const COUNT = 1000;</code>

Cette approche est lente, sujette aux erreurs de mémoire (PHP Fatal error: Allowed memory size of N bytes exhausted) et inefficace en raison de téléchargements d'images répétés utilisant Faker.

Optimisation de la doctrine pour le traitement par lots:

Pour résoudre ces problèmes, nous implémenterons le traitement par lots dans la doctrine. Nous allons définir une taille de lot (par exemple, 100 galeries), rincer et effacer l'entitéManager après chaque lot, et utiliser la collection de déchets (gc_collect_cycles()). Cela empêche le ballonnement de la mémoire. Nous surveillerons également l'utilisation de la mémoire et imprimerons les mises à jour de progression. Surtout, n'oubliez pas de remerger les entités dans le gestionnaire après $manager->clear() pour éviter les erreurs "entités non persistantes".

Exemple de luminaire optimisé LoadGalleriesData:

<code class="language-php">// Define batch size
$batchSize = 100;

// ... inside the for loop ...

// Save the batch
if (($i % $batchSize) == 0 || $i == self::COUNT) {
    $currentMemoryUsage = round(memory_get_usage(true) / 1024);
    $maxMemoryUsage = round(memory_get_peak_usage(true) / 1024);
    echo sprintf("%s Memory usage (currently) %dKB/ (max) %dKB \n", $i, $currentMemoryUsage, $maxMemoryUsage);

    $manager->flush();
    $manager->clear();
    gc_collect_cycles();
}</code>

Optimisation de la gestion de l'image:

Au lieu de télécharger dynamiquement des images, nous présélectionnerons un ensemble d'images (par exemple, 15 de UNSPLASH) et les réutiliserons. Cela accélère considérablement le processus. La méthode generateRandomImage peut être mise à jour pour sélectionner dans cet ensemble prédéfini:

<code class="language-php">private function generateRandomImage($imageName) {
    // Array of pre-selected image filenames
    $images = ['image1.jpeg', 'image2.jpeg', ...];
    // ... (rest of the method remains largely the same) ...
}</code>

N'oubliez pas d'ajouter une commande pour nettoyer le répertoire var/uploads dans votre script bin/refreshDb.sh avant de recharger les fixations.

Test de performance avec Siege et Docker:

Nous utiliserons Siege, un puissant outil de référence HTTP, dans un conteneur Docker pour des tests de performances cohérents et reproductibles. Cela évite le besoin d'installations locales et assure des environnements de test cohérents.

Scénarios de test:

Nous définirons les scénarios de test pour simuler diverses interactions utilisateur, y compris:

• Page d'accueil: Tester la charge initiale et le chargement paresseux des pages de galerie suivantes. Nous utiliserons un lazy-load-urls.txt Fichier contenant des URL pour les pages à chargement paresseux, pondérés pour simuler le comportement réaliste de l'utilisateur.
• Pages de galerie unique: Tester les performances des pages de galerie individuelles à l'aide d'une liste d'URL dans galleries.txt.

Configuration du phpunit pour les tests de fumée:

Une suite de tests phpunit de base avec des tests de fumée garantira que la fonctionnalité de base reste intacte pendant le développement et l'optimisation. Ces tests vérifieront les codes de réponse HTTP réussis pour les URL clés.

Conclusion:

Cet article a détaillé des techniques pour créer un ensemble de données réalistes pour les tests de performances et l'établissement d'un cadre de test robuste. Les futurs articles se plongeront dans l'optimisation des performances PHP et MySQL et des améliorations supplémentaires des performances.

Questions fréquemment posées (FAQ): (ces FAQ restent en grande partie les mêmes que dans l'entrée d'origine, mais pourraient être adaptées en fonction du contexte de cette série de articles de blog spécifique si des questions plus spécifiques se posent. )

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!