I want to load test a web application server which communicates through gRPC (which uses HTTP/2 for transport) with the clients.
It seems that Gatling extended by the plugin Gatling-gRPC would be perfect for this. Among other things Gatling provides a Recorder which helps quickly generate scenarios by acting as a HTTP proxy between the client and the server.
Question 1: Is it possible to use the Gatling Recorder for recording the communication through the gRPC protocol?
Question 2: Is it possible to use the Gatling Recorder for recording the communication through the underlying HTTP/2 protocol?
I have tried already the Gatling Recorder to record the gRPC communication without success :-( Maybe caused by wrong configuration of the recorder?
No, it's not possible to record gRPC with Gatling's recorder atm:
it doesn't support HTTP/2
it doesn't support gatling-grpc which is a third-party plugin work (there's some ongoing work to contribute it upstream)
Related
I have a Python Website and a GRPC service that's going to be written in GO.
I am looking to introduce microservices to the website.
-The GRPC Chat server will be written in GOLANG. The GRPC client would be written in python as my website is python. In future I would like a swift GRPC stub to communicate with this go server as well.
Is this the correct architecture?
My website current GRPC client
chat submit button-> python grpc client-> go grpc server -> DB -> gogrpc server-> pygrpc client->UpdateChat
A request from any languages future mobile GRPC Client
UpdateChatRequest-> Any GRPC Client -> go GRPC server -> DB -> go GRPC Server -> Any GRPC Client->UpdateChat
If you are intending on building multiple what you may call "gRPC Clients" that talk to the Go gRPC server to perform CRUD operations for chat, this looks like a decent model. I will say that nowadays, a lot of gRPC implementations are used for inter-microservice communication more than they are used for your standard (client -> gateway -> micro-service cluster) client-server comms. In my opinion, this is largely due to gRPC-web not being able to fully operate over HTTP/2. Now, I honesty don't see a problem with implementing gRPC on thick clients (like on native mobile or desktop), because the gRPC can be fully supported in those scenarios, just not in the browser yet.
If you are not using gRPC-web on your front end, it might be worth looking in to. gRPC-web requires a proxy anyways, so you're operating over HTTP/1.1 whether you use gRPC or not until browsers support more directly coupling with HTTP/2.
It is a little unclear, but you arch isn't necessarily screaming micro-services. In reality, it is better not to view the "micro-services" concept as an overnight transition that should take place. Your arch is a monolith right now. Using technologies like gRPC doesn't automatically make your architecture a micro-services architecture, but it does better prepare you for the gradual transition you should take to develop your architecture into more of a distributed, service-based model. Of course, the term "micro-service" is often a buzz word with many different scopes of meaning, it is important to know what context you are thinking in.
I have to connect an old but critical software to RabbitMQ. The software doesn't support AMQP, but it can do HTTP Requests.
Does RabbitMQ support plain HTTP? Or should I use a "proxy" or "app" that actively transforms the HTTP Requests to AMQP 1.0 and pushes it to the RabbitMQ server?
https://www.rabbitmq.com/management.html
The management plugin supports a simple HTTP API to send and receive messages. This is primarily intended for diagnostic purposes but can be used for low volume messaging without reliable delivery.
As mentioned, it's designed for very low loads, but it may be usable. If you need higher loads, then by all means cast around for a library that does the job and create a proxy. Most languages will have something. I've personally created a lightweight API using Lumen and https://github.com/bschmitt/laravel-amqp to tie a few disparate services together in the past, and it seems to work very well.
It is possible not but really recommended depending on load. You have three options really, two of which are web socket based and one that seems like what you're looking for. I'd suggest starting with the rabbitmq docs.
I want to create a web app using React as the front end technology. A requirement for the app is that the server will be able to update all the clients with information about changes (not have to be an exact real time, but should update after no more than 10 seconds).
Solutions like clients requesting updates from the server every several seconds are out of the question.
Requirements:
1) The server's should be implemented with either .NET or with Node.js.
2) The connection MUST be secured via port 443 of the IIS.
I read a bit about Micorsoft's SignalR and about Pusher Channels which seems to provide exactly the kind of service I require.
Could you please elaborate about what exactly are the differences between them? When should I choose each? Which of them got more community support? Which is easier to implement? Stuff like that...
Both SignalR and Pusher Channels ultimately both use websockets to deliver messages to clients, so both should meet your requirements to deliver messages to clients in realtime.
1) Both offerings also meet your requirements for both library support:
SignalR supports .NET:
https://dotnet.microsoft.com/apps/aspnet/signalr
Pusher Channels has server support for both nodejs and .NET:
https://github.com/pusher/pusher-http-node
https://github.com/pusher/pusher-http-dotnet
2) Both offerings also meet your requirements for sending messages over TLS/WSS:
SignalR:
https://kimsereyblog.blogspot.com/2018/07/signalr-with-asp-net-core.html
Pusher Channels:
Securing Pusher's messages
In terms of the differences between them this depends on your implementation, if you just run SignalR on your own ISS server then it will be down to you to manage all of the websocket connections and all of the scaling challenges that come with this.
However similar to how Channels works, SignalR also has a managed websocket service, so you do not need to manage the connections or scaling. You just make an API request with the message you want to send to either Channels or SignalR and this message is then broadcast to the interested clients connected by websockets. In this scenario you do not manage the websocket connections yourself.
However in terms of pricing Channels appears to be far more competitive (especially the free offering), so if you are looking at the managed offering Channels looks to be a better value proposition:
https://azure.microsoft.com/en-gb/pricing/details/signalr-service/
https://pusher.com/channels/pricing
Both offerings look fairly similar in terms of implementation (assuming you are using the managed service). The complexity would increase if you implement SignalR on ISS:
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-2.2
In terms of support Pusher has a free application support offering:
https://support.pusher.com/hc/en-us
Hope this helps!
This presentation has some answers A 10 Minute Guide to Choosing a Realtime Framework
We need to load test aspnetcore signalR application. I saw about crank but that
seems to help only with aspnet signalR. Can someone help me with this.
Most probably you need a load testing tool which supports WebSocket protocol as this is what SignalR will be doing by default.
It could be also Server Sent Events, Forever Frame or Long Polling so you need to clarify the NFRs and identify which protocols are in scope and what are the requirements which need to be tested.
Depending on your skills you can go for:
Gatling which has support of WebSocket, but you will need to do some programming in Scala
Apache JMeter which supports WebSocket via the plugin, JMeter allows you to create tests using simple GUI. You will be able to also test Long Polling and Server Sent Events using JMeter, check out How to Load Test Async Requests with JMeter for more details.
The short story: me and friend are making a multiplayer action game and we thought playn would be great for this. Android, java and HTML5 support is the most important ones but we don't want to cut out the others if not necessary.
The problem is now when we want to implement the networking part of it. We have implemented our own capable server and thought we would use long polling http requests for communication. We estimate now we need some way to have one thread running for the communication that use messages and two multithread safe queues. One queue for incoming messages that the update() part can consume from and one queue for outgoing messages to the server.
Is there any way to implement this without losing platform support? Or any other idea how we can implement this?
PlayN currently has no cross-platform support for persistent socket connections to a server. You will need to implement your own cross-platform abstraction. You can use WebSockets for the HTML5 backend, and you can look for a WebSockets library for Android and whatever other platforms you intend to support.
You can also use the Nexus library, which is designed to work with PlayN and provide client/server communication. However, it raises the level of abstraction substantially beyond passing simple messages between the client and server, so it might be easier to just implement your own simple WebSockets based communication than to learn how Nexus works.