PERFORMA MICROFRAMEWORK PHP PADA REST API MENGGUNAKAN METODE LOAD TESTING
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
The need for flexibility in application development by minimizing the constraints of a server production environment makes n-tier architectures increasingly used. This architecture is implemented in the form of middleware or often called API. REST API is an API architecture that is currently the most widely used for middleware-based application development.
 PHP is an easy-to-use programming language for developing REST APIs with its microframework. Each microframework has features such as database connection handling, URL routing, and performance is the top one. The large number of PHP microframeworks with different performance issues makes the selection of API-based application development cores very important. Especially if it is projected to handle data exchange or client requests in large numbers. As a basis for selection, performance testing needs to be carried out on each microframework to determine its suitability for API-based application development.
 Performance testing uses the load testing method and develops the popular PHP microframework as a basis for creating test applications. The microframework includes FatFree, Lumen, Phalcon-micro, and Slim. Testing is carried out systematically using a test plan that has been designed for performance testing needs. The focus is to analyze the RPS (Request Per Seconds) and latency to the percentile that the wrk2 test tool generates on a predetermined test type
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,000 |
| Méta-épidémiologie (sens large) | 0,001 | 0,000 |
| Bibliométrie | 0,001 | 0,003 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,002 | 0,004 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,012 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle