From 32e57fb7e4b09d4d5d7a55a5431037fe0d2e8c68 Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:25:56 +0200 Subject: [PATCH 1/7] Read Me Cleaned --- README.md | 108 ++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 72 insertions(+), 36 deletions(-) diff --git a/README.md b/README.md index 7aa04a6..9b3c10f 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,30 @@ -# EasyPass - Distributed E-Ticketing System + +███████╗░█████╗░░██████╗██╗░░░██╗██████╗░░█████╗░░██████╗░██████╗ +██╔════╝██╔══██╗██╔════╝╚██╗░██╔╝██╔══██╗██╔══██╗██╔════╝██╔════╝ +█████╗░░███████║╚█████╗░░╚████╔╝░██████╔╝███████║╚█████╗░╚█████╗░ +██╔══╝░░██╔══██║░╚═══██╗░░╚██╔╝░░██╔═══╝░██╔══██║░╚═══██╗░╚═══██╗ +███████╗██║░░██║██████╔╝░░░██║░░░██║░░░░░██║░░██║██████╔╝██████╔╝ +╚══════╝╚═╝░░╚═╝╚═════╝░░░░╚═╝░░░╚═╝░░░░░╚═╝░░╚═╝╚═════╝░╚═════╝░ + +# 🔴 Distributed E-Ticketing System 🔴 ## About the project -The "EasyPass" distributed E-ticketing system is a  platform made to make managing and selling event tickets easier. It consists of several microservices, each in charge of certain functions including order processing, user authentication, and event catalogue maintenance. The system guarantees security, scalability, and dependability while enabling users to peruse, buy, and manage tickets for a range of occasions. +The EasyPass" distributed E-ticketing system is a  platform made to make managing and selling event tickets easier. It consists of several microservices, each in charge of certain functions including order processing, user authentication, and event catalogue maintenance. The system guarantees security, scalability, and dependability while enabling users to peruse, buy, and manage tickets for a range of occasions. In real-world scenarios, websites often experience downtime during events due to high traffic. Easy Psss was designed to tackle this issue by utilizing distributed computing techniques to enhance service reliability. The system consists of distributed, scalable components as a frontend, API gateway, and backend microservices across three node tiers. For the implementation, kubernetes was used as the container orchestration service. Evaluation of effectiveness involved comparing performance metrics for different scenarios and analyzing numerical data from test cases in later stages. -## Implemented components +Group Details: +- [x] Kavindu Wijesinghe - Kavindu.WijesingheArachchilage@student.oulu.fi +- [x] Nirasha Thennakoon - Nirasha.KaluarachchiThennakoonAppuhamilage@student.oulu.fi +- [x] Sonali Prasadika - Sonali.LiyanaBadalge@student.oulu.fi +- [x] Iresh Jayasundara - Iresh.JayasundaraMudiyanselage@student.oulu.fi## Implemented components ### Detailed description of the system architecture (Application-specific system components): #### High Level System Architecture -![alt text](https://github.com/Death-RAW/sd2des_example/assets/61182412/3673ad1d-b5f6-4e21-8d9a-4117d2a99b68) - +![alt text](https://github.com/Death-RAW/sd2des_example/assets/61182412/3673ad1d-b5f6-4e21-8d9a-4117d2a99b68) figure : High Level System Architecture ## Application-specific system components - User and DNS resolver- These entities will act external to the system @@ -41,64 +52,78 @@ and analyzing numerical data from test cases in later stages. - Database - Repository for storing and managing critical data related to users, events, tickets, orders, payments, and other essential information. ________________________________________________________________________________ ![alt text](https://github.com/Death-RAW/sd2des_example/assets/61182412/111f4dcd-e9b5-4770-bb41-ac61f56a94da) -Simplyfied event flow - - +Figure : Simplyfied event flow ## Principles covered in the course -### Architecture : Service-oriented architectures -[Misco Services](https://microservices.io/) has been used to implement the project following the Service Oriented Architecture (SOA). The microservice architecture enables an organization to deliver large, complex applications rapidly, frequently, reliably, and sustainably. More details about the microservices can be found [here](https://microservices.io/). +### Architecture : Service-Oriented Architecture +[Misco Services](https://microservices.io/) has been used to implement the project following the [Service Oriented Architecture](https://collaboration.opengroup.org/projects/soa-book/pages.php?action=show&ggid=1314). The microservice architecture enables an organization to deliver large, complex applications rapidly, frequently, reliably, and sustainably. More details about the microservices can be found [here](https://microservices.io/). -Based on the microservice architecture, Distributed-E-Ticketing implements five main services: user service, ticketing service, event service, order management service, and payment service. +Based on the microservice architecture, Distributed-E-Ticketing Easy Pass system implements five main services: user service, ticketing service, event service, order management service, and payment service. -- user-service - managing user related functionalities -- ticketing service - managing ticket reservation, availability etc -- event service - handle event related functionalities -- order management service - manage orders -- pyament service - handle payement requests like purchases, refunds +- User-service - managing user related functionalities +- Ticketing service - managing ticket reservation, availability etc +- Event service - handle event related functionalities +- Order management service - manage orders +- Pyament service - handle payement requests like purchases, refunds ### Communication : REST APIs with HTTP #### API Endpoints: -The code defines several API endpoints using HTTP methods such as POST, GET, PUT, and DELETE. For example: +The Easy Pass defines several API endpoints using HTTP methods such as POST, GET, PUT, and DELETE. For example: - /api/event (POST): Creates a new event. - /api/events (GET): Retrieves all events. - /api/event/:id (GET): Retrieves a specific event by its ID. - /api/event/:id (PUT): Updates a specific event by its ID. - /api/event/:id (DELETE): Deletes a specific event by its ID. -These endpoints serve as communication channels through which clients can interact with the server to perform CRUD operations on events. -The communication between services is handled using Representation State Transfer (REST) over HTTP. By defining clear API endpoints, following the request-response cycle, transferring data in JSON format, and handling errors effectively, the codebase ensures seamless communication between clients and servers, facilitating the exchange of information and enabling the implementation of various features in the application. +These endpoints function as communication channels through which clients can communicate with the server to perform CRUD operations on events. +The communication between services is handled using Representation State Transfer ([REST](https://www.codecademy.com/article/what-is-rest)) over HTTP. By defining clear API endpoints, following the request-response cycle, transferring data in [JSON](https://www.json.org/json-en.html) format, and handling errors effectively, the codebase ensures seamless communication between clients and servers, facilitating the exchange of information and enabling the implementation of various features in the application. ### Naming -Each and every endpoint expose from the API gateway is named using URI. +Each and every endpoint expose from the API gateway is named using [URI](https://www.w3.org/Addressing/). #### Descriptive Route Names have been used -The route names in the payment-routes.js file are descriptive and reflect the actions they perform. For example, /payment is used for processing payments, and /payment/:id/refund is used for initiating refunds. This will help to understand the purpose of each route quickly. +The route names in the services-routes.js files are descriptive and reflect the actions they perform. For example, /payment is used for processing payments, and /payment/:id/refund is used for initiating refunds. This will help to understand the purpose of each route quickly. -#### Celar Resource Identification: +#### Celar Resource Identification used: The use of parameters in route paths, such as :id in /payment/:id/refund, follows RESTful principles for resource identification. This allows for identifying specific resources (e.g., payments) using unique identifiers (IDs) in the URI. By doing this, code is predictable to utilize in the distributed system. -#### Modular Organization of routes and: +#### Modular Organization of routes and controllers: The separation of concerns between routes and controllers provides modular organization. Each file, such as payment-routes.js and paymentController.js ext., focuses on a specific aspect of the application (routing and business logic, respectively), promoting clarity and maintainability. This modular structure aligns with the principles of microservice architecture, where components are decoupled and independently deployable. - - #### Consistent Naming Conventions: -The code follows consistent naming conventions throughout. For instance, camelCase is used for variable and function names (processPayment, refundPayment), which is a common convention in JavaScript development. Consistency in naming conventions helps in reducing cognitive load for developers and ensures uniformity across the codebase. +The system follows consistent naming conventions throughout. For instance, camelCase is used for variable and function names (processPayment, refundPayment), which is a common convention in JavaScript development. Consistency in naming conventions helps in reducing cognitive load for developers and ensures uniformity across the codebase. Example : /purchaseTicket - the enpoint which allows to buy tickets /login - the endpoint which can be used to login to the system Controller function Names: The controller function names such as processPayment and refundPayment in the paymentController.js file are an example, and they are also descriptive and self-explanatory. These clearly indicate the actions they perform, which is according to the Single Responsibility Principle (SRP) by focusing on a specific task + +### Fault Tolerance +In a EasyPass, fault tolerance is crucial to ensure uninterrupted service despite failures in individual components. + +#### Redundancy in EasyPass: + +Database Replication: As mentioned earlier, the system employs database replication to maintain multiple copies of data across different nodes or replicas. If one database node fails, the system can seamlessly switch to another replica, ensuring data availability and continuity of service. +Service Redundancy: Critical services such as payment processing, order management, and user authentication are deployed redundantly across multiple servers or containers. If one instance fails, traffic can be rerouted to the redundant instances, minimizing service disruption. + +#### Load Balancing: + +At a high level, the EasyPass utilizes a load balancer, specifically Nginx, to efficiently manage incoming internet traffic. Nginx acts as the gateway, directing requests to multiple instances of a React frontend application. These instances are dynamically scaled based on traffic thresholds using a provided script. Once traffic reaches a certain stage, it's routed through the API gateway for authentication and onward redirection to backend microservices. This load balancing approach ensures optimal resource utilization, scalability, and reliability for the entire system. + + ## Built with: +![NodeJS](https://img.shields.io/badge/node.js-6DA55F?style=for-the-badge&logo=node.js&logoColor=white) + +![React](https://img.shields.io/badge/react-%2320232a.svg?style=for-the-badge&logo=react&logoColor=%2361DAFB) + +![AWS](https://img.shields.io/badge/AWS-%23FF9900.svg?style=for-the-badge&logo=amazon-aws&logoColor=white) -- [x] NodeJS -- [x] React -- [x] AWS -- [x] Firebase -- [x] HTTP -- [x] JMETER +![Firebase](https://img.shields.io/badge/firebase-a08021?style=for-the-badge&logo=firebase&logoColor=ffcd34) + +![HTTP](https://img.shields.io/badge/HTTP-blue) + +![Static Badge](https://img.shields.io/badge/JMeter-blue) ### Functionalities Overview: @@ -133,7 +158,6 @@ The controller function names such as processPayment and refundPayment in the pa #### Order Management: - Upon successful payment, order details are sent to the user. -### Detailed Options #### Authentication and Authorization: - The system uses JWT-based authentication. Users need to log in to perform certain actions, and there's middleware to handle authentication (authMiddleware). @@ -162,11 +186,10 @@ The controller function names such as processPayment and refundPayment in the pa - Users can view available events (/viewEvents endpoint). #### Error Handling: - - The system provides appropriate error messages and handles internal errors gracefully. +- The system provides appropriate error messages and handles internal errors gracefully. #### Communication with Microservices: - - The API gateway communicates with various microservices (user, ticketing, payment, event, order management) to perform actions. It abstracts away the complexities of direct communication with these services. - +- The API gateway communicates with various microservices (user, ticketing, payment, event, order management) to perform actions. It abstracts away the complexities of direct communication with these services. ## Getting Started: ### Locally install @@ -315,11 +338,24 @@ Load testing enables the evaluation of how the application performs under heavy ### Results and Analysis ### Latency + +The difference in latency between single-user and multi-user scenarios varies. We cannot definitively state that multi-user scenarios always exhibit higher latency. Endpoints involving complex transactions or database writes tend to demonstrate increased latency under load, aligning with expectations. + ![l1](https://github.com/Death-RAW/sd2des_example/assets/61182412/4b1eec43-ea23-43ec-9c31-636fded4d0a6) ![l2aqv](https://github.com/Death-RAW/sd2des_example/assets/61182412/8953fbe3-6eab-4bfc-b024-731022bc3fbd) ### Throughput + +The difference in throughput between single-user and multi-user scenarios shows some deviations, meaning that single-user scenarios exhibit higher throughput than multi-user scenarios. This is an expected scenario, as the number of users increases, the number of messages processed within a given time decreases. + ![tp1](https://github.com/Death-RAW/sd2des_example/assets/61182412/14a90249-c657-4376-a6f1-0cdba76921d1) ![tp2ac](https://github.com/Death-RAW/sd2des_example/assets/61182412/8bcdd5ff-4b46-4acf-9ebf-007e94a2b42e) + +## Acknowledgements + some *blue* text +This project was carried out as a requirement for the course 521290S Distributed Systems in Faculty of ITEE of University of Oulu. All the work was carried out under the instructions of the respective lecturers of the course. + + - [JMeter](https://jmeter.apache.org) : used for testing purposes + - [PostMan](https://www.postman.com) : used for testing purposes From 7e25baa839f05f0bbab8e7f323d322d18729b603 Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:31:29 +0200 Subject: [PATCH 2/7] ReadMe Cleaned --- README.md | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 9b3c10f..54b8eee 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,19 @@ -███████╗░█████╗░░██████╗██╗░░░██╗██████╗░░█████╗░░██████╗░██████╗ -██╔════╝██╔══██╗██╔════╝╚██╗░██╔╝██╔══██╗██╔══██╗██╔════╝██╔════╝ -█████╗░░███████║╚█████╗░░╚████╔╝░██████╔╝███████║╚█████╗░╚█████╗░ -██╔══╝░░██╔══██║░╚═══██╗░░╚██╔╝░░██╔═══╝░██╔══██║░╚═══██╗░╚═══██╗ -███████╗██║░░██║██████╔╝░░░██║░░░██║░░░░░██║░░██║██████╔╝██████╔╝ -╚══════╝╚═╝░░╚═╝╚═════╝░░░░╚═╝░░░╚═╝░░░░░╚═╝░░╚═╝╚═════╝░╚═════╝░ + +████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ +█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░██░░░░░░░░████░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█ +█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀░░██░░▄▀▄▀░░████░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ +█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░░░▄▀░░██░░▄▀░░░░████░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░░░░░█ +█░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░▄▀░░███████████░░▄▀▄▀░░▄▀▄▀░░██████░░▄▀░░██░░▄▀░░█░░▄▀░░██░░▄▀░░█░░▄▀░░█████████░░▄▀░░█████████ +█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░███░░░░▄▀▄▀▄▀░░░░██████░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░░░░░█ +█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█████░░░░▄▀░░░░████████░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ +█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░░░░░░░░░▄▀░░███████░░▄▀░░██████████░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█ +█░░▄▀░░█████████░░▄▀░░██░░▄▀░░█████████░░▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█████████░░▄▀░░█████████░░▄▀░░█ +█░░▄▀░░░░░░░░░░█░░▄▀░░██░░▄▀░░█░░░░░░░░░░▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░░░░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█ +█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀░░██░░▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ +█░░░░░░░░░░░░░░█░░░░░░██░░░░░░█░░░░░░░░░░░░░░███████░░░░░░██████████░░░░░░█████████░░░░░░██░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█ +████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ # 🔴 Distributed E-Ticketing System 🔴 @@ -20,7 +28,9 @@ Group Details: - [x] Kavindu Wijesinghe - Kavindu.WijesingheArachchilage@student.oulu.fi - [x] Nirasha Thennakoon - Nirasha.KaluarachchiThennakoonAppuhamilage@student.oulu.fi - [x] Sonali Prasadika - Sonali.LiyanaBadalge@student.oulu.fi -- [x] Iresh Jayasundara - Iresh.JayasundaraMudiyanselage@student.oulu.fi## Implemented components +- [x] Iresh Jayasundara - Iresh.JayasundaraMudiyanselage@student.oulu.fi + +## Implemented components ### Detailed description of the system architecture (Application-specific system components): #### High Level System Architecture @@ -354,7 +364,7 @@ The difference in throughput between single-user and multi-user scenarios shows ## Acknowledgements - some *blue* text + This project was carried out as a requirement for the course 521290S Distributed Systems in Faculty of ITEE of University of Oulu. All the work was carried out under the instructions of the respective lecturers of the course. - [JMeter](https://jmeter.apache.org) : used for testing purposes From d6075b6611d1d779bdb3e2823e2e548008dab1cf Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:33:24 +0200 Subject: [PATCH 3/7] ReadMe Cleaned --- README.md | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index 54b8eee..6939ba9 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,8 @@ - - -████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ -█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░██░░░░░░░░████░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█ -█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀░░██░░▄▀▄▀░░████░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ -█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░░░▄▀░░██░░▄▀░░░░████░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░░░░░█ -█░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░▄▀░░███████████░░▄▀▄▀░░▄▀▄▀░░██████░░▄▀░░██░░▄▀░░█░░▄▀░░██░░▄▀░░█░░▄▀░░█████████░░▄▀░░█████████ -█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░███░░░░▄▀▄▀▄▀░░░░██████░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░▄▀░░█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░░░░░█ -█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█████░░░░▄▀░░░░████████░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ -█░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░░░░░░░░░▄▀░░███████░░▄▀░░██████████░░▄▀░░░░░░░░░░█░░▄▀░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█ -█░░▄▀░░█████████░░▄▀░░██░░▄▀░░█████████░░▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█████████░░▄▀░░█████████░░▄▀░░█ -█░░▄▀░░░░░░░░░░█░░▄▀░░██░░▄▀░░█░░░░░░░░░░▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░░░░░░░░░▄▀░░█░░░░░░░░░░▄▀░░█ -█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀░░██░░▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░███████░░▄▀░░██████████░░▄▀░░█████████░░▄▀░░██░░▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█░░▄▀▄▀▄▀▄▀▄▀░░█ -█░░░░░░░░░░░░░░█░░░░░░██░░░░░░█░░░░░░░░░░░░░░███████░░░░░░██████████░░░░░░█████████░░░░░░██░░░░░░█░░░░░░░░░░░░░░█░░░░░░░░░░░░░░█ -████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ +888888 db .dP"Y8 Yb dP 88""Yb db .dP"Y8 .dP"Y8 +88__ dPYb `Ybo." YbdP 88__dP dPYb `Ybo." `Ybo." +88"" dP__Yb o.`Y8b 8P 88""" dP__Yb o.`Y8b o.`Y8b +888888 dP""""Yb 8bodP' dP 88 dP""""Yb 8bodP' 8bodP' # 🔴 Distributed E-Ticketing System 🔴 From 93acf25c869ebdcec977049c4f6d65f6ab8be65f Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:35:53 +0200 Subject: [PATCH 4/7] ReadMe Cleaned --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 6939ba9..843a46c 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ -888888 db .dP"Y8 Yb dP 88""Yb db .dP"Y8 .dP"Y8 -88__ dPYb `Ybo." YbdP 88__dP dPYb `Ybo." `Ybo." -88"" dP__Yb o.`Y8b 8P 88""" dP__Yb o.`Y8b o.`Y8b -888888 dP""""Yb 8bodP' dP 88 dP""""Yb 8bodP' 8bodP' +____ ____ ____ _ _ ___ ____ ____ ____ +|___ |__| [__ \_/ |__] |__| [__ [__ +|___ | | ___] | | | | ___] ___] + # 🔴 Distributed E-Ticketing System 🔴 From 255f9928521df181bd6e8a3e325f6397974444da Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:36:38 +0200 Subject: [PATCH 5/7] ReadMe Cleaned --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 843a46c..5e49941 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ - ____ ____ ____ _ _ ___ ____ ____ ____ |___ |__| [__ \_/ |__] |__| [__ [__ |___ | | ___] | | | | ___] ___] + # 🔴 Distributed E-Ticketing System 🔴 ## About the project From cc1bc06158975938f0a6545cb68b5e37bc989b45 Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 02:38:30 +0200 Subject: [PATCH 6/7] ReadMe Cleaned --- README.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 5e49941..4112bb7 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,9 @@ -____ ____ ____ _ _ ___ ____ ____ ____ -|___ |__| [__ \_/ |__] |__| [__ [__ -|___ | | ___] | | | | ___] ___] - +╔═══╗╔═══╗╔═══╗╔╗ ╔╗ ╔═══╗╔═══╗╔═══╗╔═══╗ +║╔══╝║╔═╗║║╔═╗║║╚╗╔╝║ ║╔═╗║║╔═╗║║╔═╗║║╔═╗║ +║╚══╗║║ ║║║╚══╗╚╗╚╝╔╝ ║╚═╝║║║ ║║║╚══╗║╚══╗ +║╔══╝║╚═╝║╚══╗║ ╚╗╔╝ ║╔══╝║╚═╝║╚══╗║╚══╗║ +║╚══╗║╔═╗║║╚═╝║ ║║ ║║ ║╔═╗║║╚═╝║║╚═╝║ +╚═══╝╚╝ ╚╝╚═══╝ ╚╝ ╚╝ ╚╝ ╚╝╚═══╝╚═══╝ # 🔴 Distributed E-Ticketing System 🔴 From d33a7251fbb9f9b085413b62b2eac17b6a51a823 Mon Sep 17 00:00:00 2001 From: Death-RAW <61182412+Death-RAW@users.noreply.github.com> Date: Mon, 18 Mar 2024 07:47:18 +0200 Subject: [PATCH 7/7] Fine tuned readme --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 4112bb7..04631cb 100644 --- a/README.md +++ b/README.md @@ -293,7 +293,8 @@ Run the script ./setup_gateway.sh Make sure to add the other instance’s (node with all microservices) IP to the .env to build the communication. -## Results of the tests: Evaluation +## Evaluation +JMeter has been utilized for obtaining results and evaluation, as it allows us to measure latency, throughput, and conduct load testing effectively. ### Latency