ab test very slow, requests per second? about e2guardian

[philipianpearce]

Hi, I've on;y just picked this up as I have been leave following an operation on 1st March.

What do the e2guarding access logs say? Have you tuned e2guardian for such a test?
The defaults settings are for up to 4 users use ( < 100 req per sec), so tests like this will overload the default system.

Have you enabled the dstats log? This will give you the information you need to tune e2guardian and see whether you have sufficient httpsworkers configured.

Also, check processor and memory usage.

The smallest platform for production usage (for up to 200 users) would be 4 processors and 8G memory.

Also, what network speed do you have between testing and e2g target and to the target site on the internet?

For comparison have you tried the ab directly to the test site?

How did you configure e2g to block and allow the site?

[szrce]

thank you @philippearce,

how we can change, 4 users and how we tune 350 users or how we calculate 350 users max req per sec , have you any hint?

also dstat output like bellow,

time		        httpw	busy	httpwQ	logQ	conx	conx/s	 reqs	reqs/s	maxfd	LCcnt
2024-04-19 13:37	2048	0	0	0	117	0	700	 2	18	 1
2024-04-18 17:38	1024	1	0	0	28	0	1017	 3	25	 1
2024-04-18 17:43	1024	2	0	0	6	0	6	 0	25	 1
2024-04-18 17:48	1024	3	0	0	5	0	5	 0	25	 1
2024-04-18 17:53	1024	3	0	0	4	0	4	 0	25	 1
2024-04-18 18:01	2048	5	0	0	3150	10	6019	 20	720	 1
2024-04-18 18:06	2048	2	0	0	2415	7	7769	 25	994	 1

[philipianpearce]

When testing it is a good idea to set dstatinterval to a short period say 10 secs - you will be able see what is happening better then as you will have a 10sec average figures and 10 sec snapshot of busy workers. Looking at your trace. If you divide maxfd by 2 = 497 gives you the maximum number of httpworkers used in any instant so for this load httpworkers = 800 would be fine. How much resources you need depends on how the users are using the net and how many sites are allowed through without content-filtering, but looking at one of our production systems with 1G internet feed and around average 350 users, the maxiumum reqs/s over 300 second average we see is around 200 req/s and peak at 3,000 busy workers. Some request responses may be in less than 10 ms, others many thousands of seconds. I would recommend at least 8 cores and 16G ram for this, you can then tune it once in production by looking at dstats and at system usage of processors and memory. Regards Philip

…

----- On 19 Apr, 2024, at 11:43, Sezer ***@***.***> wrote:

thank you [ https://github.com/philippearce | @philippearce ] , good see you, how we can change, 4 users and how we tune 350 users or how we calculate 350 users max req per sec , have you any hint? also dstat output like bellow, time httpw busy httpwQ logQ conx conx/s reqs reqs/s maxfd LCcnt 2024-04-19 13:37 2048 0 0 0 117 0 700 2 18 1 2024-04-18 17:38 1024 1 0 0 28 0 1017 3 25 1 2024-04-18 17:43 1024 2 0 0 6 0 6 0 25 1 2024-04-18 17:48 1024 3 0 0 5 0 5 0 25 1 2024-04-18 17:53 1024 3 0 0 4 0 4 0 25 1 2024-04-18 18:01 2048 5 0 0 3150 10 6019 20 720 1 2024-04-18 18:06 2048 2 0 0 2415 7 7769 25 994 1 — Reply to this email directly, [ #802 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABHZDWNLFSW5SYOVVR5HDZDY6DYO7AVCNFSM6AAAAABESC3IYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGMYTAOJXHA | unsubscribe ] . You are receiving this because you were mentioned. Message ID: ***@***.***>

[szrce]

thank you for u information, yesterday i did check again with some settings,

when you change bellow settings

reportinglevel = 3

to

reportinglevel = 2 or redirect

so mean if e2g return html template the test output will be very slow 350 users to 200 per sec, but when you redirect some php page or just denied settings output very high 350 users 3k per sec.

do you have any idea, is it bug somewhere?

[philipianpearce]

With reportinglevel 3 (a page has to be generated from the template - very little time) and a full page with standard template is > 50k bytes of formatted html including an image is returned to the browser. So ~LAN bandwidth used = 50k bytes x 200 x 8 = plus TCP/IP overhead = >100Mbits/s With other settings or redirect the number of bytes returned will be much smaller (less than 1k). So ~LAN bandwidth used = 1k bytes x 3,000 x 8 = plus TCP/IP overhead = >30 Mbits/s When load testing, you are testing the hardware, network path and well as the software. So no, it is not a bug - it is more likely a bottle-neck in the network or in the host system network handling. Why are you load testing for blocking? In a working system block pages are not delivered very often, as users tend to avoid sites that have been blocked to them.

…

----- On 24 Apr, 2024, at 07:16, Sezer ***@***.***> wrote:

thank you for u information, yesterday i did check again with some settings, when you change bellow settings reportinglevel = 3 to reportinglevel = 2 or redirect so mean if e2g return html template the test output will be very slow 350 users to 200 per sec, but when you redirect some php page or just denied settings output very high 350 users 3k per sec. do you have any idea, is it bug somewhere? — Reply to this email directly, [ #802 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABHZDWKMN57N7FZ7KMCLQ63Y65E2FAVCNFSM6AAAAABESC3IYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGE2DQNBYGE | unsubscribe ] . You are receiving this because you were mentioned. Message ID: ***@***.***>

[szrce]

Actually we wanted to know how to calculate system requirements for RAM and CPU in order to handle different levels of user requests per second, such as 350, 500, and 1000 users, Sometimes e2guardian( version 5.3.1) giving kernel dumps average 300 users we cant reach devices, until reboot , all of issues that why

We had thought that if we improve the system options, maybe we won't get dumps, sorry we couldn't think about other issues like internet speeds.

but you answered all questions, if i get another problem or getting kernel dumps this version i will share.

thank you for everything.

[philipianpearce]

@szrce v5.3.1 is now 5 years old and the final v5.3 release v5.3.5 4 years old, so no longer supported.
There a number of bug fixes since then that relate to intermittent crashes. Most of these as related to apps that miss-use the http protocol (for example see a recent one with whatsapp which exposed a bug when bad headers are sent. #794).
Obviously, the greater the number and diversity of users, then the greater the chance of one of these apps being used and a crash happening. So this may not be a capacity issue.
If a hardware set-up works generally OK with v5.3 then it should be fine with v5.5. At least, that is our experience on a linux platform.

[szrce]

yeap sure, i will check newer versions thank you all informations.