×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
From: Thorbjoern Ravn Andersen
Actually I do not know. We primarily do ProgramCalls.
Others?
All my applications run under a portal, which authenticates against an IBM i database and against an IBM i user profile (a system object). Sorry, the applications are not available to the public. You could test the portal login, and monitor response times, using Fiddler or Firebug or something. Sadly, it's a trivial example. It hits a couple the DB tables to fetch session and user profile data, though.
http://www.radile.com/rdweb/ptl.html
For most database maintenance applications on my server, Fiddler reports request response times in the 15-150 ms range, typically - on the local network. Firebug sometimes reports response times as low as 5 ms.
But I've become more acutely aware lately that numbers like this can be misleading because in the real world, an IBM i server is normally hosting and supporting hundreds of different applications, and complex workloads. Simple and isolated tests don't mean much.
Sometimes my server is idle. Other times it may be sending or receiving email. It may be compiling a program. One's mileage may vary. My 500-700 Kb/s DSL line may be a bottleneck.
Using a tool like Fiddler, the thing that strikes me is the amount of asynchronous activity going on over the wire now, at sites like Yahoo, Facebook, Google, and MSDN. A response to a login request may trigger something like 86 asynchronous requests - some triggered at regular intervals. They evidently use persistent sockets.
Nathan.
midrange.com
