Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Keep-alive warning

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Keep-alive warning

    We have a lot of these in our Error logs. I can't find a best-practices or any "what to do about this". Any suggestions?

    [warning] The server is currently busy waiting for too many Keep-Alive requests. Idle Keep-Alive connections are being closed.
    -Steve
    sigpic

  • #2
    Did you change your server Performance settings to something other than default for HTTP keep alive?

    Keep Alive.jpg
    Alpha Anywhere v12.4.6.4.2 Build 8245-5650 IIS v10.0 on Windows Server 2019 Std in Hyper-V

    Comment


    • #3
      Obviously you are using some proxy. in Alpha you could try to disable Http Keep Alive or make it longer(20 or something else)

      Comment


      • #4
        Thanks. I'm hoping for a bit of an education here. I don't know how to figure out what's best. These are classic server instances. They are under a local load balancer, with Cloudflare out in front. Settings are, I think, the defaults:

        KeepAlive.Enable = "true"
        KeepAlive.MaxRequests = "10000"
        KeepAlive.MaxTimeout = "15"

        Does extending (or shortening) the time affect performance? How to choose a different Timeout? What about increasing the MaxRequests?

        Sure I could experiment but we *are* having server problems, I see a lot of this in the logs, and would like to approach this intelligently. And, maybe what I'm seeing is OK - I don't know.
        -Steve
        sigpic

        Comment


        • #5
          If performance (latency) is bad then...

          Cloudflare will keep connection for up to 15 minutes (900 sec) so I think you have two options. Test to totally disable Keep Alive. Your client will get better performance but your classic servers have to work harder but they are ready to serve all the time.

          The other option is to put in MaxTimeout a very little value maybe 2-5 (because the CloudFlare timeout is just too big). This means your workers are free to do new jobs again very soon and so the latency should be better for clients.

          I think you just have to test but it is normal that server will close keep alive connections with proxy.



          Comment


          • #6
            You know what - ask Alpha, in this day and age when Elon Musk has got starlink, space ships, Telsa cars and what ever else going on - why would this problem exit in AA - today. - It blows my mind.
            Insanity: doing the same thing over and over again and expecting different results.
            Albert Einstein, (attributed)
            US (German-born) physicist (1879 - 1955)

            Comment


            • #7
              When Keep-Alive is in use, clients keep socket connections open to the server to be used for subsequent requests, such as images, style sheets, callbacks, navigating to new pages, and so on. Typically you will see browsers use 4-6 keep-alive connections per server, though there is no strict limit.

              On the server side, this dedicates worker threads to those clients. The Classic App Server will run up to 128 worker threads, based on your App Server settings. Assuming 4 connections per client, this means that 32 clients would be enough to tie up all of the worker threads and block out any other clients from making connections. The 33rd client would time out trying to connect. To prevent this situation, the server monitors how many worker threads are dedicated to open but idle keep-alive connections, and it will forcibly close some if there are no other available worker threads.

              The log messages you are seeing are an indication that your server is under a high client load and it is taking measures to ensure it can still respond to new clients. This is "normal" operation for the situation, but also means you should add server capacity if it is a regular occurrence because performance is being reduced.

              Your situation is slightly muddied by your use of Cloudflare however. With Cloudflare sitting between the end users and your servers, all of those keep-alive connections should be to Cloudflare. What I have been unable to find in Cloudflare's documentation and blog is if they dedicate connections to unique clients, or if they reuse them across clients. If they dedicate them, the explanation above completely applies and you need to consider additional capacity. If they do not dedicate them, and instead will proxy requests from any client on any existing connection, then the situation is still an issue that suggest adding capacity, but it may actually be better to not forcibly close the connections. If you have a support contact at Cloudflare that can definitively answer this, it would be helpful to know. We could potentially add an option to not close the connections in this case.

              Lenny Forziati
              Vice President, Internet Products and Technical Services
              Alpha Software Corporation

              Comment


              • #8
                Follow up question Lenny: Worker threads are terminated when the user logs out, right? ...or if a thread is idle longer than the maxTimeout parameter. Does simply closing the browser (not logging out) also terminate worker threads? Is there any reason to not have threads set to the maximum of 128?

                Thanks.
                Mike Brown - Contact Me
                Programmatic Technologies, LLC
                Programmatic-Technologies.com
                Independent Developer & Consultant

                Comment


                • #9
                  Worker threads are never terminated because they are relatively expensive to start up. They are not dedicated to a specific client except while they are actively processing a request or they have an idle keep-alive connection open so there is no direct correlation between users and threads.

                  More worker threads creates more contention for finite server resources - primarily CPU but also system memory. There is a point where too many threads, even if they are not actively processing a request or waiting on a keep-alive connection, will hurt performance. In order to find that point for your system, you would need to do load testing against your application while observing response times.

                  You can think of the threads as waitstaff at your favorite restaurant. When your server is actively serving you, they cannot do anything for other diners (actively handling a request). When the server is at your table waiting for you to decide what you would like to order, they aren't actually doing anything for you, but they also cannot tend to other diners (keep-alive). When your server is not actively serving you, they can serve other diners (idle threads). When they are done serving that other diner, they are available to serve you again or take on yet another diner that has been recently seated. The restaurant can accommodate more diners by adding waitstaff, but will still be constrained by the size of the kitchen and the number of tables (CPU and RAM). If you keep adding waitstaff anyway, they get in each others way going through doorways, trying to pick up entrees, etc. while overloading the kitchen and not having enough tables to seat diners at.

                  To complete my analogy and bring it back to the original question by Steve, the Keep-Alive connections being closed would be the same as the restaurant manager going around to the waitstaff that are patiently waiting at tables to take orders, and telling them to move on to other tables instead and come back here once the diners have made their decision.
                  Last edited by Lenny Forziati; 06-30-2022, 11:22 AM.

                  Lenny Forziati
                  Vice President, Internet Products and Technical Services
                  Alpha Software Corporation

                  Comment


                  • #10
                    Excellent explanation. Thank you, it's appreciated.
                    Mike Brown - Contact Me
                    Programmatic Technologies, LLC
                    Programmatic-Technologies.com
                    Independent Developer & Consultant

                    Comment


                    • #11
                      Nice explanation - good to know - might be an idea to add to the documentation.
                      Thanks Lenny.
                      Insanity: doing the same thing over and over again and expecting different results.
                      Albert Einstein, (attributed)
                      US (German-born) physicist (1879 - 1955)

                      Comment


                      • #12
                        Agreed, what a great explanation, even I can understand that analogy

                        Thanks Lenny
                        Alpha Anywhere v12.4.6.4.2 Build 8245-5650 IIS v10.0 on Windows Server 2019 Std in Hyper-V

                        Comment


                        • #13
                          This is another good reason to offload work to stored procedures, especially if the task is a long running query (check the slow query log) or makes a number of server connections. In our case, we have MySQL on a Lynix server and it is not even breating hard. It is multi-threaded and makes fast work of the server load. Another suggestion is to make sure you close connections as soon as possible in your scripts especailly if they are open for a long time. It is easy to open a connection and just leave it open.
                          Pat Bremkamp
                          MindKicks Consulting

                          Comment


                          • #14
                            Originally posted by Lenny Forziati View Post
                            Worker threads are never terminated because they are relatively expensive to start up. They are not dedicated to a specific client except while they are actively processing a request or they have an idle keep-alive connection open so there is no direct correlation between users and threads.

                            More worker threads creates more contention for finite server resources - primarily CPU but also system memory. There is a point where too many threads, even if they are not actively processing a request or waiting on a keep-alive connection, will hurt performance. In order to find that point for your system, you would need to do load testing against your application while observing response times.

                            You can think of the threads as waitstaff at your favorite restaurant. When your server is actively serving you, they cannot do anything for other diners (actively handling a request). When the server is at your table waiting for you to decide what you would like to order, they aren't actually doing anything for you, but they also cannot tend to other diners (keep-alive). When your server is not actively serving you, they can serve other diners (idle threads). When they are done serving that other diner, they are available to serve you again or take on yet another diner that has been recently seated. The restaurant can accommodate more diners by adding waitstaff, but will still be constrained by the size of the kitchen and the number of tables (CPU and RAM). If you keep adding waitstaff anyway, they get in each others way going through doorways, trying to pick up entrees, etc. while overloading the kitchen and not having enough tables to seat diners at.
                            To complete my analogy and bring it back to the original question by Steve, the Keep-Alive connections being closed would be the same as the restaurant manager going around to the waitstaff that are patiently waiting at tables to take orders, and telling them to move on to other tables instead and come back here once the diners have made their decision.

                            Lenny Forziati
                            Vice President, Internet Products and Technical Services
                            Alpha Software Corporation

                            Comment


                            • #15
                              In running server instance interactive window you can do interesting things. One is to get info about server. Few interesting functions are SetPrimaryProcessor, PrimaryProcessor, showprocessorassignments, thread_variables and A5_ThreadStackDump. But more info more pain in head.

                              Comment

                              Working...
                              X