<div dir="ltr"><div dir="ltr">Hi Lourens,<div><br></div><div>Thanks for the reply. <br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"></div></div></div></div></div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1"><p class="MsoNormal">You probably need to look at a multi thread/auto scaling solution. Forcing a timeout will probably give the client a bad experience if it happens often.</p></div></div></div></blockquote><div><br></div><div>I think this is what happens anyway: there are timeouts (in the nginx setup, eg. proxy_read_timeout and proxy_connect_timeout) that will timeout the upstream connections. And this causes a bad experience for the user. We want to manage this better.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1">
<p class="MsoNormal">Usually each socket has a queue to “hold new requests” while the first one is being processed. (Making that 1 will cause problems on systems under load).
<u></u><u></u></p>
<p class="MsoNormal">Thus GemStone need to be able process more than 1 request on that queue, so if there are 5 requests on the queue, and no. 1 is a slow one, no. 2 – 5 will wait until no. 1 is complete.</p></div></div></div></blockquote><div><br></div><div>We start up a limited number of sessions and at this point it is ok if there are some requests waiting in a queue. Nginx decides which queues have the least number of connections and routes the requests to that one. So the idea is that requests are routed to queues that get serviced quickly. Yes, under load it may happen that some requests get stuck behind a process that takes too long. We are working on those.</div><div><br></div><div>The particular problem that I'm trying to prevent is that requests are routed to a queue where the GemStone process is still busy (and unable to handle the request), while other queues are empty (and able to handle requests). This is caused by the fact that a browser starts a heavy process and then navigates away (this is what I tried to explain in my original email).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1">
<p class="MsoNormal">Now if GemStone process can process 2 requests per socket requests 2-5 will not wait for call no.1, thus the fast calls will be processed as normal.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If 2 slow requests sits in a row, you will have the same issue, 3-5 will need to wait. This is where autoscaling comes in. GemStone needs to note request 1 is slow thus start a 3^rd thread up incase no. 2 also is a slow request.
 If no. 2 is slow then start a 4^th thread etc. And if things speed up again reduce the threads. Or always keep 3 threads and scale up when 1 request show slowness. </p></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This will also mean each thread have it’s own logged in session so that one thread does not persist 50% of another call’s data.</p></div></div></div></blockquote><div><br></div><div>This may be something that we can investigate later. We currently start up multiple sessions that do not use threading. I have not encountered a setup where a GS thread could have its own logged in session (are there references that you can give to this, please?). I have not encountered "autoscaling" in the documentation or other literature (for this kind of context) before. Can you refer me to where I can read more about this?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1">
<p class="MsoNormal">In the interim you could increase the ports on GemStone and nginx if possible. This will not remove the problem but hopefully reduce the occurrence.</p></div></div></div></blockquote><div><br></div><div>We are running 4 to 8 GemStone sessions (topaz) for web users (depending on how busy the instance is). They seem to handle the load well, except in the situation that we're struggling with.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6017417833104899762"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6017417833104899762WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regards<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Lourens<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Glass <<a href="mailto:glass-bounces@lists.gemtalksystems.com" target="_blank">glass-bounces@lists.gemtalksystems.com</a>> <b>
On Behalf Of </b>Otto Behrens via Glass<br>
<b>Sent:</b> Wednesday, December 20, 2023 2:04 PM<br>
<b>To:</b> <a href="mailto:glass@lists.gemtalksystems.com" target="_blank">glass@lists.gemtalksystems.com</a><br>
<b>Cc:</b> Iwan Vosloo <<a href="mailto:iwan@finworks.biz" target="_blank">iwan@finworks.biz</a>><br>
<b>Subject:</b> [Glass] load balancer configuration<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We are using nginx to load balance in front of GemStone that runs a Seaside application. Some of our requests run too long (we are working hard to cut them down) and in general, the time it takes to service a request in our application
 varies between 0.1 and about 4 seconds. We are improving and getting more towards the lower end of that. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Because of this, we use the least_conn directive and we persist session state so that we could use any of our GemStone upstream sessions to service a request. Requests are generally load balanced to idle sessions and there are theoretically
 no requests that wait for another to get serviced. Perhaps this is not optimal and you have better suggestions. It has worked ok for a long time, but should we consider another approach?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">When our code misbehaves and a request takes let's say 60 seconds to handle, things go pear shaped (yes we want to eliminate them). The user clicks "back" on the browser or closes the browser and nginx picks it up with: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">"epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We suspect our problem is: when this happens, it appears as if nginx then routes requests to that same upstream, which is unable to handle it because it is busy handling the previous request (which is taking too long), even with some upstream
 sessions sitting idle. Some users then end up with no response.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Ideally, we would like to catch the situation in the GemStone session and stop processing the request (when nginx closes the upstream connection). Alternatively, we could set timeouts long enough so that if the browser prematurely closes
 the connection, nginx does not close the upstream connection. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Do you have a suggestion to handle this? Does it make sense to get timeouts (which ones?) to align so that this does not happen?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks a lot<u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr>
<td width="400" valign="bottom" style="width:300pt;padding:0cm">
<p style="margin:0cm"><b><span style="font-size:13.5pt;color:rgb(146,148,151)">Otto Behrens</span></b><span style="font-size:13.5pt;font-family:Times,serif;color:black"><u></u><u></u></span></p>
<p style="margin:0cm"><span style="font-size:10.5pt;color:rgb(146,148,151)">+27 82 809 2375</span><b><span style="font-size:13.5pt;color:rgb(146,148,151)"><u></u><u></u></span></b></p>
</td>
<td width="200" style="width:150pt;padding:0cm">
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:Times,serif;color:black"><img width="200" height="38" style="width: 2.0833in; height: 0.3958in;" id="m_-6017417833104899762_x0000_i1026" src="https://www.finworks.biz/signature/finworks-signature-logo.png" alt="FINWorks"></span><span style="font-size:13.5pt;font-family:Times,serif;color:black"><u></u><u></u></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr style="height:3.75pt">
<td style="padding:0cm;height:3.75pt"></td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="1" cellspacing="0" cellpadding="0" width="600" style="width:450pt;border-top:none;border-right:none;border-left:none;border-bottom:1pt solid rgb(200,28,36)">
<tbody>
<tr style="height:11.25pt">
<td style="border:none;padding:0cm;height:11.25pt"></td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr style="height:15pt">
<td style="padding:0cm;height:15pt"></td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr>
<td width="15" valign="top" style="width:11.25pt;padding:0cm;display:inline-block">
<p class="MsoNormal"><a href="http://za.linkedin.com/in/waltherbehrens" target="_blank"><span style="font-size:13.5pt;font-family:Times,serif;color:rgb(17,85,204);text-decoration:none"><img border="0" width="15" height="15" style="width: 0.1562in; height: 0.1562in;" id="m_-6017417833104899762_x0000_i1025" src="https://www.finworks.biz/signature/finworks-linkedin-logo.png" alt="FINWorks"></span></a><span style="font-size:13.5pt;font-family:Times,serif;color:black"><u></u><u></u></span></p>
</td>
<td width="250" valign="top" style="width:187.5pt;padding:0cm;display:inline-block">
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:Times,serif;color:black"><a href="http://www.finworks.biz" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(200,28,36)">www.finworks.biz</span></a><u></u><u></u></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr style="height:7.5pt">
<td style="padding:0cm;height:7.5pt"></td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><u></u> <u></u></span></p>
<table border="0" cellspacing="0" cellpadding="0" width="600" style="width:450pt">
<tbody>
<tr>
<td style="padding:0cm">
<p style="text-align:justify"><span style="font-size:7.5pt;color:rgb(146,148,151)">Disclaimer & Confidentiality Note: This email is intended solely for the use of the individual or entity named above as it may contain information that is confidential and privileged.
 If you are not the intended recipient, be advised that any dissemination, distribution or copying of this email is strictly prohibited. FINWorks cannot be held liable by any person other than the addressee in respect of any opinions, conclusions, advice or
 other information contained in this email.<u></u><u></u></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>



  <br><br>
  <p style="font-family:Verdana;font-size:8pt;color:rgb(102,102,102)">
This electronic message, including any attachments, is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you are not the intended recipient, please notify us immediately by replying to this message and then delete this message from your system. Any use, dissemination, distribution or reproduction of this message or any attachments by unintended recipients is unauthorised and may be unlawful. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to perform your own virus checks on any attachment to this message. We do not accept liability for any loss or damage caused by software viruses.
  <br><br>
</p></div>
</div></blockquote></div></div>