Jump to content

Flarb

Newbies
  • Posts

    4
  • Joined

  • Last visited

Everything posted by Flarb

  1. Thanks for the insight. The stakeholders claim to expect 300 concurrent users in the near future. Currently they're at 220 concurrent users, although "concurrent" truly means "idle 99% of the time" as you know. Still, the stakeholders insist on setting up a test environment for some worst case scenarios. That would be 300 moderately active users. My approach, using a bunch of VMs, would take a lot of hardware, so thats why I was asking if there was another, a better way to simulate 300 from one machine. If my suggested method is in fact the only way, then I need to know it, so I can request X more computers. But I wanted to double check here, because in the web, java and SQL worlds, a tool can be run on just one single computer that'll accurately simulate 100x+. Any ideas to accomplish this for us FileMaker folks would be welcome. Let me know if by bad idea really is the only way. Many thanks!
  2. Hello folks Today I am tasked with showing performance metrics: We need to see how FileMaker Server responds to 300 users performing intensive tasks simultaneously. For example, finds, sorts, new record creation and so on. I have a test bed of scripts which loop and perform such tests, such as creating lots of records and populating them with dummy data, and so on. Now I just need to figure out a way to have 300 FileMaker clients perform these tests simultaneously so I can monitor server metrics. I do not have access to 300 real machines. The only case I can come up with is to use multiple Virtual Machines. Within each VM, runs a copy of FM14, FM14 Advanced, FM15, and FM15 Advanced. That is four quasi realish"clients" I can put to work running my intensive scripts simultaneously. And, ram permitting, I can have about ten such VMs, resulting in a total of 40 quasi-real client instances. Granted, this skews network latency, this is a known downside to this approach. But I need 300 anyway, not just 40, and I am out of hardware for testing. I am limited to a single Mac Pro with 128GB ram. Is there a different way to simulate 300 users performing my intensive scripts simultaneously? Do I ultimately need more hardware to create the simulation?
  3. Thank you Wim for the excellent information. As to where, we have been privately pinging some other developers and FMI to get extra input. Because the input has been quite dynamic, I've posted it here for extra input. I tend to agree with your assessments, right on, it's in line with a couple of other top developers. As for the RAM disk, I would never dream of running a system-level (OS X for example) ram disk in production. Specifically, the relatively obscure TMS RAM-SAN 440 is a dedicated hardware box with its own internal battery bank, system controller, and an internal standby SSD RAID which receives a RAM dump in case of power failure; a dedicated hardware unit that shows up as a curiously fast hard disk to the system. The fastest enterprise SSD boxes from IBM available today boast a 150/190 read/write µS latency; while the RAM-SAN 400 boasts a 14µS r/w latency. We figure that ten+ times quicker on latency could help make a dent? Agreed with splitting the file, purchasing and then splitting across more processor cores. Which brings me to Question 4) The powers that be may want to purchase a new 56-core system, and use VMWare to run a bunch of instances of Windows Server 2012 R2 + FileMaker Servers. Has anyone had a net positive experience with this approach, as opposed to say, a deskfull of Mac Pro cans with an equivalent number of cores, not virtualized, running normal OS X and FileMaker Server instances? We've been reading of mostly negative experiences with the VM approach thus far. Thanks again!
  4. Objective: We want to make the whole solution faster, for both web and local FMPro users. Here's what we are working with: - Machine 1: FileMaker Server 14, Blade server with 512GB ram, 1TB SSD, running Windows Server 2012 R2, intranet connected only, main machine. - Machine 2: iMac, runs Admin Console only. - Machine 3: FileMaker Web Engine 14, Mac Pro with 128GB ram, 1TB SSD, running El Capitan, intranet and internet connected, exclusively for web. - FileMaker file is a single file at 14GB, no data separation currently, containers are stored externally. Let's assume that the file's inner workings are optimized and that we are here to discuss server deployment, server specifications, and server settings. - FMPro simultaneous users: ~100. XML and PHP total Web simultaneous connections: ~50. Question 1a) Would there be much benefit to setting the Server Cache from its defaulted 512MB, to 490GB (yes that's GB)? We see 99-100% cache hit when at 512MB. We see consistent 100% cache hit when at 490GB. Disk access is orders of magnitude less when cache set to 490GB, almost none. Question 1b) Would there be any penalties associated with the above setting? For example, we've heard that regular backups would be missing the latest data changes unless the Progressive Backup feature is used. We've also heard that should the server crash, more data would be lost (except for the backup, of course). We've also heard that FileMaker Server has to use more CPU time to "manage" such a large cache, resulting in less performance, not more. Any of this rung true? Any other penalties to consider? Question 2) Would breaking the file up into data separation model, smaller chunks, net any performance benefits? Question 3) If using a smaller Server Cache (say, back down to 512MB), would the system benefit from a RAM DISK (such as RAM-SAN 440) instead of an SSD, and give net better performance than the crazy big Server Cache setting? Observation: 512MB cache makes FMPro clients faster, but web slower. 490GB cache makes FMPro clients slower, but web significantly faster. Observation: FM Inc and one consulting firm tells us to set the cache to 90% of this server's ram capacity. Other experienced developers tell us to "manage" the cache at a much smaller number, paying mind to the cache hit percentage. What say you? Thank you for any insight, folks!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.