[FX.php List] Ajax & server load?

Joel Shapiro jsfmp at earthlink.net
Mon Oct 15 11:43:28 MDT 2007


Hi Steve

In my search for appropriate tooltips, I ran across at least some  
that had built-in support for local content as well as external  
content (what I had meant by "Ajax", but perhaps I used the term  
incorrectly.)

It turns out that jQuery's clueTip has a feature to automatically  
hide local content that has the same element ID(s) as specified in  
the clueTip JavaScript, and then display that content in the  
tooltip.  (This way, I can easily loop through all returned data and  
keep appending to one variable to contain all DIVs.  Then I just  
display that one variable in my html and all my tooltips display as  
needed.  Lovely :-)

Thanks for all your help,
-Joel


On Oct 13, 2007, at 2:11 AM, Steve Winter wrote:

> 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.
>
>
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list



More information about the FX.php_List mailing list