Hi Derek -- That's great information. I didn't know about the "data-" part of custom tags -- I thought any tags were legal as long as I didn't use "id" or "class" or something else reserved. But I'm a newcomer to HTML 5 and I want to be as compliant as possible. That 10K number sounds too large for this AJAX response. I'll have to look at it with my browser again to make sure I'm not sending too much stuff.
I did overwrite the address since it was showing the actual external IP address of the site and I'm not ready for visitors yet. So I am actually using a routable address for the site itself. (I invested in a local ISP so I have learned more about routing than I ever wanted to know!) -- Joe On Wednesday, July 3, 2013 1:17:32 PM UTC-7, Derek wrote: > > You're returning 72 rows, which equates to a 10k file, it's gzipped, so > there's latency on the server side which has to gzip it. If you can get it > under 5k the server may decide not to gzip it, thus speeding it up. Also, > you are returning invalid attributes in your td tags. If you want to have > custom data in your classes, you must prefix it with the 'data-'. See here > for more info... > http://www.javascriptkit.com/dhtmltutors/customattributes.shtml > > So what I'm seeing in the HAR is that it takes you 4 seconds to get data > that is 10k... > > Also, I am not sure if you changed it, but 11.11.11.111 is an ip address > on the internet... it belongs to DoD Network Information Center. You > probably don't want to use 11.anything for your internal ip addresses. > You'll have routing issues! Use the appropriate private ip address > segments, please! > > https://en.wikipedia.org/wiki/Private_network > > > > > On Wednesday, July 3, 2013 11:31:45 AM UTC-7, Joe Barnhart wrote: >> >> Yes, you're right. The site overall feels much quicker when talking to >> it directly, bypassing nginx and uwsgi. The query below takes in the 0.5-1 >> second range -- still somewhat slower than expected, but much quicker than >> thru port 80. This does indicate some shenanigans going on in my server >> stack. >> >> I'll do something about nginx and then see if the problem persists. >> >> -- Joe B. >> >> On Wednesday, July 3, 2013 1:49:14 AM UTC-7, Massimo Di Pierro wrote: >>> >>> Ajax aside, you should be able to start web2py locally and call >>> >>> http://127.0.0.1:8000/swim_smarter/results/meetevents/?meet=4232&event= >>> 22F&pf=f >>> >>> If you see the slow down you can eliminate problems with uwsgi and nginx >>> >>> On Wednesday, 3 July 2013 02:00:40 UTC-5, Joe Barnhart wrote: >>>> >>>> Here is something odd. I was looking through the logs of nginx and >>>> uwsgi to see if there are any smoking guns there. In the uwsgi log file I >>>> can at least see the log contains the same time I experience in "real >>>> time" >>>> when I select the page: >>>> >>>> [pid: 2767|app: 0|req: 700/1896] 67.161.165.180 () {50 vars in 1007bytes >>>> } [Tue Jul 2 23:45:17 2013] GET /swim_smarter/results/meetevents/?meet >>>> =4232&event=22F&pf=f => generated 6353 bytes in *3132 msecs* (HTTP/1.1 >>>> 200) 5 headers in 218 bytes (1 switches on core 0) >>>> >>>> So uwsgi sees the same time delay I see. I don't know if this is due >>>> to uwsgi or which other component. I'm not very familiar with nginx and >>>> uwsgi and may have misconfigured it when setting it up. It may be that a >>>> different web server would be a better fit for my goals. >>>> >>>> Eventually this will be a very heavily used database application with >>>> many gigabytes of data, but it may take a year or two to build up to its >>>> full potential. I could start with something simpler to configure and >>>> upgrade it as the volume builds. >>>> >>>> Joe >>>> >>>> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
