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

Session variables and server resources

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

    #16
    Re: Session variables and server resources

    If you use a router to port forward to youre server just change it to not always allow access.

    Change it to maybe no access after 2:00 am then have the always up just restart the WAS at 3 am which will guarantee that nobody is logged in. Unless you have some crazy timeout settings.

    I run a machine with 4 gb ram an I normally run about 1gb for server and 1gb for mysql. And dont really have no issues with speed.

    Chad
    Chad Brown

    Comment


      #17
      Re: Session variables and server resources

      Originally posted by drgarytraub View Post
      I am still confused:

      1. Doesn't a session variable exist on the client, and a server variable on the server, and if that's true, then why does the session variable consume server RAM.
      Session variables exist entirely on the server.

      Originally posted by drgarytraub View Post
      2. Does delete session.variable recovery ALL the RAM that was allocated to it?
      Theoretically, yes. In practice, things like memory fragmentation will mean you aren't 100% back where you started in terms of system resources.

      Originally posted by drgarytraub View Post
      3. In a machine that has 4 GB RAM, why am I noticing significant slow downs when RAM gets just to 250K or so, and almost a crawl at 400K?
      I'm going to assume you mean MB, not KB. On a machine with 4GB of RAM, far less than that is actually available to Alpha, so you need to look at overall availability of memory. Also look at virtual memory usage as well as physical memory.

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

      Comment


        #18
        Re: Session variables and server resources

        Originally posted by Peter.Greulich View Post
        Ok. Just to muddy the waters further, what is the difference between a session variable and a global variable. I understand that session vars are/can be seen by each page in your app. I know, too, that global vars can be passed from, say a dialog to a report. But beyond that? Can global vars be passed between pages? And if yes, why use session vars?
        In a desktop environment, scope and lifetime are effectively the same thing and often used interchangeably, or at least not considered independently. In a web application though, the distinction is very important.

        Scope refers to the visibility of a variable through function calls and subroutines. Global is a scope, as are local and shared.

        Lifetime refers to when a variable is removed from memory, regardless of scope. Session and Page are variable lifetimes in the Application Server.

        When you dim session.foo as c, you create a variable with local scope and session lifetime. This makes it available to all subsequent page requests while the session is still active, but only at the top-level A5W page. If you want to use it within a function for example, you need to explicitely pass it to that function.

        When you dim global foo as c, you create a variable with global scope and page lifetime. It will be visible to all functions, reports, etc., but it will be deleted as soon as the current A5W page completes processing.

        I hope that clarifies things a bit for you.

        -Lenny

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

        Comment


          #19
          Re: Session variables and server resources

          Originally posted by Lenny Forziati View Post
          I hope that clarifies things a bit for you.
          Yes it does. Thanks Lenny.
          Peter
          AlphaBase Solutions, LLC

          [email protected]
          https://www.alphabasesolutions.com


          Comment


            #20
            Re: Session variables and server resources

            This is all very good information. Thank you!

            I have been doing some testing and want to share some observations:

            I am working on my development machine within version 9 for this test. I have the Windows task manager open while i do various things within alpha, so I can monitor what happens to CPU and RAM as I do certain things, all in an attempt to get a handle on what things affect what and by how much:

            1. Just opening a5v9, and RAM is at 40,120 K; goes to 47,896K just by clicking Web Projects; closing the Web Projects does NOT release the memory - in fact it is now at 47,880K; going back in puts the RAM at 48,856K.

            2. Opening an a5w page with just html and a little bit of xbasic, but no components, puts the RAM usage at 53,536K; closing the page puts RAM down to 53,216K.

            3. Opening a new page causes a jump in RAM to 54,480K; closing that page recovers some but not all of the RAM - now at 54,004K.

            4. opening a page, and declaring a session variable called session.idnumber and putting a 10 character value in that variable causes memory to go to 58,588K, which is NOT recovered when the page is closed

            5. the following simple script caused the CPU to hang at 50:
            dim session.idnumber as c = "0000000001"
            delete session.idnumber

            Can anyone make sense out of these apparently confusing results.
            Last edited by drgarytraub; 10-28-2009, 09:14 PM.
            Gary S. Traub, Ph.D.

            Comment


              #21
              Re: Session variables and server resources

              Another observation:

              Logging out by means of the following script does NOT recover any RAM:

              session.reset()
              a5ws_logoutuser()
              response.redirect("index.a5w")

              Why not???
              Gary S. Traub, Ph.D.

              Comment


                #22
                Re: Session variables and server resources

                Gary. Are you talking about the WAS or your development copy and localhost?
                Steve Wood
                See my profile on IADN

                Comment


                  #23
                  Re: Session variables and server resources

                  The latter, but I am doing this to get a handle on how alpha handles memory. Why, are you saying that there will be differences on the WAS versus localhost? Even if that's so, ignore absolute numbers, and look at the relative values.

                  Opening an a5w page on localhost (#2 above) gobbles up almost 5,000K which is not recovered upon closing the page.

                  Opening a page that contains only 2 lines of xbasic (and nothing else, except some very basic html generated by alpha) - 1st line initializes a session variable and stores just 10 characters of data, and the second line deletes that session variable - this gobbles up another 4,500K.

                  Localhost or not, these results are confusing, at least to me.

                  Again, I am just trying to get a handle on the things that make a difference to RAM so that I can develop a strategy to improve performance of the application.
                  Gary S. Traub, Ph.D.

                  Comment


                    #24
                    Re: Session variables and server resources

                    I would be completely unconcerned about how the CPU or Memory react to activity on your development copy. As you use the program it will continue to increase memory to some maximum and then hover around that point. Mine runs around 110-120MB.

                    Every time you use a resource for the first time, it will increase memory usage and not recover. So when you open your first A5W page for editing, memory will increase and not recover. But the memory for the specific page you happen to be looking at will be returned when you close that page. CPU will stay high while any resource is in use, such as editing an A5W page and showing the page in LivePreview.

                    Your development copy is a Windows GUI application and different from the WAS which just sits in mostly an idle state and serves up pages.

                    Localhost is tied to the development copy and therefore affected by your actions on that Windows GUI app.
                    Steve Wood
                    See my profile on IADN

                    Comment


                      #25
                      Re: Session variables and server resources

                      Gary,
                      Thank you for bringing this question to light once again.

                      As a novice developer two years ago, I was (and still am) stumped as to how to best declare variables and how they should/could be used. At the time, I thought all variables had to be declared “session.variable.” I had session.variables here there and everywhere!

                      After I authored this thread and received replies, especially Lenny’s, I realized this was not the best approach for most of my pages.

                      I have since painstakingly modified many of my pages and links changing the session.variables to page or local variables and extensively tested them. The reason for me is that the variables must change anyway with each page due to completely new data requested. Yet the question I have been asking myself if am I really saving server resources by doing this??

                      My suggestion: Alpha creates a detailed white paper in layman’s terms called “variable declaration and efficiency.” It could describe the methods of declaring variables (global, session, local, page, whatever) and examples of how they might be used (filters) and what ramifications they have on server memory. Discussion on overall system/server memory would also help. This would have been nice for me in my rookie months and would have saved me countless hours of valuable time. Lenny’s posts here might be a great start!

                      I know this was attempted in the “Help” but overwhelmed my rookie brain. :)
                      Last edited by EricN; 10-29-2009, 03:59 PM.
                      Eric

                      Alpha Five Websites
                      longlivepuppies.com
                      socialservicenetwork.com
                      -------------------------------------------------
                      socialservicenetwork.org

                      Comment


                        #26
                        Re: Session variables and server resources

                        Eric,

                        I couldn't agree with you more. Frankly, I would like to have been warned that memory issues are a strong consideration. I never had that problem on the desktop side. I remember programming in an old DOS language years ago, called Open Access, where an entire section of the manual was devoted to memory management. Back then memory was very small and thus memory management was critical. I did not know it would be such an issue here. Maybe I should have known, but I didn't. So a well written guide on what are the "best practices" would be very welcomed!!
                        Gary S. Traub, Ph.D.

                        Comment


                          #27
                          Re: Session variables and server resources

                          Steve,

                          Sorry I just noticed your reply to my recent post. Boy you were up early this AM! :)

                          I understand everything that you said. But still searching to find a way to get a handle on "best practices".
                          Gary S. Traub, Ph.D.

                          Comment

                          Working...
                          X