Wednesday, January 28, 2009

FAQ: InBizness CRM Hosted Performance

QUESTION:
We’ve been testing remote hosting with one of our own solutions with appalling results – over 3 minutes to open the main file – it’s a separation model database. Your solution, on the other hand opened smartly and seemed quite quick to use.

My first question is ..... is this the speed we could expect from inBiziness in a production environment or have you kept the file(s) particularly small? Lots of relationships seem to be one factor in our slow responding solution. Even when loaded our solution is very slow when moving between layouts while yours seems to be quite quick, and yes, we have kept graphics to an absolute minimum. I’m quite happy to admit here that your programming skills may well outshine ours!

ANSWER:
These are all great performance related questions and my answers might seem a little bit rambling. This is similar to my experiences with FileMaker performance issues, the causes sometimes seem to ramble. In fact, I’ll probably break up my answers into multiple blog posts because I really want to share my thoughts to you in these areas.

ABOUT INBIZNESS DEMO SPEEDS
There isn’t anything different about the demo from the production database system. I simply take the production version, use FileMaker Advanced to protect its code and upload it to the server to host it. It doesn’t have an extensive amount of data in it but it does have data in almost every table. As a company adds thousands of records, there may be areas that may need to be tweaked for performance issues. Since InBizness is simply a single FileMaker file that has optimized for customization, performance hurdles should be somewhat easy to fix (if and when they may arise).

InBizness does have a lot of relationships and that can be a red flag for future performance (but not really). InBizness uses Anchor / Buoy religiously and this walled garden approach pays huge dividends for performance and customization. In my experience, a lot of relationships isn’t so much of a problem as the other factors that might ride shotgun in the same vehicle. Things that come to mind are ...

- lots of relationships that interact among multiple table occurrences
- lots of relationships that have complex operators or calculated match fields
- lots of data in those table occurrences (this is basically a multiplier)

I utilize “walled garden” techniques everywhere inside of InBizness and always look for more opportunities to do so. If I have a customer that will not use some of the InBizness modules, I quickly delete them from their copy. It may take me a hour or so to clean up the table occurrences, layouts, value lists or scripts. After I’m done, I run it by BaseElements to see what schema dust bunnies I might have left behind. After I clean out those dust bunnies, I run BaseElements again and repeat the process until BaseElements reports “looks pretty trouble free to me”!

SO ABOUT THE SPEED
I haven’t ever had a complaint about InBizness speed in a core implementation. However, I’m quite prepared for it. Speed issues should be approached with a surgical approach and my walled garden approach supports that very well. The place I would expect a problem to come up is when going from one client record to another. This is because I’ve added too much functionality there and I’m OK with that. Again, after doing a needs analysis with a client, I can quick customize the client module for the best of both worlds (speed and power).

ABOUT THE SEPARATION MODEL
The separation model has advantages and disadvantages. I did a full separation model for InBizness a couple years ago and never brought that product to market. It just didn’t have the payoff that made the extra coding overhead worthwhile. Since then, I’ve done smaller versions of the separation model, using just the tables that made sense. For example, the leads module is something I’ve separated for some customers. This is because of the sheer number of records it may contain, the rather limited amount of schema needed to support it and because the customer wanted to have the leads module available on the outside web.

No comments: