ssxrver

ssxrver

     _______.     _______.___   ___ .______     ____    ____  _______ .______      
    /       |    /       |   /  / |   _           /   / |   ____||   _       
   |   (----`   |   (----`   V  /  |  |_)  |       /   /  |  |__   |  |_)  |    
                        >   <   |      /            /   |   __|  |      /     
.----)   |   .----)   |    /  .    |  |  ----.      /    |  |____ |  |  ----.
|_______/    |_______/    /__/ __ | _| `._____|   __/     |_______|| _| `._____|

O SSXRVER é uma biblioteca de rede de alto desempenho e alta concorrência em execução na plataforma Linux. Está escrito em C ++ 17 e suporta protocolos TCP e UDP.

Vantagens

1. É usado o modelo otimizado de um loop por thread + pista de rosca de bloqueio de grão fina.
2. Alto desempenho e alta simultaneidade, os dados de medição de pressão são maiores que o Nginx/1.14.2 e o Apache/2.4.28
3. O thread principal executa apenas as operações aceitadas para distribuir eventos através do EventFD para evitar a concorrência de bloqueios e threads de IO lê e grava dados.
4. De acordo com a análise em diferentes cenários, diferentes métodos de multiplexação do epoll são usados ​​para melhorar o desempenho.
5. Use o mecanismo RAII para controlar o ciclo de vida do objeto e todas as operações de alocação de memória usam ponteiros inteligentes para evitar vazamentos de memória.
6. Use o TimerFD fornecido pelo kernel Linux para lidar com eventos cronometrados e tempo de IO uniformemente e implementar o gerenciamento do timer através das bibliotecas padrão C ++ 11 STD :: Chrono e STD :: Priority_queue para implementar tarefas de tempo de nível de nanossegundos.
7. Use soquetes não bloqueadores para impedir que os threads sejam bloqueados por uma única conexão.
8. Encapular o módulo HTTP e um servidor HTTP de alto desempenho pode ser configurado com operações simples, usando RAGEL (Machine de Estado Finito) para analisar solicitações HTTP, ajustar a eficiência, suportar solicitações de GET e postagem para HTTP/1.0 e HTTP/1.1 e apoiar as conexões longas.
9. Encapsular classes de buffer de alto desempenho para transmissão e recepção de dados.
10. O envio de arquivos usa a tecnologia de cópia Zero SendFile para melhorar o desempenho do envio de arquivos.
11. Encapsular o módulo de operação do banco de dados, que pode simplesmente analisar e gerar instruções SQL correspondentes ao banco de dados MySQL e pode implementar o pool de conexão com o banco de dados com piscina de rosca de bloqueio de grão fino.
12. Implementar a biblioteca de log assíncrona de vários buffos, suportando a configuração dos níveis de log, tamanho de rolagem de log e outras funções.
13. Use novos recursos de C ++ 11 14 17 Sintaxe para melhorar o desempenho, como std :: make_shared, std :: make_unique, std: string_view, explícito, [[nodiscard]], emplace_back, etc.
14. Use o estilo de código de estilo unificado e as especificações de nomeação e adicione mais de 10 parâmetros de compilação para padronizar a implementação do código, melhorando a qualidade do código e as possibilidades de otimização do compilador.
15. Vários designs são usados ​​para reutilizar objetos para reduzir a aplicação frequente de determinados objetos para liberação.
16. Usando idéias de programação baseada em objetos, a estrutura do código do projeto é clara e clara, e as funções frequentemente chamadas entre si devem ser reunidas o máximo possível, aumentando a taxa de acertos de cache da CPU, um acoplamento frouxo entre os módulos, facilitando a adição de novos módulos funcionais.
17. Use o modo singleton, modo de política, modo adaptador e outro modo de design para reduzir a redundância do código e tornar a implementação do código mais elegante.
18. Encapsula o módulo de arquivo de configuração e use o formato JSON para configurá -lo rapidamente.
19. A afinidade da CPU pode ser configurada por meio de arquivos de configuração, reduzindo assim o número de tempos de troca de contexto de encadeamento direto e melhorando o desempenho.
20. Suporta o protocolo UDP.

Ambiente de Desenvolvimento

• Penteado do sistema operacional Versão: Deepin V20.1 Versão da comunidade (1030)
• Versão do kernel: 5.4.70-AMD64-DESKTOP (64 bits)
• Versão do compilador: GCC 8.3
• Idioma: C ++ 17
• Versão cmake: 3.11.2
• Versão da biblioteca Boost: 1.72
• Versão do banco de dados: MySQL 5.7.21-1

Como correr

1. Por favor, tente combinar o mesmo ambiente de desenvolvimento que eu. Se você não precisar de um módulo de banco de dados, modifique cmakelists.txt de acordo.

   • Instalação do CMake

      # debian/ubuntu
     sudo apt-get install cmake

   • Boost Library Instalação

     wget http://sourceforge.net/projects/boost/files/boost/1.72.0/boost_1_72_0.tar.bz2
     tar -xvf boost_1_72_0.tar.bz2
     cd ./boost_1_72_0
     ./bootstrap.sh --prefix=/usr/local
     sudo ./b2 install --with=all

2. Run ./build.sh No diretório SSXRVER, você pode modificar o Build.sh para optar por gerar a versão de depuração ou a versão de lançamento (a versão de versão padrão)

   ./build.sh

3. O compilado gerará com sucesso o diretório de compilação/ o arquivo executável está no diretório de versão correspondente. Por exemplo, quando você seleciona a versão de liberação, o arquivo executável está em/build/release/ssxrver.

4. Imite o formato de conf/ssxrver.json.example para criar seu arquivo de configuração (observe que o arquivo de configuração não pode ser comentado, não comentado, não comentado). Vou explicar as opções de cada arquivo de configuração abaixo. Na verdade, eu defino os valores padrão para muitos parâmetros. Se não estiver configurado, isso não o afetará.

   {
     " port " : 4507, # 端口号,不填的话默认4507
     " address " : " 127.0.0.1 " , # 绑定的地址
     " worker_processes " : 4, # IO 线程数量,不填默认为 4 个
     " worker_connections " : -1, # 一个 IO 线程最多支持多少连接, -1 表示最多能创建多少就创建多少,不做限制
     " task_processes " : 0, # 任务线程,不填的话默认为 0 
     " cpu_affinity " : " off " , # cpu 亲和度 ,默认关闭
     " http " : { # http 模块
       " max_body_size " : 67108864, # 单个 http 包最大支持大小
       " root_path " : " /home/randylambert/sunshouxun/ssxrver/html/ " # 文件访问根路径
     },
     " log " : { # log 模块
       " level " : " INFO " , # 输出等级,可填三种等级, DEBUG,INFO,WARN 不填默认为 INFO 等级
       " ansync_started " : " off " , # 是否打开异步日志线程,不填默认关闭
       " flush_second " : 3, # 异步线程每隔多久持久化一次
       " roll_size " : 67108864, # 日志文件滚动大小
       " path " : " /home/randylambert/sunshouxun/ssxrver/logs/ " , # 日志文件存放路径
       " base_name " : " ssxrver " # 日志文件基础名
     },
     " mysql " : { # 数据库模块
       " mysql_started " : " off " , # 是否打开数据库模块,默认关闭
       " address " : " 127.0.0.1 " , # 以下是对应数据库连接信息
       " user " : " root " ,
       " password " : " 123456 " ,
       " database_name " : " ttms " ,
       " port " : 0,
       " unix_socket " : null,
       " client_flag " : 0
     },
     " blocks_ip " : [ " 122.0.0.2 " , " 198.1.2.33 " ] # 可屏蔽部分恶意 IP
   }

5. Execute o arquivo executável.

./ssxrver -f /配置文件的路径
# 例如
./build/Release/ssxrver -f ./conf/ssxrver.json

Teste de pressão

Ambiente de teste	Valor
Versão de penteado do sistema operacional	Edição Comunitária Deepin V20.1 (1030)
Versão do kernel	5.4.70-AMD64-DESKTOP (64 bits)
Versão do compilador	GCC 8.3
Versão da biblioteca Boost	1.72
processador	Intel (R) Core (TM) I7-8750H CPU @2.20GHz
Tamanho do cache L1	32k
Tamanho do cache L2	256k
Tamanho do cache L3	9216k
Velocidade do disco rígido	1,8 DISCURSO MECÂNICO TIB 5400 rpm
Velocidade de leitura e gravação em disco rígido	370 MB em 3,03 segundos = 122,27 Mb/s
Memória	7.6 GB
Partição de troca	4,7 GB
Contagem de núcleo lógico	12 núcleos

Cenário de teste

1. Para controlar as variáveis, reinicie o computador antes de testar para garantir que o ambiente de teste não tenha outros aplicativos com alta carga de CPU e alta carga de IO.

2. A ferramenta de teste é webbench1.5. Remova os primeiros dados de aquecimento. O comando de teste é o seguinte (100 clientes foram acessados ​​continuamente por 15 segundos).

   ./webbench -c 100 -t 15 http://127.0.0.1:8081/

3. Os objetos de teste são Apache/2.4.38, nginx/1.14.2, ssxrver.

   • Apache/2.4.38 adota configuração padrão
   • NGINX/1.14.2 Feche a impressão de log, abra 4 processos de trabalhadores, abre o Sendfile e as configurações padrão do REST.
   • O nível de log do SSXRVER é definido como informações, abra o thread de log assíncrono e abra 4 threads IO.

Nota: Seja usando o Webbench ou AB, os dados medidos por essa ferramenta de medição de pressão só podem ser usados ​​como uma referência simples. A medição de pressão é um teste que requer total e multi-ângulo, em vez de simplesmente executar um comando. Mesmo durante a medição da pressão, os dados não são transmitidos pela rede, mas apenas circula no kernel.

Resultados do teste

Biblioteca de rede	Velocidade (páginas/min)	Solicita taxa de sucesso
SSXRVER retorna a resposta gerada na memória	7107414	100%
SSXRVER Retorna arquivos estáticos	5114376	100%
Apache/2.4.28	2884072	100%
nginx/1.14.2	4728748	100%

• SSXRVER retorna a resposta gerada na memória
• SSXRVER Retorna arquivos estáticos
• Apache/2.4.28
• nginx/1.14.2

Os resultados do teste do SSXRVER são muito bons, mas estranhamente, eu pensei que os dados seriam mais altos, porque quando eu estava desenvolvendo nos primeiros dias, não fiz muitas otimizações naquele momento. Quando devolvi a resposta gerada diretamente na memória, ela foi medida no máximo 8000000 páginas/min (os resultados do teste de 8000000 páginas/min não foram tirados em capturas de tela, deixando um 7550778). Naquela época, o Nginx/1.14.2 tinha no máximo 5000000 páginas/min. No entanto, não importa se era ssxrver ou nginx/1.14.2, não consegui encontrar um valor tão alto. Não sei qual foi o motivo, o que levou a uma lacuna tão grande no resultado final (é porque meu computador está envelhecendo? ￣ □ ￣｜｜)

Sobre trade-offs

1. Quando eu estava escrevendo pools de threads, hesitei por muito tempo se usava piscinas de linha sem trava ou piscinas de rosca de bloqueio de grão fino. No final, escolhi a piscina de rosca de bloqueio de grão fino. Embora o pool de threads sem bloqueio insira o estado do kernel menos em cenários de alta concorrência e geralmente tenha um desempenho mais alto, ele consumirá recursos da CPU em vão quando o número de tarefas for pequeno. Para garantir a universalidade do SSXRVER em qualquer cenário, escolhi o pool de roscas de bloqueio de grão fino.
2. Ao implementar a função do timer, o melhor desempenho da minha tarefa deve ser o temporizador implementado usando uma roda de tempo de grão fino. A granularidade do tempo é fácil de configurar, e a complexidade do tempo de adicionar e obter tarefas de tempo é próxima de O (1). No entanto, no cenário da biblioteca de rede, achei difícil controlar a roda do tempo para rolar para a frente de acordo com uma unidade de tempo fixo e dormir por um tempo com sono? Isso bloqueará diretamente os eventos normais de IO. Usando sinais? Na programação multithread, o processamento de sinal é muito difícil e não há vantagem no desempenho, o que não vale a pena. Use epoll_wait () para definir o tempo limite? Sempre que um evento legível é acionado, um novo horário de tempo limite deve ser modificado. Se o tempo de processamento for muito longo, o tempo da unidade será excedido, a precisão será reduzida. Abrir diretamente um thread de timer separado é responsável apenas pela tarefa de tempo? Isso pode resolver perfeitamente o problema acima. O thread do timer é responsável apenas por adicionar e acionar a tarefa de tempo correspondente e, após o acionamento, a tarefa é passada para o IO após o acionamento. The execution of threads or calculation threads will not cause the accuracy to decrease, but I feel that it is not necessary to do so, so I simply hand over the timing tasks to kernel management, using the combination of priority queue + timefd, which ensures good time complexity (O(log(n))), timefd ensures extremely high accuracy, and can also handle timing tasks and IO time together. Embora eu não tenha implementado o timer usando a roda do tempo, a idéia de roda do tempo está realmente em uso. Por exemplo, em alguns cenários, o TCP Keepalive não pode atender aos nossos requisitos de desconexão de conexões longas ociosas. Se queremos implementar o modo de uso de usuário mantido, precisamos criar uma tarefa de tempo para cada conexão, para iniciar a conexão longa ociosa que não foi comunicada há muito tempo ou criar uma tarefa de tempo, percorrer todo o pool de conexão cada vez que você pode usar uma lista de conexões, para que não seja necessário trocar o pool de conexão) para determinar se determina se a conexão com a necessidade de conexão. No entanto, nenhum desses métodos é elegante o suficiente. Neste momento, podemos emprestar a idéia da roda do tempo e colocar a conexão no slot da roleta. Ao definir a tarefa de tempo, controlamos a roda de tempo para rolar para a frente. Cada etapa de rolagem será processada. Dessa forma, não percorreremos todas as conexões todas as vezes e haverá muitas tarefas de tempo.

Sobre o futuro

1. Atualmente, pessoalmente modificarei o módulo de buffer e o módulo de log do SSXRVER, se eu tiver tempo.

   • Primeiro de tudo, a maneira mais fácil de modificar o módulo de buffer é alterá-lo para um tampão cíclico, reduzindo assim efetivamente o número de vezes que o buffer move os dados para a frente ou abandonando diretamente essa implementação do buffer e reimplementando um buffer de alto desempenho.

   • Em segundo lugar, o módulo de log atual é escrito na forma de fluxo de C ++. Embora seja definitivamente mais alto em desempenho do que usar C ++ diretamente com o iostam, a sobrecarga do log no formulário << simbólico ainda causará controle inconveniente de formato e problemas de desempenho causados ​​por cadeias de chamadas de função. Ambos os problemas podem ser resolvidos implementando o log na forma de printf.

2. Por razões de tempo, o SSXRVER não implementa o módulo de gerenciamento de memória, por isso é quase impossível escrever um módulo geral de gerenciamento de memória de alto desempenho (é melhor ir diretamente para Jemalloc ou TCMalloc). No entanto, analisando o cenário da biblioteca de rede, ainda é uma pequena chance de escrever um módulo de gerenciamento de memória com maior desempenho nesse cenário. Se eu tiver tempo, vou dar uma olhada na implementação no NGINX e aprender.

3. Quando eu estava consultando as informações, cheguei à conclusão de que, no C ++ 17, você pode usar o std :: string_view para substituir a const String &, o que melhorará alguma eficiência. Portanto, tentei substituir todos os lugares onde a String const & no meu projeto com STD :: String_View. No entanto, quando finalmente usei perf -top para visualizar a carga alterada, descobri inesperadamente que algumas funções realmente aumentaram depois de usar o std :: string_view para substituí -lo. Fiquei muito confuso por que essa situação ocorreu. Por razões de tempo, não investigarei a causa específica desse problema por enquanto. Tenho a oportunidade de verificar a implementação subjacente para verificar o motivo específico.

• Antes da substituição
• Após a substituição

4. Ao implementar o módulo HTTP Parsing, usei uma máquina de estado manuscrita que corresponda diretamente a strings na primeira versão. Então eu o substituí pela máquina de estado implementada por Ragel. No entanto, durante testes recentes, descobri que a carga da função de análise HTTP é muito exagerada, atingindo 10%. Será que o uso de ragel causou degradação do desempenho? (Se a análise do cabeçalho causará uma carga tão alta do sistema, parece que o HTTP/2.0 ainda melhorará significativamente o desempenho), infelizmente, quando eu escrevi a máquina de estado antes, não testei a carga da função de análise correspondente. Agora, não consigo obter a comparação de dados entre os dois de uma só vez e tenho a oportunidade de escrever um teste de referência.

5. O SSXRVER suporta transmissão UDP simples, mas eu pessoalmente acho que uma estrutura UDP sem controle de congestionamento, controle de tráfego e funções de retransmissão por perda de pacotes pode ser basicamente que não possa ser usada normalmente. No futuro, tenho tempo para aprender protocolos QIC e KCP. Vou complementar o conhecimento relacionado à UDP. Acredito que o protocolo UDP mais eficiente e flexível será cada vez mais amplamente utilizado no futuro!

Sobre a estrutura

Na verdade, eu realmente acho que a melhor estrutura de rede atualmente deve ser que a multiplexação por endereço de portas multiplexação e vários threads (multiprocess) ligue o mesmo endereço e porta, e o kernel executa automaticamente o balanceamento de carga. Ao mesmo tempo, o sistema Blocks chama através da Coroutine Framework + Hook. Depois de usar essa estrutura, ele pode garantir alto desempenho sem usar o thread principal para distribuir conexões e não há necessidade de cair no inferno de retorno de chamada assíncrono.

Além disso, se você puder usar o mecanismo de IO assíncrono io_uring adicionado após o Linux Kernel 5.1, acredito que o desempenho do servidor será maior. No entanto, não sei muito sobre io_uring atualmente e não tenho a capacidade de projetar uma biblioteca de rede de IO assíncrona com base em io_uring.