Bob,

A couple thoughts,
1. Sesame in most versions of linux runs like lighting.In Mandiva 2006 My DB in Sesame took, not kidding 20-minutes to load, I went back to Mandrake Ver.10 and it took only seconds.

2.I have had no luck getting linux to connect with windows-xp pro.

3. For speed I'd go to linux, but until I can do without windows {certain programs & hardware} I'm stuck with windows.

4. I ended up splitting my DB in half to speed it up, which seems to have solved my speed problems.

If you are after speed, and only speed - go with Linux and fill the box to the brim with RAM. But be aware that installing and configuring Linux, unless you are already familiar with Unix in general, will be a learning experience.

If the idea of changing the OS is too daunting, Sesame will appreciate being run on one of the NT derived MS OSs (XP/NT/2000) more than the 95 derived OSs (95/98/ME).

But, nothing matters more to Sesame than RAM. The higher the bandwidth and the more you have - the better.

Given the way Sesame works, it is unlikely that your users will ever need to know that the OS on the server is Linux. Afterall, most web servers are running some Unix variant, yet Windows users need never know.

The main difficulty in hooking a Windows client to a Linux server is the use of DHCP. Both operating systems support DHCP well, but they do not share each other's assigned IP addresses without being told to do so. One way to avoid this is to use a nameserver that is OS independent (like we all do on the internet), or to use a host file (and thereby avoid DHCP for the server). Or, if you are feeling daring you can set up Samba on the Linux server and make it do some of its networking (like file sharing) the MS way.

Quote:

Yup, RAM is what it is all about. Every program "allocates" memory - that is, it claims portions of memory as its own, and uses that memory to store info. It is much faster if there is plenty of surplus. Many programs, including Sesame, use RAM caching. This is a method where the program (and the OS) do not "free" RAM when they are done with it, until that RAM is needed again. This speeds things up considerably, in that it is much faster to allocate unused RAM than to recyle no-longer-in-use RAM.
Quote:

I'm working on that for 2.0. I got it about 30% faster, but I'd like to see 300% faster. It can never be as fast as natural linking, but I'd like to see it be competitive.
Quote:

In both case, you end up pre-loading the application once, and thereby avoiding a reload during operation.
Quote:


Some other speed advice for larger systems:
1. Get rid of unneeded fields. Often, Q&A databases had programming only fields, or shadow fields. These are unnecessary in Sesame. If you have lots of small fields acting as buttons, eliminate them and replace them with buttons. The more data each field holds, the more efficient your form will be. In Q&A, the average field is holding less than 2 bytes of data (from studying just under 6000 Q&A databases). If you have rarely used fields, consider combining them or eliminating them.

2. Whenever possible, use form view subforms as opposed to table view subforms, especially if the main form is used primarily for data entry. Form view only requires that the engine and the network (and the user) deal with one record at a time. The table view requires that all of the subrecords appear and be managed. It is more efficient to build two versions of the parent form, one with a form view subform and one with a table view subform. Those who need to have an overview of the data use the table view, those that need to enter data use the form view.

3. Encourage the use of search specs, as opposed to getting all the records all the time. This is especially important if you have a lot of simultaneous users. Each result set ends up smaller and easier for Sesame to manage. It also decreases the likelihood of record locking getting in your way. If you can help it, limit the result sets used in reports and table viewing (Shift-F6), both require that large portions of the underlying database be sent to the client from the server.

4. Minimize the use of networked file sharing (under MS) and NFS / Samba (under Linux). There are few networks anywhere as fast as a good hard drive. If the server needs to go through a net to get to its files, it will go slower. It will also use up network bandwidth that it could be using for communication with its clients.

5. Because RAM is most important, if you can handle the differences, use Linux as your server. Unix is substantially better at managing memory than MS. It also allows 4 Gigs to be addressed, as opposed to just 2 Gig under MS. If you are in MS, there is a boot option that allows NT derived OSs to address 3 Gig. In general, you will get more bang for your RAM buck on Linux.

6. If you can afford it, get multi-core/hyperthreaded multiple CPUs. Sesame server is a fully multithreaded application. So if you have multiple CPUs, Sesame will take advantage of that, and give each command it recieves its own thread on its own CPU. For systems with a lot of users, that can make a big difference. Get CPUs with large high speed memory caches. A good caching system (memory bandwidth) will make more difference than high Mhz numbers.

7. Use fixed size swap files and max them out for your system. It takes time for the OS to grow the swap file. If you have the hard drive space to set your swap file now to as large as it will ever get. Set it and forget it.

8. If you use reports or table view on large data sets, get more RAM for your clients. Reports and table view (Shift-F6) are the only places that require the client to have much storage/muscle.

9. If you can, organize forms so that frequently edited or searched fields are near the top of the form. Do not pack LEs too tightly on the form. Sesame uses visibility clipping to avoid drawing things that are scrolled off or on a different tab. If you can, put infrequently used LEs on a different form.

10. Organize your code so that as much code is in as few events as can be done. Putting a little bit of code in each LE is much less efficient than putting a lot of code in only a few LEs. Use subroutines and functions whenever possible. Avoid repetitious code. Use functions that group data (XLookupSourceList/XLookupSourceListAll/XLookupAll) instead of using multiple XLookups. Use functions and subroutines instead of using ThrowFocus (or (GASP!) goto) statements to control what code is running.

11. Use variables instead of LEs wherever possible. Accessing (setting and getting) variables is much much faster than using LEs. If you have the choice of using a function that returns a value or a subroutine that sets the same same, use the function (@Xlookup versus XLookup).

12. If you have data that rarely changes, store and set it in global static arrays as opposed to using XLookups.

13. If you can, use GlobalValues/@GlobalValues as opposed to XLookups/Lookups. GlobalValues are much faster.

14. If possible, use retrieve spec open programming in place of programming in a retrieve spec. If, for example, you have:

{DateEntered < @Date}
 

You can replace that with:

DateEntered = "< " + @Date
 

in your retrieve spec open event. This will cause the code to run once, writing to the retrieve spec before the actual search. If you opt for retrieve spec programming, the code will run over and over again on every record you search.

15. When possible, use natural linking as opposed to relational linking. Relational linking causes Sesame to have to find all of the child records for every parent record viewed, dynamically. Under natural linking the parent can keep a list of its children and avoid the search. This is especially true if you intend to search from a child record. Under relational linking Sesame has to find all of the children that match the spec, then find all of the parents that have that child, then find all of the other children that match all of those parents.

Of course, these steps are not required if you have no need of them. Most speed problems can be managed by adding more RAM to the server, or through small simple design changes. To sum it up, when in doubt, add RAM.