MarketSquare / MarketSquare/Rammbock

Slow performance of 'Client Sends Message' operation

Open
#84 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
64
Forks
48
PR merge metrics
No merged PRs in 30d

Description

Is there a way to improve performance of 'Client Sends Message'?

I have a test where I would like to stress test server. It it should not be like specialized equipment for such tests, just send several hundred messages at the same time. I have 2 solutions, one using Rammbock/Python and another using Golang

The Rammbock looks the following

    FOR    ${counter}    IN RANGE    ${500}
        Client Sends Message    name=${socket}    header:seq:${counter}
    END

Results:
FOR ${counter}    IN RANGE    ${500}  
Start / End / Elapsed:	20240610 13:08:12.109 / 20240610 13:08:19.522 / 00:00:07.413

Each iteration:
00:00:00.016ITERATION ${counter} = 0  
Start / End / Elapsed:	20240610 13:08:12.111 / 20240610 13:08:12.127 / 00:00:00.016
00:00:00.015KEYWORD Rammbock . Client Sends Message   name=${socket}    header:seq:${counter}

Each message takes 16 ms. When I compare it with Go solution it takes only 2 ms per message. So Rammbock is 8 times slower.

Question is following. Is there a way to optimize Rammbock performance? I believe most time is spent on message construction. Perhaps there is a way to pre-cache messages before sending? Task is to send bunch of messages asap to the server.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the implementation of the Client Sends Message operation and profile the 500-message loop described in the issue. Compare message-construction and sending costs with the reported Go timing, then define completion as a measurable reduction in the roughly 16 ms per-message runtime without changing message behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
networking, testing-qa
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.