Video and Connectivity issue.

[nelsona]

We recently updated our application to ES5.1 and are noticing some issues we are unsure if they are related to the update but since these areas where untouched we wanted to know if ES5.1 may cause conflicts with live streaming rmtp feeds , since it has support for them would we need to change the port of the rmtp on es5 even if we are not using it.

The reason i ask is because we notice in the video feeds we have they seem to be freezing up after a short period of time. I want to add we are using an external rmtp server for the feeds not using the ES5.1 built in video support.

Additionally we notice after about 40-50 users the initial connect time to ES5 for the client application increases, is there any tips to improve the initial connection.

Hope I provided sufficient information for some basic answers or guidance on these issues.

Thanks in advance.

[tcarr]

If you are not using ES5 for your streaming, I would suggest that you delete that gateway listener.

The freezing could have any of several causes. It might be the JVM garbage collector kicking in, which can be fixed by adding the right command line option to the General Settings tab. It might be that all the ES5's threads are tied up waiting for HTTP calls or database calls. It might be a bottleneck in the bandwidth, particularly if the same host is doing live streaming.

By "initial connect time" do you mean time before the login finishes or time including the login? Because your application has an HTTP call in the login event handler, so there will be problems if either the server that responds to the HTTP call is getting slow, or if all the threads are tied up in HTTP calls. If during this time of increased "connection time" you also notice that it takes longer for other ES5 activity, then it's a case of all threads getting tied up (or too much streaming). If it's only those logging in who notice a problem, then it might be that the other server is being slow.

The first thing I'd try is specifying a JVM garbage collection scheme. I'll look up the one I know works well.

[tcarr]

On the ES Admin's General Setting screen, in the Command Line Parameters, add the following:


-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode


Check the box right above it, which specifies the amount of RAM that the JVM uses. Odds are good that you want that to be about 1024 or higher, depending on total RAM for the box running the ES5.

After making changes, click the Update button and then restart ES5. If you have any problems restarting and can't get into the ES Admin because of command line changes, kill the process then start using safe mode (which ignores the amount of RAM and command line parameters that are specified by the ES Admin) so that you can get into the ES Admin to revert your changes.

[tcarr]

An alternate that is supposed to be good that I haven't had personal experience with is the "-server" command line parameter.

[nelsona]

Thank you for your suggestions we are trying them now on our development server. Also do you have a recommended thread setting for a QuadCore Server having 8GB of Ram. We currently have the heap size at 5GB, do you think that is to high / low and what are normal ram usages for an average 50 users under ElectroTanks normal running parameters.

[tcarr]

The amount of RAM needed varies enormously depending on the application, however I would think that 5 GB would be far more than you need if you have less than 1000 ccu, and would normally expect 5 GB to be enough for about 7K ccu, assuming you don't keep an enormous amount of data in memory (for example, some applications will load the entire user database into memory and keep it there, to save time with database calls).

I'm not sure what you mean by thread setting. If you refer to the Thread Settings screen on ES Admin, it is usually a bad idea to touch any of those settings. If you still have problems after setting the Garbage Collection parameters, then we would need to look into using a second thread pool for the HTTP calls. See Threading in Plugins (http://www.electrotank.com/docs/es5/manual/threading_in_plugins.htm). I have an example that will be released with the next version of ES5 that shows how to do a two stage login process with a second thread pool, and an external MySQL database. I can zip that up for you if you need it.

[nelsona]

Okay going back to the connectivity issue. Have you ever encountered an issue with initial connection only on certain browsers and if so what would you think would cause this.

For example I noticed that in Internet Explorer we rarely see any initial connection issues where in chrome it hangs. I know its not alot of detail but its all i can see at the moment, with the issue and maybe its something that may point out or help us see whats happening.

I took a look at the load between the different components like the database, website xml-rpc server and everything is basically sleeping at 40 users nothing appears to be causing extra latency and with the browser test it feels as if its something else all together.

What are your thoughts?

[tcarr]

Check the settings for your database and xml-rpc server. Your particular app has to validate from that before it tries to connect to ES5. I don't have experience with xml-rpc servers, however I do recall one or two ES4 applications that would refuse to work after 40 users because they created a connection to the database and then never released that connection, and the database's default was set to only allow 40 connections. Changing that particular project's code to release the connection after getting the result fixed the problem.