Posts de ‘Rafael Silva Pereira’

[Rafael Silva Pereira] Publishing RTSP Streams on FMS! How?

Wednesday, March 11th, 2009

For those who have ever used the Flash Media Server for video streaming, the idea of publishing a stream encapsulated in RTSP (Real Time Streaming Protocol) may seem quite strange, maybe even impossible. This is because the basic (and only) protocol used for FMS client-server communication is the RTMP (and its variations), a proprietary protocol for media streaming, from Adobe. However, in some circumstances the use of an RTMP input is almost impossible, especially when this input stream comes from legacy systems, or from external services. These specific cases require an approach where the content from a RTSP source is delivered using RTMP, that is, a translation from RTSP to RTMP via content repackaging.

The easiest way to perform this translation is using Wowza Media Server, an alternative to FMS that has many interesting features, including the RTSP input support. The problem is that sometimes is impossible to change the video architecture from FMS to other solution, especially when we have developed several applications, or when the whole environment is integrated, up, and running.

In this situation, the intuitive solution would be: we can setup a layer of Wowza Media Server before FMS Servers, working like a translation layer. With this layer, the FMS would receive a RTMP stream exactly like it receives from Flash Media Encoder, making the translation fully transparent. The challenge of this solution is that the Wowza Server cannot publish streams on FMS, so, it cannot act like a FME (from FMS perspective).

To deal with this limitation, we need to change the stream flow paradigm from push to pull, or, in other words, we need to force FMS to get the stream from Wowza. With this architecture configuration, the FMS is no longer a passive component. It is its responsibility to, not only get the video stream, but to perform the failover of the input streams, which can be done through stream multiplexing.

This change in FMS role is only possible if we use server side action script, to connect to Wowza, and to pull the stream flow. Basically, we use NetConnection and Stream classes, to establish a remote connection and to play some content (Wowza stream) through it:

myRemoteConn = new NetConnection();
myRemoteConn.connect("rtmp://wowzaserverhost/streamtest");
myStream = Stream.get("myStream");
myStream.play("my_stream.sdp", 0, -1, true, myRemoteConn);

As we can see, we can use the FMS to delivery RTSP streams without great architecture changes. With Wowza Media Servers and some server side AS, it’s not too hard to make the impossible, possible!

[Rafael Silva Pereira] Publishing RTSP Streams on FMS! How?

Wednesday, March 11th, 2009

For those who have ever used the Flash Media Server for video streaming, the idea of publishing a stream encapsulated in RTSP (Real Time Streaming Protocol) may seem quite strange, maybe even impossible. This is because the basic (and only) protocol used for FMS client-server communication is the RTMP (and its variations), a proprietary protocol for media streaming, from Adobe. However, in some circumstances the use of an RTMP input is almost impossible, especially when this input stream comes from legacy systems, or from external services. These specific cases require an approach where the content from a RTSP source is delivered using RTMP, that is, a translation from RTSP to RTMP via content repackaging.

The easiest way to perform this translation is using Wowza Media Server, an alternative to FMS that has many interesting features, including the RTSP input support. The problem is that sometimes is impossible to change the video architecture from FMS to other solution, especially when we have developed several applications, or when the whole environment is integrated, up, and running.

In this situation, the intuitive solution would be: we can setup a layer of Wowza Media Server before FMS Servers, working like a translation layer. With this layer, the FMS would receive a RTMP stream exactly like it receives from Flash Media Encoder, making the translation fully transparent. The challenge of this solution is that the Wowza Server cannot publish streams on FMS, so, it cannot act like a FME (from FMS perspective).

To deal with this limitation, we need to change the stream flow paradigm from push to pull, or, in other words, we need to force FMS to get the stream from Wowza. With this architecture configuration, the FMS is no longer a passive component. It is its responsibility to, not only get the video stream, but to perform the failover of the input streams, which can be done through stream multiplexing.

This change in FMS role is only possible if we use server side action script, to connect to Wowza, and to pull the stream flow. Basically, we use NetConnection and Stream classes, to establish a remote connection and to play some content (Wowza stream) through it:

myRemoteConn = new NetConnection();
myRemoteConn.connect("rtmp://wowzaserverhost/streamtest");
myStream = Stream.get("myStream");
myStream.play("my_stream.sdp", 0, -1, true, myRemoteConn);

As we can see, we can use the FMS to delivery RTSP streams without great architecture changes. With Wowza Media Servers and some server side AS, it’s not too hard to make the impossible, possible!

[Rafael Silva Pereira] QoS Parameters for Video Streaming

Friday, February 13th, 2009

When we talk about professional media streaming, there is a lot concern with the quality of service, especially when we have large volumes of requests, or when we delivery contents in high definition. In this scenario, is essential to have a fairly clear idea about what is quality of service, and how we can identify, through objective parameters, if we’re or not at an acceptable level, which ensures a high quality experience for end users.

In the case of video streaming, quality of service means that the user should watch a certain content, without interruption (rebuffering), and without degradation of video quality caused by the delivery process (loss of frames, problems in the reconstruction of b-frames and p-frames due packet loss).

Thus, the best known parameter for evaluating the quality of a streaming service is the buffer length, which is the ability to maintain the user’s buffer always at an acceptable level, being greater enough to ensure a continuous experience independent of small variations in bandwidth available, and in the bitrate of the encoded video. Associated with this parameter, we have the average rebuffering rate, which consists of a ratio between the total time used filling the buffer, and the total playing time. This parameter is very interesting to assess the quality of service for live streaming, where users can stay connected for a long time, and, of course, they would like to play the content without interruptions.

A high quality streaming service should always keep the rate of rebuffering below 0.5%, discarding the initial buffer, at normal bandwidth availability. Moreover, this parameter can be very useful to identify network bottlenecks at content distribution process.

Another key parameters are the average frame rate and the rate of frame loss. These two parameters give us an overview of the capacity, of the server to stream the video content, and, of the users to receive and decode the stream. In case of server overloading , one of the first alternatives used to maintain a continuous experience is to reduce the frame rate, or basically, drop frames. These parameters usually indicate that either the server is not able to serve the content, or, the clients do not have the minimum conditions to receive and decode the video. These problems are usually associated with intensive CPU usage, due an excess of clients in the server side, or by lack of resources for decoding the video on the client.

For Flash Media Server specifically, some parameters related with memory usage for input and output buffer, size of buckets, and use of aggregated messages, can influence directly in the video frame rate, but in this case, we can detect the problem even with a small amount of users.

Finally, we have some parameters, not least importants, to complement the set of basic checkpoints to ensure the quality of streaming video service, including, the time to establish the connection, the rate of reconnection, the sync between audio and video, and psnr between the video decoded by the user and the video that comes out of encoder (since the loss of packets may influence the reconstruction of the frames, especially for temporal video compression). Measuring and evaluating all these parameters we can identify with much more efficiency any problem that might compromise the quality of service, which is essential for professional media streaming business.

[Rafael Silva Pereira] QoS Parameters for Video Streaming

Friday, February 13th, 2009

When we talk about professional media streaming, there is a lot concern with the quality of service, especially when we have large volumes of requests, or when we delivery contents in high definition. In this scenario, is essential to have a fairly clear idea about what is quality of service, and how we can identify, through objective parameters, if we’re or not at an acceptable level, which ensures a high quality experience for end users.

In the case of video streaming, quality of service means that the user should watch a certain content, without interruption (rebuffering), and without degradation of video quality caused by the delivery process (loss of frames, problems in the reconstruction of b-frames and p-frames due packet loss).

Thus, the best known parameter for evaluating the quality of a streaming service is the buffer length, which is the ability to maintain the user’s buffer always at an acceptable level, being greater enough to ensure a continuous experience independent of small variations in bandwidth available, and in the bitrate of the encoded video. Associated with this parameter, we have the average rebuffering rate, which consists of a ratio between the total time used filling the buffer, and the total playing time. This parameter is very interesting to assess the quality of service for live streaming, where users can stay connected for a long time, and, of course, they would like to play the content without interruptions.

A high quality streaming service should always keep the rate of rebuffering below 0.5%, discarding the initial buffer, at normal bandwidth availability. Moreover, this parameter can be very useful to identify network bottlenecks at content distribution process.

Another key parameters are the average frame rate and the rate of frame loss. These two parameters give us an overview of the capacity, of the server to stream the video content, and, of the users to receive and decode the stream. In case of server overloading , one of the first alternatives used to maintain a continuous experience is to reduce the frame rate, or basically, drop frames. These parameters usually indicate that either the server is not able to serve the content, or, the clients do not have the minimum conditions to receive and decode the video. These problems are usually associated with intensive CPU usage, due an excess of clients in the server side, or by lack of resources for decoding the video on the client.

For Flash Media Server specifically, some parameters related with memory usage for input and output buffer, size of buckets, and use of aggregated messages, can influence directly in the video frame rate, but in this case, we can detect the problem even with a small amount of users.

Finally, we have some parameters, not least importants, to complement the set of basic checkpoints to ensure the quality of streaming video service, including, the time to establish the connection, the rate of reconnection, the sync between audio and video, and psnr between the video decoded by the user and the video that comes out of encoder (since the loss of packets may influence the reconstruction of the frames, especially for temporal video compression). Measuring and evaluating all these parameters we can identify with much more efficiency any problem that might compromise the quality of service, which is essential for professional media streaming business.

[Rafael Silva Pereira] Stream Multiplexing for FME Failover in Flash Media Server

Thursday, October 16th, 2008

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

[Rafael Silva Pereira] Stream Multiplexing for FME Failover in Flash Media Server

Thursday, October 16th, 2008

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

[Rafael Silva Pereira] Globo Vídeos para iPhone

Thursday, September 25th, 2008

A Globo.com lançou hoje, oficialmente, seu portal de vídeos para iPhone: http://m.video.globo.com. Agora é possível ver os vídeos da Globo.com de qualquer celular que suporte vídeos H.264!!!

Globo Videos para iPhone

Globo Vídeos para iPhone

Foi desenvolvida do zero uma nova versão do site, otimizada para iPhone e iPod Touch, com os já conhecidos efeitos de transição. Todo este trabalho foi realizado em pouco mais de um mês, desde a criação até o desenvolvimento, passando pelo setup da infra-estrututra de distribuição, estudos e pesquisas para otimizar a qualidade dos vídeos, implementação, etc, e isto só foi possível devido à utilização de metodologias ágeis, que definitivamente mudaram a forma como trabalhamos aqui, o que sem dúvida nenhuma permite uma resposta mais eficiente às demandas do mercado de internet.

Além de ver os vídeos no site, é possível reproduzir todos os vídeos do portal, mesmo aqueles que estão embedded em matérias, como os que encontramos no G1 e Globoesporte.com

Com relação à qualidade dos vídeos, posso dizer que conseguimos uma otimização bem legal, onde temos um vídeo de ótima qualidade (33dB) para o bitrate que escolhemos, que é limitado ao throughput máximo das redes 3G.

Video da Globo.com no iPhone

Vídeo da Globo.com no iPhone / iPod Touch

Mais uma vez conseguimos entregar um produto inovador, de qualidade, o que prova que estamos no caminho certo. Parabéns galera!!!

[Rafael Silva Pereira] Globo Vídeos para iPhone

Thursday, September 25th, 2008

A Globo.com lançou hoje, oficialmente, seu portal de vídeos para iPhone: http://m.video.globo.com. Agora é possível ver os vídeos da Globo.com de qualquer celular que suporte vídeos H.264!!!

Globo Videos para iPhone

Globo Vídeos para iPhone

Foi desenvolvida do zero uma nova versão do site, otimizada para iPhone e iPod Touch, com os já conhecidos efeitos de transição. Todo este trabalho foi realizado em pouco mais de um mês, desde a criação até o desenvolvimento, passando pelo setup da infra-estrututra de distribuição, estudos e pesquisas para otimizar a qualidade dos vídeos, implementação, etc, e isto só foi possível devido à utilização de metodologias ágeis, que definitivamente mudaram a forma como trabalhamos aqui, o que sem dúvida nenhuma permite uma resposta mais eficiente às demandas do mercado de internet.

Além de ver os vídeos no site, é possível reproduzir todos os vídeos do portal, mesmo aqueles que estão embedded em matérias, como os que encontramos no G1 e Globoesporte.com

Com relação à qualidade dos vídeos, posso dizer que conseguimos uma otimização bem legal, onde temos um vídeo de ótima qualidade (33dB) para o bitrate que escolhemos, que é limitado ao throughput máximo das redes 3G.

Video da Globo.com no iPhone

Vídeo da Globo.com no iPhone / iPod Touch

Mais uma vez conseguimos entregar um produto inovador, de qualidade, o que prova que estamos no caminho certo. Parabéns galera!!!

[Rafael Silva Pereira] Otimizando um Servidor Web para Download Progressivo

Thursday, September 18th, 2008

No dia 27 do mês passado estive no Congresso SET, da Sociedade Brasileira de Engenharia de Televisão e Telecomunicações, onde apresentei junto com o Marcello Azambuja um artigo sobre Arquiteturas de Distribuição de Vídeos na Internet. Porém, devido ao tempo bastante limitado da apresentação, não pude entrar em detalhes mais específicos de como otimizar as arquiteturas para obter um melhor desempenho. Por isso, resolvi colocar um pouco do que está no artigo aqui no blog, já que nem todo mundo que tem interesse neste assunto estava na apresentação. (O slides podem ser vistos aqui)

Assim, resolvi começar falando especificamente sobre o Download Progressivo, ou seja, como podemos otimizar um Web Server para que ele seja capaz de servir a maior quantidade de usuários possível. No caso de distribuição de vídeos via Progressive Download temos algumas características básicas que devem ser consideradas para otimização:

  • As conexões com o WebServer são persistentes, ou seja, o usuário fica conectado ao servidor por uma quantidade razoável de tempo, até que o conteúdo seja completamente copiado;
  • Dependendo da quantidade de vídeos diferentes podemos ter diversos conteúdos diferentes sendo acessados simultaneamente;
  • Os arquivos de mídia não estão necessariamente nos discos do servidor. Eles podem estar em um repositório central sendo acessados pelo servidor Web através de NFS/CIFS;
  • A quantidade de acessos ao serviço pode aumentar rapidamente, variando de acordo com o conteúdo disponibilizado;

Com estas características já podemos identificar alguns gargalos principais:

  • Tráfego de rede: muitos usuários conectados realizando download irão rapidamente ocupar a banda disponível. Além disso, existe a ocupação de banda pela cópia dos arquivos do repositório central para o servidor;
  • IO (Repositório Central e Disco Local): muitos usuários realizando download significa muito IO de leitura, que é maior a medida que temos mais usuários acessando arquivos diferentes;
  • Memória: quanto mais usuários, mais memória o Apache irá precisar para atendê-los, e quanto mais arquivos, mais memória o kernel irá utilizar para cache;
  • CPU: quanto mais usuários mais processamento para organizar e servir as requisições;

Na verdade, se queremos obter o máximo de uma arquitetura não podemos nos limitar a olhar apenas um componente. O primeiro ponto, e mais simples, consiste em alterar as configurações do Apache, escolher a versão correta (2.X), e compilar uma versão do Web Server que tenha apenas aquilo que é relevante para a distribuição de arquivos, ou seja, devemos evitar incluir na configuração de compilação módulos que não serão utilizados, como mod ssl, por exemplo.

Uma vez compilado cabe a nós decidir qual arquitetura interna de funcionamento possui uma performance maior: se é a multi-process (Apache Prefork) ou a multi-process/multi-thread (Apache Worker).

Basicamente, no prefork, para cada conexão será criado um processo específico para atendê-la, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados para atender as conexões, sendo que a medida que os clientes se conectam, eles são atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de performance:

  • Memória: cada processo criado ocupa uma porção da memória, de modo que a memória disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
  • Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas conexões;

A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma área de memória do processo pai, e reduzimos o overhead na criação de processos. Na verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só realizamos um fork quando este limite é atingido.

A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra. No caso específico de servidores para utilização em distribuição de vídeos em Progressive Download, a escolha do MPM Worker é recomendada, com o objetivo de reduzir a ocupação de memória pelo servidor Web, deixando-a livre para que o kernel possa utilizá-la para cache de conteúdo, reduzindo o IO no disco e conseqüentemente o tempo de resposta da requisição. Uma configuração interessante seria neste caso seria forçar a criação de todos os processos filho (children) e suas threads no momento que o servidor Web for iniciado, reduzindo assim o overhead de controle de threads.

Além de configurar o MPM, o Apache permite diversas outras configurações capazes de aumentar o desempenho do mesmo, como a possibilidade de desabilitar Hostname Lookups e DNS resolving, e outras que podem ser encontradas na documentação do Apache.

Entretanto, quando falamos de arquiteturas de distribuição de vídeo que recebem grandes volumes de acesso, devemos nos preocupar um pouco mais em como otimizar o processo de distribuição. Uma das maneiras mais eficientes de aumentar a capacidade de uma infra-estrutura de Download Progressivo consiste em realizar um processo de cache intensivo. Ter uma estratégia de cache de conteúdo é fundamental quando falamos de alta performance com um grande volume de acessos. Quando temos um volume muito grande, temos também diversos requests ao mesmo conteúdo. Processar todo o request para cada cliente consistiria em repetir as mesmas operações diversas vezes, sem aproveitar para um request os dados processados por outro. Assim, fica claro que podemos otimizar este processamento, simplesmente aproveitando aquilo que serve para mais de uma requisição.

Em situações onde temos uma arquitetura onde o Apache funciona como uma espécie de “proxy” entre o usuário e um repositório central de vídeos, essa necessidade é ainda mais latente, uma vez que não faz sentido obter um mesmo arquivo diversas vezes neste repositório para servir para os clientes a cada request semelhante. Uma vez copiado do storage para o Apache, para servir uma requisição, o arquivo pode ser mantido no servidor Web para as requisições posteriores realizadas ao mesmo vídeo. Com essa abordagem, reduzimos a carga no storage e o tráfego de rede e de operações de cópia.

Para realizar o cache de conteúdo existem diversas alternativas, como o Squid e o mod_cache. O mod_cache, por estar integrado ao Apache e por ser bastante conhecido e utilizado, além de apresentar uma ótima performance, é uma excelente opção para cache em arquiteturas de distribuição em Download Progressivo.

O mod_cache permite duas abordagens principais de cache: disco ou memória. O mod_disk_cache é o módulo responsável pelo cache em disco, e funciona da seguinte forma: ao receber um request, o mod_disk_cache verifica se o conteúdo solicitado já está no cache em disco. Se estiver, o módulo valida se o conteúdo não está expirado e serve o mesmo a partir do cache, sem que a requisição seja passada aos demais módulos do Apache. Caso, não esteja cacheado, o request passa pelo path normal de atendimento ao request, sendo que, ao finalizar o processamento, o mod_cache escreve a resposta no cache antes de servir a mesma. Assim, ele cria dois arquivos em disco: o .data, com o conteúdo do request, e o .header com os headers da resposta. O nome dos arquivos criados é criado a partir de um hash, para evitar que o conteúdo seja sobre-escrito.

O mod_mem_cache, é o módulo responsável pelo cache em memória, e funciona de forma semelhante ao mod_disk_cache, porém armazenando o conteúdo em memória.

A escolha de um dos módulos para utilização em um servidor de Download Progressivo também depende da configuração do hardware. Entretanto, em servidores que rodam em Linux, o uso do mod_disk_cache é recomendada, uma vez que o gerenciamento do cache em memória feito pelo kernel é bastante eficiente.

Com um web server bem otimizado e configurado, e com uma estratégia de cache eficiente, temos uma arquitetura de distribuição muito mais robusta e capaz de atender um volume até 70% maior que o volume que atenderíamos utilizando apenas um servidor com as configurações “default”, o que reduz de forma significativa os custos de investimento para expansão da capacidade, tornando esta uma opção bastante interessante para distribuição de vídeos na internet.

[Rafael Silva Pereira] Otimizando um Servidor Web para Download Progressivo

Thursday, September 18th, 2008

No dia 27 do mês passado estive no Congresso SET, da Sociedade Brasileira de Engenharia de Televisão e Telecomunicações, onde apresentei junto com o Marcello Azambuja um artigo sobre Arquiteturas de Distribuição de Vídeos na Internet. Porém, devido ao tempo bastante limitado da apresentação, não pude entrar em detalhes mais específicos de como otimizar as arquiteturas para obter um melhor desempenho. Por isso, resolvi colocar um pouco do que está no artigo aqui no blog, já que nem todo mundo que tem interesse neste assunto estava na apresentação. (O slides podem ser vistos aqui)

Assim, resolvi começar falando especificamente sobre o Download Progressivo, ou seja, como podemos otimizar um Web Server para que ele seja capaz de servir a maior quantidade de usuários possível. No caso de distribuição de vídeos via Progressive Download temos algumas características básicas que devem ser consideradas para otimização:

  • As conexões com o WebServer são persistentes, ou seja, o usuário fica conectado ao servidor por uma quantidade razoável de tempo, até que o conteúdo seja completamente copiado;
  • Dependendo da quantidade de vídeos diferentes podemos ter diversos conteúdos diferentes sendo acessados simultaneamente;
  • Os arquivos de mídia não estão necessariamente nos discos do servidor. Eles podem estar em um repositório central sendo acessados pelo servidor Web através de NFS/CIFS;
  • A quantidade de acessos ao serviço pode aumentar rapidamente, variando de acordo com o conteúdo disponibilizado;

Com estas características já podemos identificar alguns gargalos principais:

  • Tráfego de rede: muitos usuários conectados realizando download irão rapidamente ocupar a banda disponível. Além disso, existe a ocupação de banda pela cópia dos arquivos do repositório central para o servidor;
  • IO (Repositório Central e Disco Local): muitos usuários realizando download significa muito IO de leitura, que é maior a medida que temos mais usuários acessando arquivos diferentes;
  • Memória: quanto mais usuários, mais memória o Apache irá precisar para atendê-los, e quanto mais arquivos, mais memória o kernel irá utilizar para cache;
  • CPU: quanto mais usuários mais processamento para organizar e servir as requisições;

Na verdade, se queremos obter o máximo de uma arquitetura não podemos nos limitar a olhar apenas um componente. O primeiro ponto, e mais simples, consiste em alterar as configurações do Apache, escolher a versão correta (2.X), e compilar uma versão do Web Server que tenha apenas aquilo que é relevante para a distribuição de arquivos, ou seja, devemos evitar incluir na configuração de compilação módulos que não serão utilizados, como mod ssl, por exemplo.

Uma vez compilado cabe a nós decidir qual arquitetura interna de funcionamento possui uma performance maior: se é a multi-process (Apache Prefork) ou a multi-process/multi-thread (Apache Worker).

Basicamente, no prefork, para cada conexão será criado um processo específico para atendê-la, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados para atender as conexões, sendo que a medida que os clientes se conectam, eles são atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de performance:

  • Memória: cada processo criado ocupa uma porção da memória, de modo que a memória disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
  • Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas conexões;

A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma área de memória do processo pai, e reduzimos o overhead na criação de processos. Na verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só realizamos um fork quando este limite é atingido.

A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra. No caso específico de servidores para utilização em distribuição de vídeos em Progressive Download, a escolha do MPM Worker é recomendada, com o objetivo de reduzir a ocupação de memória pelo servidor Web, deixando-a livre para que o kernel possa utilizá-la para cache de conteúdo, reduzindo o IO no disco e conseqüentemente o tempo de resposta da requisição. Uma configuração interessante seria neste caso seria forçar a criação de todos os processos filho (children) e suas threads no momento que o servidor Web for iniciado, reduzindo assim o overhead de controle de threads.

Além de configurar o MPM, o Apache permite diversas outras configurações capazes de aumentar o desempenho do mesmo, como a possibilidade de desabilitar Hostname Lookups e DNS resolving, e outras que podem ser encontradas na documentação do Apache.

Entretanto, quando falamos de arquiteturas de distribuição de vídeo que recebem grandes volumes de acesso, devemos nos preocupar um pouco mais em como otimizar o processo de distribuição. Uma das maneiras mais eficientes de aumentar a capacidade de uma infra-estrutura de Download Progressivo consiste em realizar um processo de cache intensivo. Ter uma estratégia de cache de conteúdo é fundamental quando falamos de alta performance com um grande volume de acessos. Quando temos um volume muito grande, temos também diversos requests ao mesmo conteúdo. Processar todo o request para cada cliente consistiria em repetir as mesmas operações diversas vezes, sem aproveitar para um request os dados processados por outro. Assim, fica claro que podemos otimizar este processamento, simplesmente aproveitando aquilo que serve para mais de uma requisição.

Em situações onde temos uma arquitetura onde o Apache funciona como uma espécie de “proxy” entre o usuário e um repositório central de vídeos, essa necessidade é ainda mais latente, uma vez que não faz sentido obter um mesmo arquivo diversas vezes neste repositório para servir para os clientes a cada request semelhante. Uma vez copiado do storage para o Apache, para servir uma requisição, o arquivo pode ser mantido no servidor Web para as requisições posteriores realizadas ao mesmo vídeo. Com essa abordagem, reduzimos a carga no storage e o tráfego de rede e de operações de cópia.

Para realizar o cache de conteúdo existem diversas alternativas, como o Squid e o mod_cache. O mod_cache, por estar integrado ao Apache e por ser bastante conhecido e utilizado, além de apresentar uma ótima performance, é uma excelente opção para cache em arquiteturas de distribuição em Download Progressivo.

O mod_cache permite duas abordagens principais de cache: disco ou memória. O mod_disk_cache é o módulo responsável pelo cache em disco, e funciona da seguinte forma: ao receber um request, o mod_disk_cache verifica se o conteúdo solicitado já está no cache em disco. Se estiver, o módulo valida se o conteúdo não está expirado e serve o mesmo a partir do cache, sem que a requisição seja passada aos demais módulos do Apache. Caso, não esteja cacheado, o request passa pelo path normal de atendimento ao request, sendo que, ao finalizar o processamento, o mod_cache escreve a resposta no cache antes de servir a mesma. Assim, ele cria dois arquivos em disco: o .data, com o conteúdo do request, e o .header com os headers da resposta. O nome dos arquivos criados é criado a partir de um hash, para evitar que o conteúdo seja sobre-escrito.

O mod_mem_cache, é o módulo responsável pelo cache em memória, e funciona de forma semelhante ao mod_disk_cache, porém armazenando o conteúdo em memória.

A escolha de um dos módulos para utilização em um servidor de Download Progressivo também depende da configuração do hardware. Entretanto, em servidores que rodam em Linux, o uso do mod_disk_cache é recomendada, uma vez que o gerenciamento do cache em memória feito pelo kernel é bastante eficiente.

Com um web server bem otimizado e configurado, e com uma estratégia de cache eficiente, temos uma arquitetura de distribuição muito mais robusta e capaz de atender um volume até 70% maior que o volume que atenderíamos utilizando apenas um servidor com as configurações “default”, o que reduz de forma significativa os custos de investimento para expansão da capacidade, tornando esta uma opção bastante interessante para distribuição de vídeos na internet.