NYCPHP Meetup

[harvey]

Ok, well, I think the problem is somehow Yahoo's (the client's host).
The load times for the page have been totally erratic, and so have the form 
submit times.
I just copied the page and relevant database tables to a Dreamhost account 
I have.
Voila! Everything runs perfectly fast now. Not even 2 seconds to load or 
form submit.
Seems like it might be something screwy with the Yahoo mysql server or even 
web server.
Not sure, but that's what it seems like to me?



At 10:14 AM 3/9/2005, John Nunez wrote:

>Harvey,
>
>If you have phpMyAdmin on that server run your SQL queries with the 
>COMMAND "EXPLAIN" in front of your SELECT Queries. Make sure your have the 
>proper indexes on the tables.
>
>Someone previously suggested copying all output to a variable then 
>transmitting it to the browser.  This will increase the speed of your page 
>loading.  There will be a slight pause on request but then it just flows in.
>
>500 - 1000 form items is quite a bit of formatting for the browser so make 
>sure all formatting is done via CSS. It's one setting for all TABLES, TRs, 
>TDs, INPUTs.
>
>Good Luck,
>John Nunez
>
>On Mar 8, 2005, at 10:33 PM, harvey wrote:
>
>>Hello Matt,
>>
>>Thanks for the note. I loaded the page in my browser, copied the source, 
>>and uploaded that for the client to test.
>>
>>As far as table rendering, there really shouldn't be an issue since the 
>>page is just one table with maybe half a dozen rows, one or two columns max.
>>
>>I'll try validating my html, but I doubt there are any major issues with 
>>it; the page is pretty simple, just pretty big.
>>
>>I doubt I can get the client to use Firefox, but probably can get them to 
>>upgrade their IE to version 6.
>>
>>Daniel earlier suggested that even though the client and assistant are on 
>>different machines, they're "probably on the same network and using the same
>>route over the Internet to/from your server. Have them run trace route." 
>>But actually the client and his assistant are at two different companies, 
>>different machines, networks, etc. Unless of course they are in the same 
>>building and are sharing the same connection, which I guess is possible. 
>>I'll check.
>>
>>With some tips from Brent, I implemented a potential fix that he 
>>suggested earlier, "My recommendation is to change you code so you are 
>>storing everything in a variable, then echo the variable when you have 
>>everything. That will probably speed everything up considerably." Still 
>>waiting for the client to test and get back to me.
>>
>>Rahmin suggested breaking up the long form with the list of bands into a 
>>few smaller pages, but the client already complains that there are too 
>>many pages to click through.
>>
>>So, that's where I am right now...
>>
>>Thanks to everyone for their help so far.
>>
>>Harvey
>>
>>
>>
>>At 09:48 PM 3/8/2005, Matt Morgan wrote:
>>
>>>[attempted to rearrange top posting for clarity--my apologies if I 
>>>mucked up the ">" signs]
>>>
>>> > harvey wrote:
>>> > > At 12:15 PM 3/8/2005, Faber Fedor wrote:
>>> > > > On 08/03/05 12:06 -0500, harvey wrote:
>>> > > > Hello NYPHP,
>>> > > >
>>> > > > I've got a page that works totally fine for me. Takes a few 
>>> seconds to load
>>> > > > on cable connection with IE 6 PC. Works fine for a colleague with 
>>> DSL on
>>> > > > the Mac (not sure which browser). But for the most important person
>>> > > > (client!) the page is taking over a minute and a half to load. 
>>> He's on Win
>>> > > > XP and IE (probably 6) with cable connection.
>>>
>>> > > Why are you looking at code changes when the problem is obviously with
>>> > > the client's computer/connection?
>>> > > You should find out what the problem is before you start fixing it.
>>>
>>> > Same thing happened to the client's assistant in a different location 
>>> on a different system.
>>> > Maybe both their connections are slow. Can't change that. But I can 
>>> change the code if that will help.
>>>
>>>This is not a slow connection problem unless every page on your site 
>>>loads slow for them. You could test by making a very simple, text/plain 
>>>page with as much content as your bands/shows page and seeing if they 
>>>download it faster. But I think I know what's going to happen (it will 
>>>load fast). If it does load slowly, they have bigger problems.
>>>
>>>Nor do I think it's a problem with your code, unless you are generating 
>>>bad HTML (have you validated it?). The browser doesn't see the php, only 
>>>the HTML. And if it goes fast for you, the php part is fast. I suspect a 
>>>table-rendering issue with their browsers, or maybe they have some funny 
>>>filtering setup that scans big pages slowly, or whatever (they, 
>>>hopefully, should be able to tell you what the "whatever" might be). Or 
>>>maybe (like most Windows computers out there) they're crammed with 
>>>viruses and spyware and ... In any case, most likely it's on their end 
>>>and changing your code won't fix it, unless you can remove all HTML 
>>>tables from the generated page and/or you're sending bad HTML.
>>>
>>>First, test the connection by having them download a large, but simple 
>>>page. Second, validate the HTML your code generates. If it validates 
>>>your code is good, or good enough. Third, Firefox is free. Ask them to 
>>>install it and try your (validated) pages with Firefox. Or, if they 
>>>don't want to install Firefox, have them update IE to exactly the 
>>>version you're using, or something newer (check to verify what they're 
>>>actually using--you're not sure, right?).
>>>
>>>Note: I am more of an admin than a programmer. If that was my network, I 
>>>would assume something was wrong on my end and take responsibility for 
>>>it. I sincerely believe that your responsibility here is to generate 
>>>valid HTML (unless they specified otherwise :-)), and anything else is 
>>>their problem. Maybe that's difficult in some way, but you shouldn't be 
>>>afraid to say it. If there's something wrong over there, they should 
>>>know about it.
>>>
>>>Good luck,
>>>Matt
>>>_______________________________________________
>>>New York PHP Talk Mailing List
>>>AMP Technology
>>>Supporting Apache, MySQL and PHP
>>>http://lists.nyphp.org/mailman/listinfo/talk
>>>http://www.nyphp.org
>>
>>_______________________________________________
>>New York PHP Talk Mailing List
>>AMP Technology
>>Supporting Apache, MySQL and PHP
>>http://lists.nyphp.org/mailman/listinfo/talk
>>http://www.nyphp.org
>
>_______________________________________________
>New York PHP Talk Mailing List
>AMP Technology
>Supporting Apache, MySQL and PHP
>http://lists.nyphp.org/mailman/listinfo/talk
>http://www.nyphp.org