Nothing special. No errors, no dropped connections just an increased
server response time (Tr). An excerpt from low and high traffic times is
below:
Jun 20 18:05:29 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.28
client_ip:193.XX.XX.XXX client_port:50876 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:157 Tq:95 Tw:0 Tc:2 Tr:60
Jun 20 18:05:29 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.41
client_ip:193.XX.XX.XXX client_port:32910 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:148 Tq:82 Tw:0 Tc:1 Tr:65
Jun 20 18:05:30 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.40
client_ip:193.XX.XX.XXX client_port:51077 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:525 Tq:312 Tw:0 Tc:2 Tr:211
Jun 20 22:05:36 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.28
client_ip:193.XX.XX.XXX client_port:48936 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:25368 Tq:101 Tw:0 Tc:3 Tr:25264
Jun 20 22:05:36 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.41
client_ip:193.XX.XX.XXX client_port:43030 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:23474 Tq:88 Tw:0 Tc:2 Tr:23383
Jun 20 22:05:36 localhost haproxy[13426]: ndc vakanz-backend/10.2.8.40
client_ip:193.XX.XX.XXX client_port:18935 SSL_version:TLSv1.2
SSL_cypher:DHE-RSA-AES256-GCM-SHA384 -- Tt:26150 Tq:106 Tw:0 Tc:3 Tr:26040
Am 21.06.17 um 10:21 schrieb Igor Cicimov:
On 21 Jun 2017 6:11 pm, "Daniel Heitepriem"
<[email protected] <mailto:[email protected]>>
wrote:
Hi Jarno,
yes we are decrypting TLS on the frontend (official
SSL-certificate) and re-encrypt it before sending it to the
backend (company policy so not that easy to change it to an
unencrypted connection). The CPU usage is not higher than 15-20%
even during peak times and the memory usage is also quite low
(200-800MB).
Regards,
Daniel
Am 21.06.17 um 10:00 schrieb Jarno Huuskonen:
Hi,
On Wed, Jun 21, Daniel Heitepriem wrote:
we got a problem recently which we can't explain to
ourself. We got
a java application (Tomcat WAR-File) which has to handle
several
million of requests per day and several thousand requests
per second
during peak times. Due to this high amount we are
splitting traffic
using an ACL in "booking traffic" and "availability traffic".
Booking traffic is negligible but the Availability traffic is
load-balanced over several application servers. The
problem that
occurs is that our external partner "floods" the
Availability-Frontend with several thousand requests per
second and
the backend becomes unresponsive. If we redirect them
directly to
Looks like you're decrypting tls/ssl on frontend and then
re-encrypting on backend/server. Is one core(you're not using
nbproc?)
able to handle thousand ssl requests coming in and going out ?
(is haproxy process using 100% cpu).
-Jarno
What do you see in the haproxy log when the problem happens?
--
Mit freundlichen Gruessen / Best regards
Daniel Heitepriem
pribas GmbH
Valterweg 24-25
65817 Eppstein-Bremthal
Germany
Phone +49 (0) 6198 57146400
Fax +49 (0) 6198 57146433
eMail [email protected]
Corporate Headquarters: Huenfelden-Dauborn Managing Director: Arnulf Pribas
Registration: Amtsgericht Limburg a. d. Lahn 7HRB874 Tax ID: DE113840457
________________________________________________________________________
This e-mail is confidential. Information in this e-mail is intended for
the exclusive use of the individual or entity named above and may
constitute information that is privileged or confidential or otherwise
protected from disclosure. The information in this e-mail may be read,
published, copied and/or forwarded only by the individual or entity
named above. Dissemination, distribution, forwarding or copying of this
e-mail by anyone other than the intended recipient is prohibited. If you
have received this e-mail in error, please notify us immediately by
telephone or e-mail and completely delete or destroy any and all
disseminated, distributed, forwarded electronic or other copies of the
original message and any attachments.
