Hi Steve, Before jumping all over what Andrei said, it would be wise to understand the context.
Andrei is a systems admin, he watches the impact of an app file on the equipment, he isn't involved in the application layer of the system. Andrei was commenting on issues that were uncovered during last peak season. The reality is completely different than his observations. Software is only as efficient as WE the developers make it. Asking witango to improve their code is important, however we also have a responsibility to ensure that the code we write is very efficient. In this particular case the app server is being blamed for a poorly architected solution. In our world, we are tasked to do our jobs as quickly as we can with an expectation that there is such thing as perfection. The truth is that we do what we can in the amount of time and when we experience problems with the architecture we go back and fix it. The issue that Andrei is addressing is in fact not the app server, it is the simple fact that when we wrote the application that is maxing out at 200 users, we referenced objects (.tcf) files in local scope, these .tcf files are called on every execution of every user. This was done because at the time, it didn't seem to be an issue and it was faster than placing them in a shared scope that might get cleared during execution. The truth, i should have referenced the objects as domain or application variables and did a better job of error handling, but that would have taken more time than what was available to me. Afterwards I had anticipated having enough time to go back and rethink what I had done, but unfortunately i didn't. This issue came to light once we started to see significant concurrent user sessions, you see, these .tcf files collectively are about 5Mb in size. If you do the math you will see that to manage 200 concurrent clicks the server would have to allocate 1Gb of memory. Running in application scope the server would only have to allocate 5Mb of memory. The servers have 4 daemons each and only 2Gb of memory. Hence we just ran out of room. This issue has brought to light additional symptoms of poor memory management, we see latency in the connections with the database, likely because a lack of memory available on the app server. The bottom line is this, over the 8+ years that i have been making stuff with Tango, the number 1 problem that i have had to deal with is me, and i am very advanced. Tango is a good and stable product if you use it properly, it is only when we skimp on planning and testing to understand best practices that we end up with issues that are easier to point at someone else rather than look at our own lack of understanding. The key reason that I, and I suspect everyone on this list uses Witango is that it is easy, fast, and even easier to change. With very little effort any level of developer can pretty much make whatever they can think of. This is distinctly different from every other platform. But along with easy comes a sense that "it should do it all". That isn't true. We as developers are responsible to write good code, just as we expect Witango to provide a stable and scalable server. I suspect that 90% of Tango users wouldn't even be coding if it weren't for Tango, everything else has a longer learning curve. I am happy with Witango, I, and my clients have made considerable money from using it and i am certain that i will continue to do well with it. Peter. > Andre Rekhtine's post a couple of weeks ago and some activity on one of > my sights last night brought this to a head for me. > > > > I had a sight last night that SearchPublisher 3.0 was indexing. I am > sure they are similar to other search engines in that each request > invokes a new user session. Imagine if you have 15 to 20 sites on a > Witango server, the normal 30 minute session inactivity variable purge, > normal traffic for each site and a few search engines start indexing the > sites. User sessions can exceed the 200 sessions that Andre talked about > real quick. > > > > Are any of you addressing this and if so how? > > > > I was thinking about building a table to keep track of user sessions > that would maintain last access and number of accesses by user > reference. Then having a cron job run every minute to find sessions with > only one access for the last five minutes. The cron job would then purge > the inactive sessions. I am not even sure I can do this as I can't find > a tag to purge other sessions users vars! > > > > I keep my user vars low - 4 or 5 per session and I also realize that I > could reduce the VARIABLETIMEOUT system setting, but there are a lot of > valid user sessions that I prefer not to keep requiring a new session > initialization. > > > > Comments please. > > > > Thanks > > > > Steve Fogelson > > Internet Commerce Solutions > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
