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:
WebCatalog for Postcards ? (1997)
[WebDNA] How to get a screen size (2009)
fresh eyes needed. Append won't work. (2000)
PCS Frames (1997)
Interfacing WebMerchant to www.fedex.com (1997)
Still Learning (1997)
Email...Thanks (1997)
Another question (1997)
Random Images (2000)
passing large amount of text in post form (2005)
shipcost (1997)
security problem (1997)
WebCat2 beta 11 - new prefs ... (1997)
SiteGuard Use Question (1997)
PCS Emailer's role ? (1997)
Shopping cart now bad (1997)
For those of you not on the WebCatalog Beta... (1997)
[OT] Bad Hard Drive? (2003)
WebCat b13 CGI -shownext- (1997)
Pirated WebCat? NOT... (2003)