ForumGarden

1|2|test 16798789789797979799879797979|4|5|6|7

1^~right with colspan

2^333|=center with colspan

3^1|2|left with colspan

4^1|=center without colspan|3|4|5|6|7

5^1|blablabla|3|4|5

6^1|2|3|4|5|6|7

jimbo;719916 wrote: jimbo calling NASA,stephen hawkins or spock ...come in please :wah::wah:


You're such a plague jimbo!

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimbo

JimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimboJimbo

Oh poo, that's not right either.

jimbo;719923 wrote: i guess i passed the ignore test then buddy :wah::wah::wah:


That shouldn't have worked even a little bit.

Ah. Okay, I see how you did it. It still shouldn't have worked!

I see that I'm like Jimbo. The word ignore does mean look, right? :wah:

col1|col2|col3

row2|row2|row2

row3|row3|row3



hmm....

Notes on optimal webserver efficiency in the context of the kitchen statistics.

Highlights:

* One database read per client request, for a map with lots of boundaries on it

* All data-to-javascript translation done once-only as a back office admin screen function during data import from the kitchen site

Detail:

Currently in the prototype (which exists to check that our syntax of all the external API calls is clean and there's no surprises in what they do) each polygon is pulling a coordinate map off the database. Then the server loops sufficiently to build explicit static javascript. The client gets that and generates the static map. If any variation on the map content is asked for (other than zooming) another server call is made. So for a large force there's maybe 200 SQL selects being made for each client request.

For the live system, this must be made more efficient. Here's how to do it.

The back office admin once-a-month process can take the existing record set (it's fine as a JSON cache) and build one extra record per map. That record can carry all of the boundary arrays in one prebuilt javascript parameter list, and all the stats for all the areas in another, as explicit js code rather than as field-by-field data.

The client javascript code can actively take those two array sets, passed with a single database read, and generate the API map call and the correct colouring. All the stats variation requested by the user can be rebuilt by the client code without any other server call. The next server action would be show details of the force or NPT, change to another NPT or return to the national map.

The database javascript arrays record can have two flavours, "TEST" and "LIVE". After running the admin screen, the client can be run on TEST data to check everything looks rational. Then a "release to live" screen can overwrite all the old LIVE records with the new TEST and the release is made.

The server response to a client request for a map now becomes: 1. get the map javascript table record with one SQL select; 2. stream that, and the remaining client javascript code, to the html header space without even looking at it. There's no server processing of map data at all, just copy the one record content into the output stream. There's no server interpretation of any JSON fields as a result of a client request for this high-volume load. The low-volume "show me the NPT / Force description" can involve JSON interpretation on client request, it won't happen often and there's still only one SQL select needed to serve the page.

I thought that was so obvious, it was taken as read but I guess there might of been one or two here who didn't know it though.

I was rather pleased with that, myself. I went to the surgery at two for some antibiotic eyedrops and they didn't open until three so I sat and thought with a pad of paper and a pencil, me being the sort that's never without. And that's what came into my head. It baffles me how it happens but it's gratifying that it does.

These Gorillas ain't half strong.