Hatler — threads, filters, speed, status codes

Very often, questions arise about: how to increase the speed of Hatler scanning? What do the numbers in the Hatler console mean. How Hatler filters affect scanning speed and why. Let’s try to figure it all out.

Previously, we have already discussed how to set up a Hatler and how it works. Now we will try to understand in more detail how everything is arranged and works.

Hatler — threads

We have already discussed in some detail how flows work in a proxy. But each software has different settings and properties for working with threads. One software, when installing 10 threads, can generate up to 500 simultaneous connections (this usually happens if the software completely opens the site with which it interacts), while the other will strictly observe the number of installed threads. Hatler just works with the actual flow restriction. If you specify 1000 threads in the Hatler, then during normal network operation, it will not go beyond this value. Of course, there are exceptions, but in any case, the Hatler itself tends to work within the limit of the specified simultaneous connections.

But why is the result of “ticks” different when we set, for example, 1000 threads?
What are tics in Hatler? A tick is a unit of time that Hatler takes to update crawl statistics. On average, a tick in a Hatler is equal to one second. Despite the fact that Hatler always works within the limit of the set number of threads, several factors affect the actual operation speed / scanning speed:

• Scan type (cannot be taken into account in calculations, but may affect speed)
• Number of games set to search
• Number of threads
• Request processing speed (this value includes: ping to the proxies themselves, the speed of the proxies themselves, the speed of Steam as a platform)
• Number of Hatler filters

Filters and speed in Hatlertool

Filters are the criteria by which the program divides Steam accounts into suitable ones and which are not. But the more criteria, the more data we need to collect from the Steam platform in order to understand whether the account is right for us or not. Let’s try to understand with examples.

Example 1: Scanning without filters. One game.
Imagine the situation, we work in a hatler without filters, we are only interested in one game — Dota2.
To process one account, the hatler will need 2 requests.
One request to get information about the account.
The second request is to the inventory itself. Done 🙂
But things get a little more complicated if we increase the number of filters and the number of games.

Example 2. Scanning with filters: level, badges. Two games.
In a situation where we scan with a hatler with a filter by level and badges and two games, as a result we get — 2 requests from the example above (GetPlayerSummaries + steamcommunity.com/inventory) + requests to get the level (which is done in Steam by a separate request — http: //api.steampowered.com/IPlayerService/GetSteamLevel) and badge information (GetCommunityBadgeProgress). Already 4 requests. Also 2 requests for two games.
In total, there are 6 requests for processing one account.

Accordingly, the more complex the filters and the more games, the fewer accounts per tick.
But already now we can imagine how many Hatler ticks we will have for example 1 and example 2.
Imagine that the average speed of one request is 1 second. The number of threads is 1000. Proxies are as clean as a nun’s tear (they respond with only 200 statuses). API keys are enough and they are also relatively private.
Formula: number of threads / number of requests per account * average processing speed per request
Tick ​​speed for example 1: 1000 (threads) / 2 (requests to scan one account) * 1 (one second average processing speed of one request) = 500 accounts per second.
Tick ​​speed for example 2: 1000 / 6 * 1 = ~167 accounts per tick.

Thus, the speed of the actual number of accounts per tick is affected by 3 key factors at once:
-average processing speed of one request (the higher the speed, the higher the tick)
-number of filters (the more filters, the lower the speed)
-threads (the more threads, the more accounts)

Status codes Hatler

What is the Hatler console «saying» to us?

Status code / request processing time for one request
Briefly about the status of the Hatler codes:
200 — everything is ok
429 — proxies are overloaded (steam answers that there are too many requests from one IP)
500 — most likely Steam is temporarily lying
0 — timeout, the Hatler could not receive a response within the allotted time

Recommendations for improving scanning speed

In order to get the maximum possible speed of work with the chtaler, we recommend:
—Use a dedicated server instead of a home PC.
On dedicated servers, the communication channel is better and more stable, which can significantly reduce the average processing speed of one request. If the average request processing speed is too high, try changing the hardware host or proxy.

• Follow the filters.
  Remove filters you don’t use.
  -Use quality proxies

Subscribe to the unofficial channel of the Hatler in the telegram: https://t.me/+uiD_CnmdUn85ZWIy
And also follow the news of the analogue of the Hatler — Steamler