Каковы проблемы, о которых можно знать при написании высокопроизводительного кода GRPC?C#

Место общения программистов C#
Ответить
Anonymous
 Каковы проблемы, о которых можно знать при написании высокопроизводительного кода GRPC?

Сообщение Anonymous »

Я автор Autocser и слышал, что GRPC является высокопроизводительным компонентом RPC, но я обнаружил, что Autocser RPC в этом тесте превышал. Производительность теста параллелистики GRPC в 30 раз через простое сравнение теста паралита.
Тест, который я сделал, состоял в том, чтобы запустить 8K -задачи и выполнить 67,108 864 простых операций расчета добавления одновременно и, наконец, рассчитать результат TPS. Поскольку тест.net GRPC занял слишком много времени, он был изменен, чтобы завершить 1 048 576 операций. Например, веб -сервис с более чем 8 тысячами одновременными запросами может иметь более 8 тыс. Одновременного давления запроса на услуги Business RPC. Этот одновременный тест заключается в моделировании такого реального сценария параллелизма борьбы. Тестовый код, который я написал, не соответствует лучшим практикам. Поэтому я хочу знать, что искать в in.net grpc параллельное тестирование производительности? Параметры и методы на стороне сервера, вторая - создать параметры и методы клиентской стороны, а третьим является использование клиента (например, использовать режим Singleton). < /p>
После моего тестирования и обсуждения с некоторыми китайскими пользователями сети я наконец -то сформировал текущую версию тестового кода, но тестовый эффект не идеален. < /p>
Цель моей Вопрос заключается в том, как улучшить код.net GRPC, который я пишу, чтобы код мог проверить лучшие результаты, а не как провести тестирование производительности, результаты тестирования производительности используются только для сравнения различных кода версий. < Br /> Согласно STACKOVERFLOW.com Рецензентам добавлению. NET GRPC Минимальный воспроизводимый пример проектов GRPCServicePerformance и GRPCClientPerformance. < /p>
Содержание тестового определяется следующим образом: < /p>

Код: Выделить всё

syntax = "proto3";

option csharp_namespace = "GrpcServicePerformance";

package greet;

// The greeting service definition.
service Greeter {
rpc Add (AddRequest) returns (AddReply);
}

message AddRequest {
int32 left = 1;
int32 right = 2;
}

message AddReply {
int32 result = 1;
}
< /code>
API сервера определяется следующим образом: < /p>
    public class GreeterService : Greeter.GreeterBase
{
public override Task Add(AddRequest request, ServerCallContext context)
{
return Task.FromResult(new AddReply
{
Result = request.Left + request.Right
});
}
}
Код сервера .NET GRPC создается со ссылкой на выборку, предоставленную Lesnyrumcajs в grpc_bench, которая является основной библиотекой тестирования для GRPC, а конкретный код выглядит следующим образом:

Код: Выделить всё

        public static void Main(string[] args)
{
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
options.AddServerHeader = false;
options.ListenAnyIP(5000, listenOptions =>
{
listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http2;
});
});

builder.Logging.ClearProviders();

builder.Services.AddGrpc(o => o.IgnoreUnknownServices = true);
builder.Services.Configure(c => c.SuppressCheckForUnhandledSecurityMetadata = true);
builder.Services.AddSingleton();

var app = builder.Build();

app.Lifetime.ApplicationStarted.Register(() => Console.WriteLine("Application started."));
app.UseMiddleware();
app.MapGrpcService();

app.Run();
}
< /code>
Промежуточное программное обеспечение на стороне сервера определено следующим образом: < /p>
    public class ServiceProvidersMiddleware
{
private readonly ServiceProvidersFeature _serviceProvidersFeature;
private readonly RequestDelegate _next;

public ServiceProvidersMiddleware(RequestDelegate next, IServiceProvider serviceProvider)
{
_serviceProvidersFeature = new ServiceProvidersFeature(serviceProvider);
_next = next;
}

public Task InvokeAsync(HttpContext context)
{
// Configure request to use application services to avoid creating a request scope
context.Features.Set(_serviceProvidersFeature);
return _next(context);
}

private class ServiceProvidersFeature : Microsoft.AspNetCore.Http.Features.IServiceProvidersFeature
{
public ServiceProvidersFeature(IServiceProvider requestServices)
{
RequestServices = requestServices;
}

public IServiceProvider RequestServices { get; set; }
}
}
< /code>
Прото -файл клиента определяется следующим образом: < /p>
syntax = "proto3";

option csharp_namespace = "GrpcClientPerformance";

package greet;

// The greeting service definition.
service Greeter {
rpc Add (AddRequest) returns (AddReply);
}

message AddRequest {
int32 left = 1;
int32 right = 2;
}

message AddReply {
int32 result = 1;
}
< /code>
После тестирования режим Singleton лучше, поэтому клиент использует режим Singleton, а код тестового тестирования выглядит следующим образом: < /p>
        static async Task Main(string[] args)
{
int maxDegreeOfParallelism = 1 
Тестовая среда.net GRPC-WIN10 + I5-6400 2,70 ГГц. Первоначальный результат теста был 100/мс. После изменения минимального воспроизводимого примера производительность теста несколько снизилась, и результаты следующие: < /p>
.NET gRPC Add API 8192 Concurrent Completed 1048576/11876ms = 88/ms
Код тестового проекта Autocser RPC. При создании CommercilePerverperformance и CommandServerperformance/Client все виды результатов тестирования стратегий планирования потоков следующие:

Код: Выделить всё

AwaiterClient+Server.Queue 8192 Concurrent Completed 67108864/14976ms = 4481/ms
AwaiterClient+Server.Callback 8192 Concurrent Completed 67108864/14744ms = 4551/ms
AwaiterClient+Server.SynchronousCallTask 8192 Concurrent Completed 67108864/14772ms = 4542/ms
AwaiterClient+Server.Task 8192 Concurrent Completed 67108864/21902ms = 3064/ms
AwaiterClient+Server.TaskQueueKey 8192 Concurrent Completed 67108864/18561ms = 3615/ms
AwaiterClient+Server.Synchronous 8192 Concurrent Completed 67108864/16277ms = 4122/ms
AwaiterClient+Server.TaskQueue 8192 Concurrent Completed 67108864/17468ms = 3841/ms

CallbackClient+Server.Queue Loop Completed 67108864/11625ms
CallbackClient+Server.Queue Completed 67108864/11627ms = 5771/ms
CallbackClient+Server.Callback Loop Completed 67108864/11960ms
CallbackClient+Server.Callback Completed 67108864/11961ms = 5610/ms
CallbackClient+Server.SynchronousCallTask Loop Completed 67108864/12121ms
CallbackClient+Server.SynchronousCallTask Completed 67108864/12123ms = 5535/ms
CallbackClient+Server.Task Loop Completed 67108864/15836ms
CallbackClient+Server.Task Completed 67108864/15865ms = 4229/ms
CallbackClient+Server.TaskQueueKey Loop Completed 67108864/15980ms
CallbackClient+Server.TaskQueueKey Completed 67108864/16108ms = 4166/ms
CallbackClient+Server.Synchronous Loop Completed 67108864/12330ms
CallbackClient+Server.Synchronous Completed 67108864/12332ms = 5441/ms
CallbackClient+Server.TaskQueue Loop Completed 67108864/15693ms
CallbackClient+Server.TaskQueue Completed 67108864/15700ms = 4274/ms
Сопоставление с тестированием.net GRPC - это API задачи сервера, включая server.synchronouscalltask и server.task два режима. < /p>
При прохождении теста на сравнение производительности я не хочу, чтобы результаты неудовлетворительных испытаний grpc или garnet + stackexchange.redis были связаны с тестовым кодом, который я написал, поэтому я хочу знать Как их следует записано, чтобы проверить лучшие результаты. < /p>
Например, код Garnet + stackexchange.redis I Первоначально написал, не использовал синглетоны, что привело к разнице порядка между результатами теста В то время и результаты теста сегодня. Но нет проблем без сравнения. Я думаю, что в центре внимания этого вопроса должно быть то, как написать тестовый код, чтобы сделать .NET GRPC или Garnet + stackexChange.redis достичь лучших результатов тестирования.

Подробнее здесь: https://stackoverflow.com/questions/794 ... -grpc-code
Ответить

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

Вернуться в «C#»