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?
Easy...here 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.
|