1 2 3 Previous Next 38 Replies Latest reply on Nov 2, 2016 8:36 AM by wimdecorte

    Practical Question -




      I have a Order Entry app that will be hosted in a server with 5 clients over LAN.


      The orders from customers usually flood in during a 3 hour window - this takes the joint effort of 4-5 people manning the phones and entering the orders into the system.  It is important that there be zero lag due to high volume.


      During other times the performance demands are minimal.


      Given today's technology(Oct 28th 2016,) what do you guys recommend as the best practical set up to insure performance is decent?


      I am not necessarily constrained budget-wise, but don't want to go overboard...


      The following examples are made up from my rudimentary understanding(and reading tons of community articles), so please forgive me if it seems to lack understanding! 


      For sake of simplicity, I want to only consider Mac servers.


      1) Mac Pro or iMac as the server (Mac mini is becoming weaker by the generation)  Are there benefits from using Xenon (in my context) or something lower is fine(e.g. quad-core I5)?

      2) Gigabit Ethernet connection between server and client - but my guess is everybody has this nowadays?

      3) Speed of read/write--> Is SSD is sufficient for my needs above, or, use the latest Mac Pro has something even faster called ("PCIe-based flash storage")

      4) Clients may be Mac or PC with little difference (provided they are decent.)

      5) PSOS (server script) utilization makes a difference if using the latest Mac Pro or iMac?




      Thank you.


        • 1. Re: Practical Question -

          Hmmm, sounds like you are taking orders after an infomercial airs...


          A fast server, the faster the better with lots of RAM is a a good idea. About how many orders are you likely to receive during that window?


          I don't think that PSOS is likely to help for basic data entry tasks like taking orders.


          An "if all else fails" scenario would be to have the order takers take down order information locally in a file on their machines and after the traffic dies down, a "synch" uploads the data as a batch to your server. I wouldn't do that unless absolutely necessary, but it is an option that totally divorces any performance issues during that "rush" period from being due to server or network issues.

          • 2. Re: Practical Question -

            Others here will give better answers than I regarding I/O and hardware, so I'll let them.


            One thing I've run into is human lag...specifically on an order entry system.

            Going field to field filling out info leaves all the data in "stasis"...uncommitted.

            As you design the work flow, keep in mind which particular data fields affect other users, and take care to commit that data ASAP.


            We've had on instance where we had 1000 parts...and they got promised to three different customers within a 20 minute period.  The first one to promise them was still filling out other details (like ship to, billing info, special packaging, etc.) when the third one promised them.  The "oops" flag didn't show up until the data was committed.

            Commit early, commit often...especially when it is a fast paced multi-user work flow.

            • 3. Re: Practical Question -

              Hi philmodjunk,


              That's a humorous, but not too far off from the mark, description!


              There is a nuanced difference: instead of 'millions' of people calling in to order a single item, there is maybe about 100-200 customers(who are retailers) ordering anywhere from 100-250 order line items.  Each 'order line item' comes from a 5K+ item catalog, so rapid look-up is also important, but I think this should give you an idea of the performance requirements?


              BTW, I never considered RAM as a performance booster, thanks for that advise.   Do you think a used Mac Pro (previous gen to the current 'trash-cans') with SSD and 64GB RAM would be a 'smart' solution, with high bank-for-the buck?


              Also, the last solution you suggested is very elegant - is the execution not too hard for a newbie developer like myself?   Can you provide with where I can read up on that 'delayed synch' solution?


              Thanks much!

              • 4. Re: Practical Question -



                That is a great advise from a multi-user work-flow design perspective.  Nothing is as embarrassing as telling the customer when they just put in high-quantity order that it was a 'mistake'... Looks like I have to write well-thought-out validation rules accompanied by frequent commits as the user goes from one field to another in the order entry screen.  Another learning curve for newbie developer like myself...


                On a related note, if I commit often, would that add to the 'tax' for additional resources in a typical FM setting?


                The mandate I was given was: "Thou shalt have zero-lag during the order entry frenzy..."  So if frequent committing adds to resource requirements, that would be nice to plan for.  I am thinking this process needs time for data to travel from client to server and perhaps back?  Also the time to save frequent commits to the disk can add up?


                Thanks for your valuable advise!



                • 5. Re: Practical Question -

                  I will leave hardware advice to others.


                  What you lose from the "synch method" is something that Eric touched on--you lose any inventory level info as to whether you have sufficient, not yet ordered stock on hand to fulfill an order or not.


                  But since this would be a "one way" flow of new records to the server, this can be a simple Import Records step that imports both the invoice and related line item records into tables on a file hosted from your server. This is a step that can benefit from PSOS BTW.


                  There are third party synch tools such as those offered by 360works and SeedCode, but I don't think that you'd need them in this case. But keep in mind that I wouldn't use this option unless I had no other choice. Simple, rapid data entry from 5 users should be well within the capabilities of a server hosted solution. They simply won't be able to type and click fast enough to seriously challenge a properly designed solution.


                  If you don't need to worry about inventory levels, you could even set up the local machines with a copy of your "catalog" so that you don't have to keep pulling sets of those records over the network to your client machines and then you just enter invoice and line item data into your hosted files.


                  Also, be prepared to make a major investment in time and though in how you process each order. There are a wide variety of ways that you might use to quickly select the item being requested by the customer in order to achieve both rapid and error resistant data entry while serving each customer over the phone.

                  • 6. Re: Practical Question -

                    user28222 wrote:



                    BTW, I never considered RAM as a performance booster, thanks for that advise. Do you think a used Mac Pro (previous gen to the current 'trash-cans') with SSD and 64GB RAM would be a 'smart' solution, with high bank-for-the buck?



                    Of the 4 potential bottlenecks (processing, disk i/o, network i/o, memory), memory is the one that gives you the least performance boost.  You won't see any noticeable difference by picking 64GB over 32GB unless you will go wild on PSoS and WebDirect.


                    You have to pick the machine for the peak load, even if that means that it will sit nearly idle for the rest of the time.


                    Go with fast SSD

                    For processing power: it's a balance between CPU speed and # of cores.  In your case since you only have about 5 users, pick something with say 6 cores and as fast (GHz) as you can afford.

                    Big caveat: the speed vs. core decision is hugely affected by the design of the solution and how it is used.

                    • 7. Re: Practical Question -

                      Thanks Wim,


                      For the other two potential bottlenecks (network and CPU):


                      1.  Gigabit Ethernet connection should be more than enough for peak load scenario like mine, in LAN set-up?


                      2a.  Does using a server cpu (eg Xeon) make a difference compared to, say i7?   Both have multiple cores and the i7 might even have better single-core performance, in my very simplified view, so what is the difference (in the context of my needs)?


                      2b.  High performance cpu 2-generations ago is preferred to current gen mid-upper-tier cpu?  This is a performance/dollar consideration.


                      Thanks alot for your help - truly appreciate it!


                      • 8. Re: Practical Question -

                        user28222 wrote:


                        Thanks Wim,


                        For the other two potential bottlenecks (network and CPU):


                        1. Gigabit Ethernet connection should be more than enough for peak load scenario like mine, in LAN set-up?



                        FMS has a stats.log (it's off by default); I would strongly recommend that you turn it on and collect some good info about your current deployment.  The stats.log has numbers on all 4 potential bottlenecks and will help you make decisions based on reality, real numbers.  Including the actual network throughput.


                        user28222 wrote:



                        2a. Does using a server cpu (eg Xeon) make a difference compared to, say i7? Both have multiple cores and the i7 might even have better single-core performance, in my very simplified view, so what is the difference (in the context of my needs)?


                        Xeons are meant for servers whereas i7s are meant for workstations and it translates into a number of differences.  Xeons for instance are supported on motherboards with multiple sockets so you can add more processors to the same motherboard.  Xeons support different types of RAM that are higher performant and Xeons are built to withstand longer sustained high loads.  Like with any server-class piece of hardware, it is built stronger and has less chance of failure.


                        Don't know enough about the uptime requirements and design of your solution to say which one would be best.

                        If you are going to stick with current Macs it is a moot point because you don't get much choice nor a lot of flexibility in upgrading (like adding an extra processor to the motherboard).

                        • 9. Re: Practical Question -

                          Let's not lose track of two things:

                          1) we are only talking about 4-5 users taking orders

                          2) the "catalog" Isn't all that large at 5,000 items


                          Even with highly trained users with very fast typing speeds running frequent catalog queries, that just isn't going to put that much demand on whatever system you are going to put together for this.


                          The quality of your database design both in terms of interface and data model will have far more impact on the success of this venture than your hardware.


                          I make two more recommendations:

                          Get a consultant with a thorough understanding of FileMaker to design this--someone who can talk to some people who have experience manning the phones for this if possible.


                          After your solution has been created. Do a full scale dress rehearsal where your 5 order takers are each handed a script of fictitious orders to use during the practice run. This can identify any unexpected bottlenecks whether they be due to training, interface, data model, or hardware. End the session with a group discussion where everyone can comment on the process and offer suggested improvements.

                          • 10. Re: Practical Question -

                            Thanks Wim.


                            Based on my using Mac's for server role, and given the lack of configuration options (did not hit me until I started this discussion thread that Apple is de-emphasizing the server market for business reasons) I will attempt to trial run it with an iMac or a used Mac Pro(say 5,1.)   Other than being a dedicated host for FM server and related-backups, there are no other roles planned, hence I am considering iMac's!


                            Also, to philmodjunk's point, it is a relatively simple app - we just want to avoid lags during those order hours.  I also agree with the point that trial-runs will inform the final design of production system.


                            I will give a follow-up update on my final decision for configuration for FM Server as well as performance outcomes.


                            Thanks everyone - it was very helpful and educational!



                            • 11. Re: Practical Question -

                              One other thing to consider is, if there is a day or time of month that is slower, to use that time put it in to service.

                              • 12. Re: Practical Question -

                                Hi greatgrey,


                                Do you mean, for example, use the non-peak times to do calculations and other updates?  That is a great idea.


                                Looks like my work is cut out for me as the designer...

                                • 13. Re: Practical Question -

                                  Not what i was thinking of, not bad idea.

                                  What I was thinking of was if a day of the week had a lower peak order volume to use that day to change over to the new solution. i.e. Saturday has only 100 orders come in during the peak time instead of 200 orders.

                                  • 14. Re: Practical Question -

                                    You don't have a lot of users, so unless you have a sloppy and inefficient database, even a Mac Mini with SSDs would be fine.  However, keep in mind Mac Mini's are all consumer level hardware and that is why Mac Pro's cost more (as well as enterprise level Windows servers).  If you want a robust server, then I would only consider the Mac Pro.  There are some nice other advantages of it including have multiple ethernets which is useful if you want to segregate your LAN and WAN connections which can really improve network performance.  Unless the database is really huge, you probably only need 8 Gigs of RAM, but I would go with at least 16 just for comfort.  But as noted above, RAM won't change speed much unless there are a lot of users, particularly WebDirects users which you are not doing. 


                                    The biggest disappointment to choosing a Mac Pro is that it and the Mac Mini are the two oldest Mac hardware that haven't been updated in years and many people thought something would come out with last week's Apple announcement replacing them.  The assumption is that in the near future those will either be upgraded or discontinued.  Many of us are hoping new versions will be out soon.  The bummer part is that you are looking at hardware now and it always is disheartening to buy say a Mac Pro just before the new version comes out next month.  Then again, we've been waiting since 2013 for the upgrade and it may be years before the next one comes out or Apple could pull an xServer scenario and discontinue the Mac Pro, which would make me very unhappy.  My personal guess is a new Mac Pro will come out at WWDC in 2017.  But that is a complete guess with nothing to back it up. 


                                    Even though the Mac Pro is long in the tooth, my recommendation is for you to get an entry level Mac Pro with 16 Gigs of RAM (Quad-core) $2999.  That will give you a lot of long term reliability and very fast storage. 

                                    1 2 3 Previous Next