texte = 1946 --Apple-Mail=_42AD59E3-B43F-47BA-BAA1-E9732C2DAA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I did a similar thing a while ago on 2 high traffic sites Basically the concept was this. Every page had a 3 level deep menu = pulldowns. Those menus were driven by a backend CMS and stored across = various tables. The site was serving well over 1 million page views a = month and I was starting to feel the weight of it in performance. keep in mind that each pulldown was a recursive search for each level so = it really added up. Instead, I retooled the CMS so that the result of adding, deleting or = editing any menu in the admin resulted in a menu being written = completely to a single include file. This put the work of the recursive = searching on the backend and only when a change was needed. It made an immediate difference in page performance. Later, this was done on another site with similar traffic that was all = driven by SQL connections. Because of the ODBC performance hit, speed = was improved even more dramatically. This was especially true when the = tables had 1.5 million records in them. If you=E2=80=99re unsure of the impact throw an elapsedtime tag on the = page and you will instantly know just how much performance you squeezed = out of the system. HTH Alex > On Jul 3, 2018, at 2:24 PM, Lawrence Banahan
= wrote: >=20 > I was more thinking of something like a CMS, with the engine Online. > Doesn't it make sense to have the content that change one a year to be = in static pages? > Wouldn't it be faster than having Webdna in the middle? > I'm working also on Wordpress websites, and it's so slow... That's how = I came through my searchs on some websites using static pages. --Apple-Mail=_42AD59E3-B43F-47BA-BAA1-E9732C2DAA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = did a similar thing a while ago on 2 high traffic sites
Basically the concept was this. Every = page had a 3 level deep menu pulldowns. Those menus were driven by a = backend CMS and stored across various tables. The site was serving well = over 1 million page views a month and I was starting to feel the weight = of it in performance.
keep in mind that each pulldown was a recursive search for = each level so it really added up.
Instead, I retooled the CMS so that the = result of adding, deleting or editing any menu in the admin resulted in = a menu being written completely to a single include file. This put the = work of the recursive searching on the backend and only when a change = was needed.
It = made an immediate difference in page performance.
Later, this was done on another site = with similar traffic that was all driven by SQL connections. Because of = the ODBC performance hit, speed was improved even more dramatically. = This was especially true when the tables had 1.5 million records in = them.
If you=E2=80=99re unsure of the impact = throw an elapsedtime tag on the page and you will instantly know just = how much performance you squeezed out of the system.
HTH
Alex
I was = more thinking of something like a CMS, with the engine Online.
Doesn't= it make sense to have the content that change one a year to be in = static pages?
Wouldn't it be faster than having Webdna in the = middle?
I'm working also on Wordpress websites, and it's so = slow... That's how I came through my searchs on some websites using = static pages.
1946 --Apple-Mail=_42AD59E3-B43F-47BA-BAA1-E9732C2DAA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I did a similar thing a while ago on 2 high traffic sites Basically the concept was this. Every page had a 3 level deep menu = pulldowns. Those menus were driven by a backend CMS and stored across = various tables. The site was serving well over 1 million page views a = month and I was starting to feel the weight of it in performance. keep in mind that each pulldown was a recursive search for each level so = it really added up. Instead, I retooled the CMS so that the result of adding, deleting or = editing any menu in the admin resulted in a menu being written = completely to a single include file. This put the work of the recursive = searching on the backend and only when a change was needed. It made an immediate difference in page performance. Later, this was done on another site with similar traffic that was all = driven by SQL connections. Because of the ODBC performance hit, speed = was improved even more dramatically. This was especially true when the = tables had 1.5 million records in them. If you=E2=80=99re unsure of the impact throw an elapsedtime tag on the = page and you will instantly know just how much performance you squeezed = out of the system. HTH Alex > On Jul 3, 2018, at 2:24 PM, Lawrence Banahan = wrote: >=20 > I was more thinking of something like a CMS, with the engine Online. > Doesn't it make sense to have the content that change one a year to be = in static pages? > Wouldn't it be faster than having Webdna in the middle? > I'm working also on Wordpress websites, and it's so slow... That's how = I came through my searchs on some websites using static pages. --Apple-Mail=_42AD59E3-B43F-47BA-BAA1-E9732C2DAA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = did a similar thing a while ago on 2 high traffic sites
Basically the concept was this. Every = page had a 3 level deep menu pulldowns. Those menus were driven by a = backend CMS and stored across various tables. The site was serving well = over 1 million page views a month and I was starting to feel the weight = of it in performance.
keep in mind that each pulldown was a recursive search for = each level so it really added up.
Instead, I retooled the CMS so that the = result of adding, deleting or editing any menu in the admin resulted in = a menu being written completely to a single include file. This put the = work of the recursive searching on the backend and only when a change = was needed.
It = made an immediate difference in page performance.
Later, this was done on another site = with similar traffic that was all driven by SQL connections. Because of = the
ODBC performance hit, speed was improved even more dramatically. = This was especially true when the tables had 1.5 million records in = them.
If you=E2=80=99re unsure of the impact = throw an elapsedtime tag on the page and you will instantly know just = how much performance you squeezed out of the system.
HTH
Alex
I was = more thinking of something like a CMS, with the engine Online.
Doesn't= it make sense to have the content that change one a year to be in = static pages?
Wouldn't it be faster than having Webdna in the = middle?
I'm working also on Wordpress websites, and it's so = slow... That's how I came through my searchs on some websites using = static pages.
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Price problem (1997)
WebCat editing, SiteGuard & SiteEdit (1997)
removing commas from a preformatted number (2000)
Not really WebCat - need HTML Grider (1997)
Alternating BGColors in Table Rows (1998)
Help with Repost Data msg from form (1997)
[WebDNA] Code works in v6 but not in v7 (2010)
WebCat2b12 forgets serial # (1997)
Upload to LINUX always breaks my sites - why? (2004)
4.5 Upgrade (2003)
Almost a there but..bye bye NetCloak (1997)
WebCat2b13MacPlugIn - [showif][search][/showif] (1997)
Error: Permision deny. (2005)
WebCatalog for guestbook ? (1997)
Web Catalog not encrypting/decrypting problem (1998)
Page Counters? (1997)
Re[2]: 2nd WebCatalog2 Feature Request (1996)
Word search (1997)
Re:Off Topic: Frames Killer? (1998)
[WebDNA] CMS in WEBDNA (2009)