MGI 1.x FAQs

The MGI FAQ is a collection of questions that we have been asked about MGI and the answers to those questions. The questions involve every aspect of MGI EXCEPT technical discussions about individual tags which are found in the User's Guide.

If you have a particular question about MGI or PagePlanet Software feel free to email or call us. We will not only answer directly back to you, but we will also post the query and response here for the benefit of others. As the FAQ expands over time, we may actually even give it a structure; for the time being, questions are listed in the order in which they arrived.

Is there an educational price for MGI?

Yes. For all versions of MGI, the educational price is 20 percent off the listed retail price of the respective versions.

To qualify for the educational price, the purchaser must provide a faxed or mailed copy of a purchase order on University, College, School, or Departmental letterhead, though the actual purchase of MGI can still be conducted on-line via credit card through our secure server. For addresses and phone numbers to use in order to make payment arranagements, see our contact page.

Is MGI a database itself, or does it just interact between WebStar and a third-party database like FileMakerPro?

MGI is a self-contained database engine using NeoAccess by NeoLogic Systems build right into the heart of MGI. When you purchase MGI, there is no need to also purchase any other product to get full database functionality. And MGI is multi-threaded so it can handle many simultaneous database transactions without needing to queue up the requests and handle them one at a time.

PagePlanet Software released MGI 1.1 to the public. Where is version 1.0 and what is the difference between the two?

MGI 1.1 was the first release of the software directly to the public. Since September 1996 MGI has been developed and has been running on the servers of PagePlop Web Hosting Service for the sole benefit of our own hosting clients. Over that time, we have developed MGI and all its facets in direct response to what our clients needed to have their web sites work for them. So, in a sense, MGI 1.0 has been running for almost three years on our own servers while in development.

Will there ever be a version of MGI that runs on an NT or UNIX box?

Yes. MGI was written on the Macintosh platform for the Macintosh server. Now that we are done with version 1.5, we will begin work on MGI 2.0. The next version will be fully compatible with the Win32 architecture as well as Red Hat Linux and the web servers associated with both platforms (including Apache.) Our tentative schedule for release of MGI 2.0 for the NT platform is currently August 2000. The Classic MacOS version of MGI 2.0 will follow in September 2000. The Linux version of MGI 2.0 is scheduled for November 2000.

Will MGI run in conjunction with Tenon's Web Ten on the Macintosh?

Not at this time. We may make modifications in future Macintosh versions of the software to accommodate the users of Web Ten.

How much does Canada weigh?

We are calculating that figure and will get back to you shortly.

How do we keep up with any bug fixes? is the key. There are two primary parts of MGI that contain version numbers. There is the MGI server itself and each of the MGI plug-ins. All the plug-ins and the server were initially released as version 1.1. IF changes are made to any of the plug-ins, a new plug-in will be released with an updated version number. For instance, if someone finds a bug in mgiAuthenticate version 1.1, we will release mgiAuthenticate 1.1.1 to fix that bug.

Because of the modular nature of MGI, it will not be necessary for you to re-download the entire program and do a complete reinstall of MGI to get bug fixes for individual tags. All you will have to do is download the single tag and stick it in the plug-in folder, replacing the existing tag.

You can always tell exactly which version of MGI and the tags are running on your server in one of two ways. Either look at the server log on start-up of WebStar where the version numbers of the tags are displayed in the log, or do a Get Info on the tags themselves. A current list of all tags and all version numbers is located on the MGI Features Page. All registered owners of MGI will be notified by email whenever there is an interim tag release.

How fast is MGI?

Though that is technically a technical question, I think it best to handle it in the MGI FAQ. The answer is...we don't really know, or alternately, there is no real answer.

Remember, MGI is not really a single product, but a collections of many different products in the form of tags, each performing a different function. Some of the tags like mgiGet require very little processing time involving the CPU or access to the hard drive and are so fast so as to be immeasurable. Other tags such as mgiDatabase, though very fast, can be slowed down when performing intensive searches on enormous databases just like any other database program. Trying to come up with a general answer when so many different tags can be used on the server by so many different people -- well, the matrix to even begin calculating that requires a post-doc in theoretical math.

What we do know is this...each individual tag in MGI screams. Here are some of the individual benchmarks that we did perform.

mgiCounter: We host one site that has 130 html pages, each of them with a hidden counter that increments on it. Then those hidden counters are linked to a single page where the counters actually display, but do not increment when you hit the page. On a server running a heavy load, that read-counter page takes about eight seconds to process, serve out, and display in a browser -- most of that time spent actually rendering the intricate table configuration on-screen (I'm just grateful that he didn't use 130 frames to display the counter results instead of 130 table cells.) And all of it is accomplished without slowing down the rest of the server requests because MGI is multi-threaded and yields appropriately.

mgiEditDataabse: The import time for a tab delimited file to be slurped into an MGI database depends on the size of the database and the load on the server at the time of the import. In one test, a 2200 record database where each record contained 32 fields (several of them long description fields) took 40 seconds to complete the import. Again, the server was under load and no other requests were delayed because of the way MGI yields processor time.

mgiSearchDatabase: Using the same database as described above. a keyword search that returned 150 hits (listing them 25 per screen) displayed the results in about six seconds. That includes the latency in the dial-up connection of the user (a twin 56K bundled dial-up line) and the redraw of the screen in Netscape. Each returned record also had a 5K thumbnail image that went along with it.

In one test we ran, we took a 170K page with dozens of MGI tags embedded in it including mgiCounter, mgiGet, mgiSet, mgiPopup, mgiMath, mgiFileInclude, and dozens of others (each embedded multiple times.) That page took 62 MICRO-seconds to parse out and be handed back to WebStar for return. For those of you having problems with your metric system conversions, a micro-second is one-millionth of a second. The latency inherent in a modem dial-up connection itself is 250 milliseconds, or 250,000 micro-seconds -- plus the telco transit time plus the screen rendering time.

Of course, your specific performance will vary depending on the load on the server while using MGI. Remember, we built MGI to be used in a multi-domain environment. We typically put between 150 and 300 clients per machine (converted 7500s upgraded with G3 cards running between 233 and 400 MHz). Our machine that hosts our Basic Accounts (who have access to mgiSendMail, mgiCounter, and all the eye candy stuff like mgiTime) currently hosts 475 individual domains and who knows how many sub-domains hosted under our reseller program. There is probably some 700 to 1000 different web sites on that machine. Rarely is WebStar trying to serve out more than 80 simultaneous connections and even at peak we do not see any degradation in the server response time.

One the one machine where we have many of the database-intensive clients, we regularly hit and sustain 60 simultaneous connections without problems. Occasionally, we will see some slowdown when we peak at 120 simultaneous connections or better, but we're talking perhaps three or four seconds latency -- below what it is taking to actually draw the screen on the end user's browser window. And we are not sure whether the delays, as minimal as they are, are the result of MGI server processes, WebStar, specific MGI functions, or DNS resolve involving HomeDoor -- or a combination of all of them

One week before we released MGI 1.1, one of the domains we host was mentioned on the Rush Limbaugh radio talk show. The domain he mentioned (and spelled out for emphasis) linked to another web site on a different machine -- both domains and both machines on our LAN. So each request initially came into domain one on machine one, then jumped to domain two on machine two. Within 30 seconds, both machines hit 150 simultaneous connections. About 15 minutes later, I had the domains spread out across four machines doing DNS load balancing and each of the four machines were hovering in the 130 to 140 simultaneous connection range -- serving the pages flawlessly. I was getting ready to add a fifth machine just in case Rush mentioned the web site again, when things starting tapering off. In that whole incident, and once I got the machines off the maximum number of connections allowed by WebStar, the choke point was the telco -- not MGI, not WebStar, and not the hardware. Those two sites took almost 300,000 page loads in three hours and some 1.4 million actual hits including graphics in the same time. Every HTML pages served through MGI before going out. It was very cool.

Can you use MGI in a multi-domain environment?

Most indeed you can; it was built as such.

MGI can be placed on a server and you can then host hundreds of domains on that single machine. Each domain has access to all the MGI functions, but no domain can access the data generated by other domains -- just like virtual domains currently work running WebStar only. And each domain using database functions creates its own MGI Data folder that contains its own database entries. Since MGI can not get out of any given user's root level, their data is secure from alteration by another client on the same machine -- even if that client knows the specific tree path to an MGI Data folder located in the tree of another domain. Even two identically-named counters will increment only for the domain they are located in, not affecting other counters of the same name on the same server. There is one instance where MGI breaks down, though.

When you have a single domain running on two or more machines, there is no way to synch the databases between the machines. In other words, the counters will read differently and reflect only those hits to the specific machine that the request came into. And if you are adding records to the database table on one machine, you have to repeat the process for each machine the web site is hosted on. On the other hand, it takes a domain hitting about eight to ten million hits per month before you even need to consider load balancing across two or more machines. Any domain taking that kind of traffic can afford to hire someone to update two machines. MGI 2.0 will correct that situation, though, and allow two or more machines to synch their data files for a single domain.

[Admin Guide Main Menu]