This content has been marked as final. Show 6 replies
Hello haXbat,1 person found this helpful
I don't have serious differences between Listener and EPG on my test box. Is your Listener running on the same machine as the database or have you distributed it? In my scenario, both are on the same host. Of course you get additional round-trip times if you put the Listener on a separate host. Depending on the latency between that host and your database server, this might already be the explanation. Also, there might be higher latency from your client to the Listener's host than there are from your client to the database server.
For details on caching, see the installation document for the APEX Listener. More specific answers on that issue require some additional information on your usage scenario(s).
My listener is running on the same machine as the 11gR2.
As I have understood there is no need to use listener instead of EPG for development apex application purpose.
it's odd that you get such a high supplement for round trip times when running the Listener on the same machine as your database. Do you see any heavy load on your server that could explain that? Or is your unit "ms" micro seconds instead of milli seconds? I wouldn't say it's bad performance then. ;)
If you just use "plain APEX", there should be no need to use the Listener instead of EPG.
But the APEX Listener will get additional features with upcoming releases which won't be available for EPG. On the other hand, there currently also exist features you can configure on EPG that aren't available on the APEX Listener.
So I'd at least test with the Listener from time to time to be sure everything will run as expected in case you plan to run with the Listener in your production environment.
One thing to look into as well is what type of servers your running your setup on as some types require you to split it up. A good example is the Niagara chips in Sun servers. My understanding is it is the way the servers multi-thread. If you have x threads running then on this particular chip family, each thread gets exactly 1/x of the processor speed to execute its instructions. We cannot run our Database and Listener on the same box or it brings the server to its knees. It is kind of a balancing act here because we have run both configurations in the past. Might also want to check to see if your particular server does something interesting like this.
I thought about that as well, but the scenario doesn't look like that for me. From what I read, we talk about a development machine, so the number of concurrent threads should be limited. The roundtrip time for the EPG seems to include network latency. One of our customers has a Niagara system, but process switching times aren't so bad that you come to milliseconds of delay. Sure, the effect would be immense on systems with high load. That's why I asked about the load level. If you really have some issue with process/thread switchting, you'd probably see it there.
Ironically, I saw the same thing happen here on a development box with 1 user connected. In this configuration I have a Sun T1000 with 1 11gR2 DB and 1 Weblogic Server (Yes, I know this config is not optimal but at the time I did not have a spare box to put the DB on that was separate) and the performance of Weblogic hit the toilet with the db online. You have to also consider that it is not number of users but also number of threads executing. There will always be some number of threads running such as the db listening for clients, weblogic listening for clients, operating system operations in the background, etc. Like I said though, it is worth a look.