\section*{Pain Points in Regards to Performance}
In the current state of the architecture there are two main categories of paint points that seem like good candidates for optimization:
\begin{itemize}
    \item Client-scheduler-engine communication
    \item Data serialization in messages
\end{itemize}

\paragraph*{Client-Scheduler-Engine Communication}  ~\\
In the current architecture, the client communicates with the scheduler to execute tasks. The scheduler is then responsible for communicating with all the connected engines so that they can execute the tasks and return the results of the execution.
The pain point in this becomes apparent when the scheduler has to communicate with a high number of engines (>100). Because the scheduler is sending its messages one by one to the engines, this doesn't scale well (O(n)) when you increase the number of engines. Also because the scheduler is listening to messages back from the engines, it will keep getting interrupted when trying to send its messages to the engines.

\paragraph*{Object Serialization} ~\\
When data is sent in a message it get serialized by the scheduler. This data is serialized for every message that is sent out, even if the data is exactly the same for all the messages. That makes this an O(n) operation  when it could probably be an O(1) operation for situations where the same data is sent to \textit{n} engines.
\begin{figure}
        \includegraphics[width=15cm]{client-scheduler1.png}
    \caption{Client-scheduler-engine Communcation in current architecture}\label{current architecture}
\end{figure}

\vspace*{\fill}
\pagebreak