Click to See Complete Forum and Search --> : How to make a web site work faster


ikava
February 29th, 2008, 10:51 PM
Hi Guys, we have linked a lot of telecom companies by technology categories, countries and cities on our web site www.wirelesspedia.com but this slows down a web site, any ideas how to make these kind of web sites the right way? And how to improve the speed. tnx. Marco

wildfrog
February 29th, 2008, 11:03 PM
Ignoring the fact that this is just pure advertisement; use a profiler to determine where the bottlenecks are.

- petter

ikava
March 1st, 2008, 09:06 AM
Story of my life, when i tell the truth people take it as a lie, when I lie people believe in it...anyways, thank you very much for the advice, but the problem is, as was explained to my by the developers, that too many fields and information in the database, and that is what is slowing down, so I guess the question should have been "how to make the data base work faster"?

TheCPUWizard
March 1st, 2008, 10:23 AM
A properly designed database, running on the appropriate platform (HW & SW) should never "slow down" a WebSite. I typically query datasources with well over a million rows.

Are you sure:

1) Your hardware and software is the appropriate platform for the amount of data?

2) Your data is optimally normalized (note: this does NOT mean fuly normalized)

3) Your data is properly indexed?

btw: none of these issues have ANYTHING to do with this forum.....

ikava
March 1st, 2008, 04:27 PM
Thank you, actually the snowlines is "contained" when doing the admin work, speed of 8-9 seconds, so probably some unnecessary requests are being made in the DB, we’ll need to optimize that part, the home page loads in about 1 second, I guess it is ok. Out of curiocity, "Your data is properly indexed" how that effects the speed fo the site? You mean indexed by Google?

PeejAvery
March 1st, 2008, 09:50 PM
Not by Google. To make quick access to database information, you want an index column which is unique. In other words, you can have a column named id which is set to a primary auto-incrementing integer. Then you can call that row by that id for easy access.

Of course, that is only one out of many steps to making an efficient database structure.

EDIT: Fixed tags.

PeejAvery
March 1st, 2008, 09:51 PM
[ moved ]

kutu62
March 5th, 2008, 05:05 PM
y'all may wan to discuss static pages built based on dynamic content

PeejAvery
March 6th, 2008, 09:16 AM
kutu62...That has nothing to do with this topic.

ikava
March 6th, 2008, 11:03 PM
We have fixed the problem by using the pointers in our DB so thank you very much guys for your help.

kutu62
March 24th, 2008, 12:11 PM
PeejAvery

It has everything to do.. his issue is his website is slow b/'c his pages are built on the fly based on information from a DB. This makes his site slow.

The Washington Post and other large sites use static pages built based on dynamic content.

Now I didn't tell him how to "fix" his problem.. but I did tell him a better way to utilize technology to increase productivity. As his DB grows and as they get more traffic his DB servers will have to grow also... static pages are a nice way around this

check out http://www.movabletype.org

PeejAvery
March 24th, 2008, 01:23 PM
To archive old data, this may be true, but I personally would never do it. In fact, I am not seeing where the Washington Post is doing this either. Just because they have the HTML extension, does not mean they are static pages. Any server-side language can use any custom file extension it wants.

Any database can be organized well enough to sort loads of data beyond what static pages would do. MySQL alone can be used to house double-digit gigabytes of data without tying down a machine.

All this depends on the organization of the database.

TheCPUWizard
March 25th, 2008, 09:41 PM
I agree with Peej and have worked on many very large sites that are all dynaically gnerated with hit count in the tens of thousands per hour. What gets "emitted" is often plain HTML for maximum browesr flexability.

There si ONE advantage to actually storing the statically generated pages on the server that has not been mentioned. Search Engine Access. Compare the following two scenarios.

An "active" page with 4 combo boxes each with "0" thru "9" as a selection. The page also has a single button. On a post back, the values are read to display 1 of 10,000 possible result pages.

Submit this page to a sarch engine, and it is highy likely that you will only be "Finadable" by what ever satic content is on the original page.

Alternatively, create a site with 10,000 actual html pages and a set of links between them (so bots can crawl from page to page). This will almost always result in much more of your content being accessible. For best results you want to limit the degrees of separation to about 4 or 5 (ie from any page, you can get to any other page in a maximum of 4 or 5 clicks.

This approach WILL take more server disk space (typically cheap) and may present various maintenance issues (as well as potentially being "unfriendly" to humans. But if the goal is to achieve maximum web presence, this can work extremely well.