Sorry, my confusion, I thought from a previous message that you were using a database by the name of dv3.

It sounds like your programmer just needs to clean up some nasty spaghetti code.  It may not have seemed bad when first written when there were only 1 or 2 links to resolve, but he may need to go in a completely different direction to support the number of city links or site links that you could expect if this takes off.

as for apostrophes in Mysql, it can handle them, but depending how your programmer is handling strings, he may need to "escape" them first.  What I mean by that is when he's loading them into a string, he may need to add a backslash ( \ ) character before any apostrophes like this "wasn\'t"  This slash shouldn't show up in the output, it just lets the program know to handle the character following as if it were a normal character (not something used to enclose a string)

Hi Vita,


I'll be adding your site shortly.
Hopfeully we can have this speed thing resolved soon.

Ok...Rotating link....
Because the .com is slow right now I'll refer you to the .ca

So if you got to http://www.iconxs.ca, let the page load, and then click refresh, you'll notice, say for example,
Sports may be the NFL Logo, after refreshing, the logo changes to say, TSN etc and so on....

All of our categeories do that. ie. Lottery, Insurance, Search etc....

Steven, Hi....

I'm sorry for the confusion....This is certainly not my forte. but I am desperate for answers and would like to
try and understand what the heck is wrong with our site.

DV3 -- We switched over to a dedicated virtual server last week, thinking it would resolve our speed issues.
So now we don't have to share with other sites, we have our own.

By doing so, our speed has improved, but certainly not what we were expecting.
It's clearly a database issue that is causing our lag time. Not to mention no search queries coming up
AND dumb code like "A0" & "="


I am frustrated to say  the least.

I need this to be fixed YESTERDAY!

Again, I am taking notes of everything you wonderful people are saying.


Thanks so much again!

I'm fairly new at a lot of this, but if if you'd like an idea that might help isolate the source of the problem, view your dynamic page, view source, copy/paste into new document, name "whatever_lite", upload and see if it is much faster without the server side dynamic bits, (because they will already have been resolved).

If it is helped in terms of speed, then you can look into the many ways one can choke their database, as I have often been inclined to do.

laurie_m wrote:

how long do you reckon it'll take, here in Australia? I'm a bit skepticle, Mate. But then, that's me.

Laurie - Does the internet go all the way to Australia?

Since the .ca site is fast and the .com is slow and the only difference is the .com has more info, it makes me wonder if there aren't a couple pertinent fields in your database that if you added an index to things would be better.

vita10gy -

That's a good thought and might be reinforced by a large disparity in the number of records between the two. I'm guessing the .com is bigger and I have no idea why...

It would indicate an inefficiency that was less relevant with fewer records.

Holy toldeo Batman!!

Here's what I did...


I went to iconxs.com/ohio, viewed the source, copied the code and pasted it into Dreamweaver.
(Not to cause confusion, but we don't normally use Dreamweaver to upload our files as it's database driven).

Now what?


LOL

Well if we renamed the file so we don't make waves, select the file & push the blue button... (upload it).

Do not confirm an overwrite because there shouldn't be one...

Then navigate to the page in your browser. It should be structured identically to the dynamic one, 'cept the database won't be invited.. I did test this, just to be sure and it worked nicely.

Let me qualify this by adding that I use Dreamweaver, IIS, ASP and that I am not a "real" doctor...

pigtails wrote:

Holy toldeo Batman!!

Here's what I did...


I went to iconxs.com/ohio, viewed the source, copied the code and pasted it into Dreamweaver.
(Not to cause confusion, but we don't normally use Dreamweaver to upload our files as it's database driven).

Now what?


LOL

Upload it as ohio_test.html or something and view it. It's probably not going to accomplish much though. It's obvious the build time is the culprit.

Agreed. The size of 147kb is actually fairly lean.

Just trying to be thorough..

I saw a lot of "webhop" theorizing.

I didn't mean to sound like I was "impugning" your idea as much as the comment sounded in hindsight.

I agree with the others that the programmer is just using a bad solution that isn't so obvious with a small dataset, but grows exponentially with a large data set.

I wrote a little quick/dirty stats page on my site that does all sorts of string replacing and grouping, and counts and mins/maxes and whatnot in a query of a join of two tables that have 300.000 and 500,000 records in them, and it still only takes like 10 seconds. (and i still hate waiting for it )

I wasn't "impugned". 

I think everyone is just trying help out with what they know.  You very nearly "over-smileyed". Try to be careful...

My primary function page has hoops of querys and joins and fun stuff, way fewer records though. Takes (0) seconds to process.

I love smiling, smiling's my favorite.

DMX wrote:

I wasn't "impugned". 

I think everyone is just trying help out with what they know.  You very nearly "over-smileyed". Try to be careful...

My primary function page has hoops of querys and joins and fun stuff, way fewer records though. Takes (0) seconds to process.

I've had pages that have litterally done thousands of queries and take almost no time.

It's clear something else is amiss here.

I'd guess a lack of indexes or a bad/wrong join of some sort.

Hey! It's faster!

Good Morning (or Good Evening depending on what side of the world you're on! )

Just wanted to say a big thanks for all your time. You people are brilliant!!!

Although I don't understand much of what you're saying, I'm getting a good grasp that
our issues are the database.

I came here for some resolve as I have been told a slew of things regarding the lag time.
-my connection, hops to New York, etc....

Here was my test on another server for our Ohio page...
Just a static page, but man does it load fast!

http://www.iconxslocal.com/iconxs_ohio.html

Unreal!

Still waiting to hear from the Programmer.

Hopefully this will be fixed soon and we can continue to grow!

I'm telling you, it is faster. Unless there's something we dont know, like you disabled some features or something, your programmer must have found the problem.

DMX wrote:

Agreed. The size of 147kb is actually fairly lean.

Just trying to be thorough..

I saw a lot of "webhop" theorizing.

147Kb including HTML, imgaes, CSS and JS is NOT lean

I [try to] keep my pages less than 30kb all in.

The page in question is ~40kb html for something that doesn't even go below the fold!!!

The remaining 100 kb is from images, I'm seeing ~30-35 images => ~3kb/image

I think 3kb for an image that size is pretty big anyway, but 150kb shouldn't be giving such huge load times.

Whatever your script is doing in the background needs to find those images quicker, much quicker.

As someone has already stated - good database designs, programming and SQL is worth while. All tables should have a unique index field. This means that other tables can reference that record with just 1 number, mapping tables and inverted indexes will also help large db designs

OK, slightly embarrassed after my last post -

having just run a report on a site I have advised on [from SEO basis]

we have

all in 302Kb [ouch]
html 21kb

page loads in 3 seconds

yeah.... its inevitable Northie, basically if you want your site to look aesthetically appealing and be functional... a large page size cant be helped... but thats what modern internet connections are for, the only way to advance the net is to use more space... so people either have to be patient  for now or get used to plain text sites. Or the telephone companies could suck it up and reduce the prices for broadband.. imagine what could be done if we could utelise 1mb per page.... it would be a seriously beautiful world. If you really want to reduce your page size though, host your images elsewhere, that way your page loads damn fast and gives users something to look at while waiting for pics to download.

Northie wrote:

OK, slightly embarrassed after my last post -

No need. We were looking for why the page took a half a minute to load on cable. I was commenting that it was not likely the page size is all. If you look into the little "experiment" above it may have helped isolate what was pretty evident anyway, that they need to look at the db, indexing, queries, etc.

I don't like pages that are all text or very nearly so. I removed 1/3 of the images on my index (most of the ones below the "fold") and worked on those remaining  until the size is around 135kb depending on a variable or two.  It's as good as it's going to get.  Now my problem is a retarded server choice that is going to require some work.