I noticed that FSQL supports a 64 bit windows os, but does FPMI. I have not seen it explicitly stated anywhere. Also, other than allowing for more useable ram, is there a speed advantage?
Kyle,
You can download a 64 bit Windows version of the Java 6 JRE from java.sun/com. My guess would be that a 64 bit Windows machine would have no problem running a FPMI client - I’m not sure about the service. Carl should be able to answer both questions definitively.
As to choosing 32 versus 64 bit Windows - there are advantages and disadvantages to both. At this stage of the game, you’re probably much better off using 32 bit Windows. Do you want to use > 4 gigs of RAM? In theory 64 bit instructions could make your optimized application run faster - if it was supported by your CPU, program, and OS. In practice you’re probably running 32 bit apps in emulation mode, which will be slower. For the time being I’d recommend using 32 bit Windows.
en.wikipedia.org/wiki/64_bit#Cur … hitectures
Is there a problem that you’re trying to solve or are you just curious?
I can say that from the FactorySQL side, the “Win64 support” that came in the last version is more of a compatibility issue than a performance one. I wouldn’t expect any great benefit from switch over to win64- FactorySQL actually still runs in 32-bit mode.
PMI should run fine on a 32-bit JVM installed on Win64, but I’m not the expert on that side…
Regards,
Don’t think you’d do that (Emulator to run a virtual machine) with Java when they have a 64 bit version (that probably runs emulation mode anyway). Who knows? We’ll have to ask the expert…
btw all the search results I came up with about 64 bit Windows Java performance said slow (not true of other 64 bit OSes, which were bounded by the 32 bit ones).
[quote=“Colby.Clegg”]PMI should run fine on a 32-bit JVM installed on Win64, but I’m not the expert on that side…
[/quote]
Im just wondering because we are buying new servers in the new year. Just wondering if i should get a copy of the 32 or 64 bit edition of Windows Server 2003. If i go 32 bit, then im thinking some sort of xeon quad core, 4 gb of ram, and a raid 0+1. Just trying to create a stable server to run FPMI,Kepware,FSQL and MYSQL.
Kyle,
This is pretty “dreamy” here - to illustrate priorities in performance. Your system may be different. Check the FactoryPMI metrics, process CPU usage, and process memory for your actual performance numbers.
Those specs are more than enough to take you into the new year. I will be recommending a Scale Out approach using multiple computers over a Scale Up approach of upgrading your one system. I’d recommend the 32 bit version. We should do 64 bit benchmarks. If you’re beginning to push your system performance, your best bang for your buck by far will be to split the SQL database on to its own separate machine. Running a high speed connection (ie Gig E) between the Gateway and SQL database would be a good idea too - that also could give you an additional layer of security since you could device the system such that your clients can’t talk to the SQL database directly - which is secondary to clients not being able to communicate with PLCs over the same network. But I digress, we’re talking performance, not security…
The next step for performance would be to consider separating out your SQL databases for special purposes like historical data. That way a separate machine is running the huge queries that are generating reports or querying graphs for millions of data points. This is how web sites like amazon.com expand - it’s called a Scale Out approach.
You may also want to separate FactorySQL from FactoryPMI on separate machines. With SQLTags, I have a hard time seeing this as a “real world” requirement. Additional FactorySQL machines can split the work load and provide fault tolerance. Additional FactoryPMI Gateways will automatically load balance clients, lightening up each Gateways load and providing additional fault tolerance.
I would use my most powerful computer to run the SQL database. I would use the second and optionally 3rd to host FactorySQL/FactoryPMI/OPC Server. Depending on your project, you may add additional SQL databases. Those mighty specs (maybe less on the CPU end) would do great for your SQL Server machine. A fast Core 2 Duo with 2 or 4 gigs of RAM with a small RAID 1 (mirroring) array running XP would be more than enough for the FSQL/FPMI box(es). Keep in mind that tweaking/configuring your SQL Server may get you just as much of a performance delta as throwing hardware at it.
To recap:
- Separate SQL Database to most powerful machine
- Consider moving historical/specialized data to another separate DB
- Consider separating FSQL/FPMI and optionally adding nodes of either
Make sure that you have the network pipe on the backend to support it. An 8 port gig-E switch (or VLAN), a few cards, and some pieces of Cat 6 cable are cheap now days. You’d use a separate IP subnet for that and ensure that FSQL/FPMI datasources are set to communicate over those.
Alright, so after our server caved today, went ahead and ordered a Dell R200 server, with a 2.66 Ghz quadcore Xeon with 8mb cache, 4 gb of ram, and 2 - 300Gb SAS drives going to a controller card. Also has 2 GigE ports. Its a 1u server, which should last for a while. I was gonna do a 2 machine setup, buit figured when we need to upgrade again, we can keep this machine as well. Installing into a 13u enclosed rack with a UPS and 24 port switch. OS is Win Server 2003 Std.
On a side note, we might keep our existing server (3.2Ghz p4, 1.5 gb ram, 120gb Raid 1) to run FPMI, as even running RSview32, FPMI,FSQL,RSLinx(will replace soon with Kepware thank god) and MySQL only uses on average ~35% cpu. Just future proofing now
Sounds solid - like a beast of a machine. There are many more metrics that you can look at, both on the FPMI gateway, FPMI client, and from within FactorySQL that will give you more meaningful info than CPU useage. Low CPU utilization is always a good indication, but high usage isn’t always necessarily bad. For example, run a program that just loops and you’ll probably show 100%. Run two instances of it and you’ll more likely get 2 at 50% each - you get the idea. Actual memory usage is a pretty good indication, but you can always allocate more for the Java VM, which makes it look like it’s using more (and is good for “future proofinging”).
You’ll see all the meaningful metrics when we release our official benchmarks. Things like average group execution time in FactorySQL and SQLTags throughput on the PMI side. Keep in mind that the SQLTags portion of your project scales extremely well with clients - I’d recommend opening up many runtimes (can be on the same machine) to see how it affects your performance. In my experience it will only be huge queries, typically from graphs/reports of lots of historical data, that tax your system.
Does your switch have GigE ports?
Yes, i agree, SQLTags scales very well, I had 10 clients open just the other day, as a test, and my CPU usage didnt budge at all.
As for my switch, we have a 24 port Zyxel 10/100 unmanaged switch. If i went the route for scaling out at this point, I would have purchased a GigE switch, but didnt think we needed it right now. Ill find a way to get one in there though. Any recommendations? Should we go Managed/Unmanaged/“Web-smart”
You’re probably fine with your existing switch. Often times they’ll have a single or a few gig ports, or have an expansion card for one. Nothing magical there - if you start regularly putting more traffic on that server than a 100 meg card can handle you’d want to upgrade. The “networking” tab of the Windows task manager on that server is a quick way to get a good idea of how much traffic you’re pushing. Of course, there are other better metrics as well.
I’ll post to my blog about managed switches in the next few days. They bring cool features to the table that may be useful for you. If you have a good IT department I’d go with their recommendations.
Right, that “scale out” approach that we described works really well with a separate (can be cheap) 8 port GigE switch for the segment between your servers. A single GigE port between FPMI gateways and clients (even 10megs would be plenty there) would never be bad either.