[FX.php List] Ajax & server load?

Sat Oct 13 03:11:17 MDT 2007

Hi Joel,

Glad it was some help then...

The Ajax tooltips will work just fine, since really they are javascript, but
instead of loading content via ajax, then displaying the tooltip in the
correct place, just skip the loading step ;-)

Cheers
Steve

-----Original Message-----
From: fx.php_list-bounces at mail.iviking.org
[mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Joel Shapiro
Sent: Friday, 12 October 2007 11:56 p.m.
To: FX.php Discussion List
Subject: Re: [FX.php List] Ajax & server load?

Hi Steve

Your long winded reply is indeed much appreciated ;)

After reading it, I did test the load-time difference when bringing  
in the additional data right from the start, and surprisingly it was  
only .3 - .4 seconds slower to load the page (less than half a second  
slower)!

I recognize that in production these times will be different, but it  
sure seems to point to not much more overhead -- and just once per  
session -- and then I'll be able to enjoy the luxury of instant local  
tooltips.

I did like the idea of everything being "Web 2.0", but I think I'll  
be happier with better performance while running in "Web 1.5" ;)

BTW- Yes, I'll be putting the tooltip content into hidden divs.  I've  
seen some JavaScript tooltips that do just that... I just need to  
find them again after all my efforts on those Ajax tooltips :-P

Thanks,
-Joel

On Oct 12, 2007, at 3:05 PM, Steve Winter wrote:

> Hi Joel,
>
> Strangely enough this idea that you came up with as an 'after  
> thought' was
> what I was thinking as I was reading through your original post... ;-)
>
> I have no solid facts to base it on, but my gut feeling is that with
> potentially so many links that can gain mouse focus, that the  
> number of
> calls to the db is going to make the tool tips load quite slowly  
> once you
> start to get several users on at once...
>
> Like you, I really like the Ajax idea of not having to have a bunch  
> of radio
> buttons and a submit, but that it all works through links via Ajax...
>
> Perhaps as a way forward the thing to do is build the 'ideal'  
> situation that
> you described in the original post, with the Ajax calls for each mouse
> focus, and see how it goes... if it ends up being too slow, with so  
> many db
> hits, then 'fall back' to the position that you've outlined here,
> potentially putting in a 'page loading' icon if it gets a bit slow,  
> and load
> your tool tips into either a Javascript Array, or probably more  
> sensibly a
> series of hidden divs, which you then position as required with  
> JavaScript
> on mouse focus...
>
> I'd love to hear that you built the 'ideal' solution, and that it  
> worked,
> but as a general rule I try to reduce the number of db calls as  
> much as
> practicable... This inclination is based on a system I built about  
> a year
> ago, in which I started out with a highly distributed series of  
> tables, with
> very few relationships in FM, and was essentially building them  
> through
> multiple php calls. What I found was that with each page load  
> making 5 - 8
> db calls, and 10 simultaneous users (this was an intensive education
> programme using FM as the back end), changing pages as often as  
> once every 2
> - 3 seconds, things began to slow down dramatically... I did some
> restructuring and went back to using portals for related data,  
> dropping the
> number of hits per page to 2 - 3 and things improved significantly...
>
> I guess my concern in your situation would be that if you had half  
> a dozen
> users who were running their mouse down a column in your table,  
> which passed
> over 10 items, each of which initiated a db call, almost  
> simultaneously (and
> as far as I know with Ajax once a call is initiated you can't stop  
> it, so
> even a brief mouse-pass over one of the links will make the db hit,  
> even if
> the data is never used) then the responsiveness of the system would be
> lost...
>
> I guess the only way to know for sure is to give it a try, and see  
> what
> happens...
>
> A very long winded way to not really say very much, but perhaps  
> helpful...
>
> Cheers
> Steve
>
> -----Original Message-----
> From: fx.php_list-bounces at mail.iviking.org
> [mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Joel  
> Shapiro
> Sent: Friday, 12 October 2007 7:40 p.m.
> To: FX.php Discussion List
> Subject: Re: [FX.php List] Ajax & server load?
>
> Hmm... One other option but I'd have to look into load times...  I
> could possibly bring in all detail data on my initial page load so
> that tooltips display already loaded content instead of needing to
> rehit the server for each mouseOver.  There's quite a bit of text in
> the details, though, which I thought would significantly slow down
> the page load.
>
> I'll check this, but would still love your feedback.
>
> Thanks,
> -Joel
>
>
> On Oct 12, 2007, at 11:34 AM, Joel Shapiro wrote:
>
>> Hi all
>>
>> I'd love your feedback on how my intended use of Ajax might affect
>> server load & performance:
>>
>>  - A <table> with 24 cells (4x6)
>>  - Each cell has 2-15 links (120-150 total) that onMouseOver call
>> to the DB for record details (as a tooltip)
>>  - Each link when clicked edits the DB and reloads the respective
>> cell via Ajax
>>
>> Basically, this is for users to select one option in each cell.
>> Mousing over any option shows details.  Clicking an option edits a
>> record in FM via Ajax.  I like the idea that changes are instant
>> and the user doesn't need to click a Submit button for the whole
>> page.  And I like that this way I can do various checks on each
>> selection before editing the record, e.g. to make sure that option
>> hasn't already been selected in another cell.
>>
>> However, I'm wondering if all these small hits to the DB will be a
>> problem when more than a few users are using the site at once.
>>
>>  - Probably not more than 30 or so users at a time, but in theory
>> could be more (but not 100s)
>>  - 1-machine configuration (FMSA(8) & WPE), running on a new Mac
>> Mini (not sure of the RAM)
>>
>>
>> Do you think this setup will be too slow in production?
>>
>> If so, would it help much to move the record details that display
>> on mouseOver into static content, since they won't be changing
>> often in the DB?  Or is a hit to the server pretty much the same
>> whether to the DB or to static content?  (& what would be the best
>> way to make static content?  Bring those 100+ records into one
>> large php array and grab each via a GET?  Create 100+ php pages on
>> the server?  Other...?)
>>
>> Or do you think a Web 1.0 site with radio buttons and a Submit
>> Whole Page button is preferable? (yuck)
>>
>>
>> All thoughts much appreciated.
>>
>> TIA,
>> -Joel
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date:  
> 11/10/2007
> 3:09 p.m.
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date:  
> 11/10/2007
> 3:09 p.m.
>
>
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

_______________________________________________
FX.php_List mailing list
FX.php_List at mail.iviking.org
http://www.iviking.org/mailman/listinfo/fx.php_list

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date: 11/10/2007
3:09 p.m.

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date: 11/10/2007
3:09 p.m.