Containers is a widely used way of developing and delivering software today. As they take use of abilities in the kernel to provide isolation and control, they provide a small overhead compared to traditional Virtual Machines. But with using a shared kernel comes additional security threats. A solution to this is to provide a extra layer of virtualization to provide extra isolation.The aim of this research is to study two different runtimes. The selected runtimes are Crun and Kata Containers. Where as Crun is a native low level runtime and Kata Containers offers an additional layer of isolation. To test these runtimes, this study use a Python benchmarking suite called pyperformance, to be able to measure what modules and libraries are affected by this extra layer of isolation.The findings are that the overhead in ranges from <1x up to 44x comparing the two runtimes. This research show what modules and libraries in Python are affected in a significant way when executed in Kata Containers.

Containers have been gaining popularity in recent years due to their ability to provide higher flexibility, higher reliability and dynamic scalability to enterprise software systems. In order to fully utilize containers, software developers aim to build their software using microservice architecture, meaning that instead of working on a single large codebase for the whole project, the software is split into smaller units. These microservices can be deployed in their own container instead of the traditional virtual machine setup where a server has to configured with all necessary dependencies. Moving away from the monolithic software architecture to containerized microservices is bound to bring performance penalties due to increased network calls between services and container overhead. The integration must therefor be carefully planned in order to fully utilize the container setup while minimizing the overhead. The purpose of this thesis project was to measure how much overhead can be expected due to containers in an enterprise environment. By using a combination of virtual machines and Docker containers, a microservice system was deployed with four different deployment strategies and the system’s performance was measured by analyzing request response times under various loads. The services were made to run on a single server and on multiple servers, with and without Docker. The performance measurements showed that the system performed worse in every case when Docker was used. Furthermore, the results showed that Docker can have significant negative impact on performance when there is a heavy load on the system. / Containers har blivit populärare under de senaste åren tack vare deras förmåga att ge högre flexibilitet, högre tillförlitlighet och dynamisk skalbarhet för företagsprogramvarusystem.  För att fullt ut kunna använda containers har programutvecklarna för avsikt att bygga sin programvara med hjälp av mikroservicearkitekturen, vilket innebär att programvaran delas upp i mindre enheter istället för att arbeta på en enda stor kodbas för hela projektet. Dessa mikroservices kan distribueras i sina egna containers istället för den traditionella virtuella maskininstallationen, där en server måste konfigureras med alla nödvändiga beroenden.  Att flytta sig från monolitisk mjukvaruarkitektur till containeriserade microservices kommer att få prestandaförsämringar på grund av ökade nätverksanrop mellan tjänster och container-overhead. Integrationen måste därför noggrant planeras för att fullt ut utnyttja containeruppsättningen och minimera overhead. Syftet med detta avhandlingsprojekt var att mäta hur mycket overhead kan förväntas på grund av containers i en företagsmiljö. Genom att använda en kombination av virtuella maskiner och Dockercontainers, implementerades ett microservices-system med fyra olika implementeringsstrategier och systemets prestanda mättes genom att analysera anropens svarstid under olika belastningar. Tjänsterna gjordes för att köras på en enda server och på flera servrar, med och utan Docker.  Prestandamätningarna visade att systemet var sämre i alla fall när Docker användes. Dessutom, visade resultaten att Docker kan ha signifikant negativ inverkan på prestanda när det är tung belastning på systemet.

A number of technological changes have taken place in packaging market milk. Initially, glass bottles were the only means; later on paper cartons entered the scene. At the present time some plants are packaging mil: in plastic pouches. Since no study seem to hale been made to estimate the cost of packaging milk in plastic poaches, this study was designed. The objectives of the study were to: 1. determine investment in land, building, and equipment for packaging milk in plastic pouches in three model plants; 2. determine unit cost of packaging milk in one gallon and one-half gallon plastic pouches for each plant size; 3. compare cost of packaging in pouches in relation to plant size; and 4. identify factors that might contribute towards economies due to plant size.The economic-engineering approach was used to analyze the cost of packaging. Findings off the study were that the per unit. packaging cost varied from 3.1 cents for model plant 1 to 2.8 cents for model plant 3. Therefore, it is reasonable to conclude that it is not only cheaper to package milk in plastic pouches but also the economies of size can be realized up to a certain point by increasing the plant size.

Com a crescente demanda do transporte multimodal conteinerizado verificado no Brasil, o gerenciamento dos processos logísticos associados ao transporte e às operações portuárias tornou-se uma atividade complexa, envolvendo uma vasta quantidade de variáveis que interferem no desempenho das operações. Na atual conjuntura, a busca pela eficiência nos processos logísticos constitui um fator primordial nesta área. A utilização da simulação como ferramenta permite a visualização minuciosa no desempenho dos recursos utilizados demonstrando ser uma ferramenta poderosa e muito eficiente nas tomadas de decisões e solução de problemas. O modelo computacional desenvolvido permite avaliar as configurações criadas e os arranjos dos equipamentos utilizados, bem como uma variação do número de equipamentos, isto é, uma completa simulação do sistema portuário. Essa simulação, baseada numa movimentação estimada, permitirá o cálculo dos tempos de espera em fila, tempo de atendimento, taxa de ocupação dos equipamentos. Pode-se também variar os arranjos internos do terminal, alterando os tempos das operações envolvidas, podendo assim melhorar o terminal reduzindo tempos de espera e os custos por contêiner movimentado. Em resumo, o trabalho propõe uma metodologia que permite criar arranjos de um terminal de contêineres e veículos, melhorá-los através do modelo de simulação e calcular qual os custos desse terminal, baseando-se na previsão de movimentação de cargas. As melhorias propostas nos arranjos têm como objetivo melhorar a eficiência do terminal, de forma que os custos por unidade de carga movimentada sejam reduzidos, melhorando assim a taxa interna de retorno do investimento. / With the growing demand of the containerized multi-modal transport verified in Brazil, the logistics management processes in associating with the transport and the port operations became a complex activity, involving a great number of variables that interfere in the operation performance. In the current conjuncture, the search for the efficiency in the logistical processes constitutes a primordial factor in this area. The use of the simulation allows to model complex systems, being a very powerful and efficient tool as a decision-making in working out problems. In this context a simulation model associated with a spreadsheet cost was elaborated to allow the design of the port system in which will operate containers and vehicles, permitting to test a set of resources levels, for example: the number of reach stackers, trucks and ship-to-shore cranes. The model allows to choose the demand of containers (TEU per year) and vehicles (units per year), number of berths, ship-to-shore cranes, reach stackers, also the other parameters like as the operational average times for each equipment. After the simulation of the port system for a defined period of time, we are able to analyse the design of the port equipments and the operational cost and investments. It may realize with a sensibility analyses on the system parameters and verify those influences in the final cost.

There are several ways to virtualize machines from the different closed source variants as VMware ESXi and Windows Hyper-V virtualization to open source varies as Xen and Kernel-based Virtual Machine (KVM). There is also another way to virtualize parts of an operating system to increase versatility and be able to use more of the system’s resources in a more efficient way. LXC (Linux Containers) is a lightweight virtualization that is run on top of the existing operating system by encapsulating applications that is inside the container. LXC works so the kernel of the Linux system is shared by the containers that run next to each other without much knowledge of each other. In that way it can be more resource efficient than virtualizing the entire Linux kernel several times for different applications in a traditional guest to host environment. Many data centers today are already using some variant of virtualization in their production environment, it may then be interesting to examine if there are some other methods that result in better performance for chosen application and power savings when hosts can be turned off. That is why this project has carried out a field study to examine how LXC performs when the host system is virtualized in a hypervisor environment. An organization might want to migrate from a hypervisor environment to a lightweight virtualization environment that is based on containers. The work has been done by doing experiments using two different software to examine I/O to determine if LXC is affected by being nested inside ESXi. The study begins with a small background study to obtain information that will give relevant information from previous done work in relevant fields. The study was conducted with the use of the experimental method to be able to answer the hypothesis and the projects questions. The questions that was answered in the project was: How much degradation of the file system's read and write speeds arises when LXC is nested in ESXi? Does it affect the file system's ability to read and write to disk when there are restrictions on available resources? The result of the experiments show that LXC performs close to equal of the bare metal systems, with a 2 percent loss as a minimum and a maximum of 11 percent in write and read ability to/from disk. When LXC is intertwined with ESXi there is an up to 15 percent loss in write and read ability excluding the loss the hypervisor adds. When restricting the resources for a container down to one processor core and two gigabytes of primary memory experiments show that there was a 3 to 15 percent loss in write and read ability from the disk

Para uma empresa de navegação, manter uma frota grande de contêineres próprios poderia gerar custos desnecessários para manutenção dos estoques destes contêineres; contudo, se a frota de contêineres próprios for pequena, poderia resultar em um número grande de contêineres arrendados a curto prazo. Assim, nesta dissertação desenvolve-se um modelo de programação linear capaz de estimar a frota ótima de contêineres próprios e alugados, que envolve a dificuldade da tomada de decisão em um comércio extremamente desequilibrado. A revisão bibliográfica apresenta poucas publicações que tratam do tema proposto. O trabalho desenvolvido por Imai e Rivera (2001) é examinado por ser mais semelhante ao tema proposto para esta dissertação. Por tratarem do dimensionamento de frota de contêineres para dois portos e não admitirem aleatoriedades nos tempos de movimentação terrestre de contêineres outros procedimentos foram examinados. Para tentar solucionar o problema de dimensionamento de frota de contêineres próprios para a empresa de navegação dois métodos são analisados: modelo de simulação probabilística e modelo de programação linear. O modelo de simulação é desenvolvido para um problema pequeno. Conforme a ampliação deste modelo e o aumento do número de variáveis, o modelo de simulação passou a ser difícil de ser controlado, pois a mudança dos valores destas variáveis se tornaria muito difícil. O modelo de programação linear é desenvolvido com base nas características e definições adotadas para o modelo de simulação. Este modelo matemático incorpora as aleatoriedades existentes nos processos terrestres, de acordo com as hipóteses adotadas. Este modelo permite auxiliar o planejador a tomar decisões estratégicas, com relação ao tamanho da frota de contêineres necessários para atender a demanda de transporte ao longo do horizonte de planejamento, e operacionais, por apresentar o fluxo de transporte de contêineres vazios entre portos, bem como a quantidade de contêineres alugados, se necessários, para realizar as operações emergenciais associadas a picos de demanda ao longo do período de planejamento. Para testar a consistência do modelo, cenários hipotéticos foram gerados. Por meio dos resultados obtidos para estes cenários, mostra-se a relação do custo dos contêineres alugados e do custo do transporte de contêineres próprios vazios sobre o tamanho da frota de contêineres próprios. / For a carrier, provide a large fleet of owned containers could generate unnecessary costs for maintenance of their inventories; however, if the fleet of owned containers is small, it might result in a large number of short-term leased containers. Thus, it is developed a linear programming model capable to determine the optimal fleet size of owned and leased containers that involves the difficulty of decision-making in an extremely unbalanced trade. The literature survey presents few publications that deal with the considered subject. The work developed for Imai and Rivera (2001) is examined by being more similar to the subject considered in this project. For dealing with the container fleet sizing for two ports and not admitting stochastic travel times inland of containers other procedures are examined. To solve the problem of own container fleet sizing for the carriers two methods are analyzed: probabilistic simulation model and linear programming model. The simulation model is developed for a small problem. As the growing of this model and the increase of the number of variables, the simulation model becomes difficult to control, because the change of the values of these variables would become very hard. The linear programming model is developed on the basis of the characteristics and definitions adopted for the simulation model. This mathematical model incorporates the existing stochastic inland times, in accordance with the adopted hypotheses. This model allows to assist the planner to make strategical decisions, with regard to the size of the fleet of containers necessary to attempt the demand of transport throughout the planning horizon, and operational, for presenting the flow of empty cont ainers between ports, as well as the amount of leased containers, if necessary, to carry through the special operations associated the peaks of demand throughout the period of planning. To test the consistency of the model, hypothetical scenes had been generated. By the results gotten for these scenes, it is showed the relation of the cost of leases containers and the cost of the transport of empty owned containers above the owned container fleet size.

In recent times Cloud Computing has become an accessible technology which makes it possible to provide online services to end user by the network of remote servers. With the increase in remote servers and resources allocated to these remote servers leads to performance degradation of service. In such a case, the environment on which service is made run plays a significant role in order to provide better performance and adds up to Quality of Service. This paper focuses on Bare metal and Linux container environments as request response time is one of the performance metrics to determine the QOS. To improve request response time platforms are customized using real-time kernel and compiler optimization flags to optimize the performance of a service. UDP packets are served to the service made run in these customized environments. From the experiments performed, it concludes that Bare metal using real-time kernel and level 3 Compiler optimization flag gives better performance of a service.

A common way of organizing Windows, Icons, Menus, and Pointers (WIMP) interfaces is to group tools into tool containers, providing one visual representation. Common tool containers include toolbars and menus, as well as more complex tool containers, like Microsoft Offices Ribbon, Toolglasses, and marking menus. The location of tool containers has been studied extensively in the past using Fittss Law, which governs selection time; however, selection time is only one aspect of user performance. In this thesis, I show that tool container location affects other aspects of user performance, specifically attention and awareness. The problem investigated in this thesis is that designers lack an understanding of the effects of tool container location on two important user performance factors: attention and group awareness. My solution is to provide an initial understanding of the effects of tool container location on these factors. In solving this problem, I developed a taxonomy of tool container location, and carried out two research studies. The two research studies investigated tool container location in two contexts: single-user performance with desktop interfaces, and group performance in tabletop interfaces. Through the two studies, I was able to show that tool container location does affect attention and group awareness, and to provide new recommendations for interface designers.

A common way of organizing Windows, Icons, Menus, and Pointers (WIMP) interfaces is to group tools into tool containers, providing one visual representation. Common tool containers include toolbars and menus, as well as more complex tool containers, like Microsoft Offices Ribbon, Toolglasses, and marking menus. The location of tool containers has been studied extensively in the past using Fittss Law, which governs selection time; however, selection time is only one aspect of user performance. In this thesis, I show that tool container location affects other aspects of user performance, specifically attention and awareness. The problem investigated in this thesis is that designers lack an understanding of the effects of tool container location on two important user performance factors: attention and group awareness. My solution is to provide an initial understanding of the effects of tool container location on these factors. In solving this problem, I developed a taxonomy of tool container location, and carried out two research studies. The two research studies investigated tool container location in two contexts: single-user performance with desktop interfaces, and group performance in tabletop interfaces. Through the two studies, I was able to show that tool container location does affect attention and group awareness, and to provide new recommendations for interface designers.

Ever since the milk bottle was invented in 1884, a number of technological developments have taken place. At present milk is packaged in Plastic Pouches, Tetra-Briks, and Pure-pak cartons.The volume of milk sold in paper cartons in the U.S. has reached about 78 per cent, of which Pure-pak cartons account for about 70 per cent. Besides milk, it is also used for packaging other products such as cole slaw, soft drinks, and laundry detergents.Despite its divergent use and seemingly far-reaching advantages and implications for the market milk industry, no packaging cost study seems to have been done. Therefore, this study was designed to make an economic analysis of the cost of packaging milk in Pure-pak cartons.The economic-engineering approach was used to analyze the cost of packaging. The estimated cost of packaging in small and large plants varied from 7.3 cents to 6.0 cents and from 6.3 cents to 5.8 cents when the machines are purchased and leased, respectively, irrespective of the size of the container. Furthermore, it is economical to use larger plants and lease the, machinery than to buy them.