Connection/statistics

Archived Topics
1

First off I dont recall the exact menu option. I know it is under the connections tab and it has to do with statistics. It is a window pane that show avg. exection time and thing such as this. What I am wondering is:

  1. How does these setting affect the running and collection of FSQL?

  2. Where in the manual can I find the exact information concerning these, what affects them, what is considered optimal, etc…?

I am curious about these just to make sure I have the system optimized for best performance.

2

In FactorySQL, connection->service status provides good information about groups, OPC tags, and performance. The performance indicates group execution times, delays, etc.

Unfortunately the “Service Status” utility isn’t yet well documented. I can tell you that the Avg Exec Delay should be close to 0ms. If you post your numbers we can provide you with feedback.

The other place to look is connection->System Status.

Your best SQLTags info comes from FactoryPMI. Look in the “Gateway Status Page” for an aggregate summary, or help->diagnostics, for per client statistics. FactorySQL also gives some information under the “SQLTags” section of the above mentioned “System Status”.

We’re in the process of running benchmarks. I would expect some performance metrics to be explained there.

[quote=“mrtweaver”]First off I dont recall the exact menu option. I know it is under the connections tab and it has to do with statistics. It is a window pane that show avg. exection time and thing such as this. What I am wondering is:

  1. How does these setting affect the running and collection of FSQL?

  2. Where in the manual can I find the exact information concerning these, what affects them, what is considered optimal, etc…?

I am curious about these just to make sure I have the system optimized for best performance.[/quote]

3

Here are my statistics from the page in question as requested.

Total Groups 103
Logging Groups 103
Active OPC Tags 4950
Total OPC updates 0

AVG Group Execution Cost 5.78mS
AVG Execution Delay 14.08 mS
AVG Group Efficiency 0%
Exec. Queue Length 0

The first two fields in the second group here change as things are running. I recall from one of my conversations with Travis that one of these items should be close to 100 to be efficient or something like that. But I dont recall which one and I dont recall what affects it.

[quote=“nathan”]In FactorySQL, connection->service status provides good information about groups, OPC tags, and performance. The performance indicates group execution times, delays, etc.

Unfortunately the “Service Status” utility isn’t yet well documented. I can tell you that the Avg Exec Delay should be close to 0ms. If you post your numbers we can provide you with feedback.

The other place to look is connection->System Status.

Your best SQLTags info comes from FactoryPMI. Look in the “Gateway Status Page” for an aggregate summary, or help->diagnostics, for per client statistics. FactorySQL also gives some information under the “SQLTags” section of the above mentioned “System Status”.

We’re in the process of running benchmarks. I would expect some performance metrics to be explained there.

[quote=“mrtweaver”]First off I dont recall the exact menu option. I know it is under the connections tab and it has to do with statistics. It is a window pane that show avg. exection time and thing such as this. What I am wondering is:

  1. How does these setting affect the running and collection of FSQL?

  2. Where in the manual can I find the exact information concerning these, what affects them, what is considered optimal, etc…?

I am curious about these just to make sure I have the system optimized for best performance.[/quote][/quote]

4

Don’t you ever sleep?

5

Of course I sleep. What kind of question is that? Sometimes when I am at home I come up with an idea or something and I jot it down. And some of the things I know that I dont have the required knowledge. So I post a question either here, PLC or both. Then the next morning I check and see what has been posted. Just remember I am on Easteren Standard Time.

6

I think he only said that cause your message was timestamped 4am, but I think that’s our server here, so 7am eastern… not too unreasonable!

Anyhow, down to business…

The statistics facilities in FSQL are a bit dispersed right now, and we’re trying to consolidate and enhance them. As for the values you posted, the most important/telling are the Avg. Group Execution Cost, the Delay, and the Queue Length.

Group cost: on average how long a group is taking to execute. Good indicator of how the database is acting, because the database queries are by far the biggest cost in executing a group. Any value under 100ms here is good, 5ms is extremely good. HOWEVER, this number can be thrown off by a lot of groups that run on triggers and aren’t triggered often- they get “executed” each cycle, but do very little work.

Execution Delay: on average how long a group has to wait from the time it’s due to execute to when it actually occurs. 15ms is about the normal overhead. Values above that, like on the order of 500ms-1sec+ indicate that either things are running slowly or there are too many groups running at the same time, so they end up waiting for their chance.

Queue Length: Very related to execution delay, it’s how many groups are waiting to be executed. That is, they’ve come up due to run, and now they’re waiting to be executed ASAP. This should basically always be 0. You might randomly catch it at 1. But if it’s more than that, it means things are backed up.

The biggest thing that causes backups is to have many many groups running relatively quickly. (.5 sec, 1 sec). The groups get into a scheduled queue, and when they’re due to run, they get put in an exec queue. If everything’s running at 1 sec, but the collective groups in the queue take longer than that to execute, those numbers up there are likely to change.

Now, I happen to know that in your particular project almost every group has a trigger, and that it doesn’t occur particularly frequently (I wouldn’t consider 5sec frequent). Therefore, the groups are doing very little work, and long story short your project is very efficient.

Hope this sheds a bit of light, like I said, we’re always trying to improve our statistics/troubleshoot facilities, and I think the next main release (4.2) will help this a bit.

Regards,

7

I have the same problem as you Martin, cant sleep when I have an idea. Anyways, on my new server, our avg exec times are about 1/3 or my old hardware, so the server hardware and config will help. Saying that, my times are about the same as yours, so I’d say youre good.

8

Colby thanks for the info and also thank you Kyle. I will be calling and hope to talk to you Colby to get a little more insight on things. If I dont get you then maybe I can get ahold of someone else.

And I hope I dont offend Nathan. It was I was trying to make a funny and it might not have come across as that.

Have a great day.

9

Oh, don’t worry, you can’t offend him so easily. Years of dealing with us responding to all of his feature requests have tempered him, I think.

But good thing, cause believe it or not SQLTags is an idea he came up with about 3 years ago! (took him that long to explain it to us :laughing: ok, sorry Nathan)

10

Can't think of anything that might have come off as offensive. Nope, you're doing fine. I was joking about the sleep thing :wink: - usually industrial guys take that as a complement.

5:41PM, 4:03AM (PST)...I guess that's not that crazy in Eastern - I've been known to do much worse.

I'll call you tomorrow about checking out your system for performance metrics per your PM on Mrplc.

[quote="mrtweaver"]Colby thanks for the info and also thank you Kyle. I will be calling and hope to talk to you Colby to get a little more insight on things. If I dont get you then maybe I can get ahold of someone else.

And I hope I dont offend Nathan. It was I was trying to make a funny and it might not have come across as that.

Have a great day.
[/quote]

11

yeah - I’ve got my pee-pee slapped more times than I care to admit. But you should see my feature requests; some of 'em have been pretty wild - all totally necessary :wink:.

But the guys certainly made SQLTags pimp-tastic! I think Colby may have even been the mastermind behind the name.

[quote=“Colby.Clegg”]Oh, don’t worry, you can’t offend him so easily. Years of dealing with us responding to all of his feature requests have tempered him, I think.

But good thing, cause believe it or not SQLTags is an idea he came up with about 3 years ago! (took him that long to explain it to us :laughing: ok, sorry Nathan)[/quote]

12

:open_mouth: WTF? This is a PG-13 forum.

13

:open_mouth: WTF? This is a PG-13 forum.[/quote]

Humm....I think I'm ok...

maybe borderline...couldn't be much worse than a [quote="Carl.Gould"]WTF[/quote]

A PG-13 rating is a sterner warning by the Rating Board to parents to determine whether their children under age 13 should view the motion picture, as some material might not be suited for them. A PG-13 motion picture may go beyond the PG rating in theme, violence, nudity, sensuality, language, adult activities or other elements, but does not reach the restricted R category. The theme of the motion picture by itself will not result in a rating greater than PG-13, although depictions of activities related to a mature theme may result in a restricted rating for the motion picture. Any drug use will initially require at least a PG-13 rating. More than brief nudity will require at least a PG-13 rating, but such nudity in a PG-13 rated motion picture generally will not be sexually oriented. There may be depictions of violence in a PG-13 movie, but generally not both realistic and extreme or persistent violence. A motion picture’s single use of one of the harsher sexually-derived words, though only as an expletive, initially requires at least a PG-13 rating. More than one such expletive requires an R rating, as must even one of those words used in a sexual context. The Rating Board nevertheless may rate such a motion picture PG-13 if, based on a special vote by a two-thirds majority, the Raters feel that most American parents would believe that a PG-13 rating is appropriate because of the context or manner in which the words are used or because the use of those words in the motion picture is inconspicuous.

mpaa.org/FlmRat_Ratings.asp

14

Nathan, I think you may want to check for a gas leak in your building…

15

I think you're right...

16

lol what the hell happened to this thread.

17

Sorry Martin - I hijacked your thread and got a little nutty. Back to being “(reasonably) professional Nathan”…

18

No problem. I enjoy a little nuttyness every now and then. It lets us know we are still human. Take friday, I have a kind of apprentice working for me. He will take the electronics position and I am going to data processing. A fairly nice change. But anyway I was kind of in a jolly jovial mood and was going around singing songs from my favorite artist John Valby. He goes under the stage name Dr Dirty. Quite interesting songs. But it was just one of those kind of days.

Anyway I do have some questions that I am hoping someone might be able to answer.

  1. Is there a way to determine wire time? (I hope I have this term correct, what I want to know is how long it takes for my data to get from the PLC back to the PC and into the SQL table)

  2. If I have 40 tags going back for historical data, 2 are 20 char ASCII strings, 3 are 4 char ASCII strings, 24 are boolean bits and the remaining 12 are DINT. Would it be more efficient to use a standard group or a block group or it would not matter? I am using a trigger, this is why I am curious about wire time. I want to know that the data is stable then in FSQL when the trigger goes active it correctly grabs this data and sends it to the SQL table.

This kind of goes as follows. On the PLC we are using there is a compact flash card. THe same time that the data is written to the compact flash it also sets the bit that triggers the group to read the historical data and write it to the SQL table. Both the write to compact flash and the timing in FSQL for the group is set at the same value 1 Sec. However what we are seeing is that FSQL will read the same data and write the same data twice so you end up having dupe records in the data base. When it does this it sometimes misses the next event record. I am thinking it probably is takeing more than 1 second to read all the data from the PLC and that when the trigger goes high a second time within a two to three second interval that there is not enough time to read the data so it writes whatever was there last. I only think this because we did a study on friday where we ran the machine and recorded all the data. then we dumped the data from the compact flash and checked it with the manual form. This was 100% good. However when we checked it against the SQL table there were flaws.

One other option that I am thinking might work well would be to have FSQL do the time stuff. That 20 char ascii is a date/time stamp and proveds a span of time. Instead of doing it at the PLC just monitor the bits and have some sort of script or something that would do the same thing. This way that amount of data would not require as much wire time. It takes less to read a bit than it does to read a string. Or at least I think so. Not sure. A couple of other areas that read the strings might also work well doing it as a bit and having FSQL convert it. Any thoughts on if this would be better, same, worse, etc...

Just trying to get all data validated so we can continue to move forward with this project.

Sorry Martin - I hijacked your thread and got a little nutty. Back to being "(reasonably) professional Nathan"...[/quote]

19

Mrt-

These are very good questions… but for the usefulness and coherence of the forum, I think it’d be better to start a new thread since these are way different than the original topic (not to mention this thread has already become pretty convoluted!)

Anyhow, I’ll leave the question here and create a new topic called “Data transfer timing”.

Regards,