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:
upgrading (1997)
WebCat2b13MacPlugIn - [include] (1997)
Shopping with Accounts (2003)
WebCatalog/WebMerchant 2.1 (1998)
Shiping problem (1999)
Listserver problem (1997)
TeaRoom Order fields email account remain empty even though thewy are filled. (1997)
Webcatalog-firesite and [referrer] tag (1997)
Country & Ship-to address & other fields ? (1997)
RE: Credit Card not accepted (1998)
multiple skus (2000)
WCS Newbie question (1997)
Fun with Dates - any progress? (1997)
Multiple shipping databases (1997)
Template Not Found (1998)
NT b19 sends extra MIME headers (1997)
emailer w/F2 (1997)
where to put code (1998)
Virtual hosting and webcatNT (1997)
Changing Date Format in Field (1999)