Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How many files/pages can GetSimple handle adequately?
#1
This may be answered somewhere else on this site but I can't find it offhand. Is there a maximum number of pages that GetSimple can handle?

Do you have a large website now using GetSimple? If so, can you tell us how many pages are in it?

I'm thinking of migrating my website to GetSimple but I'm wondering, as easy and as simple GetSimple cms is, how many files (i.e., pages) can it handle? For example, I've got about 100 php files, 20 audio files and a photo gallery of about 200 photos (which I can leave in its present format and simply include through php, if GS allows me to do that--which I assume it does).

Thanks for help.

My site, by the way, is at http://tinyurl.com/3mxts8g

Don
Reply
#2
dondemaio Wrote:This may be answered somewhere else on this site but I can't find it offhand. Is there a maximum number of pages that GetSimple can handle?

Do you have a large website now using GetSimple? If so, can you tell us how many pages are in it?

I'm thinking of migrating my website to GetSimple but I'm wondering, as easy and as simple GetSimple cms is, how many files (i.e., pages) can it handle? For example, I've got about 100 php files, 20 audio files and a photo gallery of about 200 photos (which I can leave in its present format and simply include through php, if GS allows me to do that--which I assume it does).

Thanks for help.

My site, by the way, is at http://tinyurl.com/3mxts8g

Don

On the front end side - the website for your visitors - there is basically no limit, unless you use a dynamic navigation menu - it's just reading a theme file and the page's xml file, including the xml content in the theme file and displaying it.

If you use a dynamic navigation that's caching the important information from the page files (like the I18N plugin). you will not have any problem either, even with a few 100 pages.

Photos and galleries shouldn't be a problem either - especially if you keep them as they are (in any case it's mostly the data transfer time for the pictures that is important). But there are some gallery plugins available, too.

If you need a search on your page, you can use the I18N Search plugin, which builds index files and should be quite fast.

On the back end side, the administration, you might encounter some delays when editing hundreds of pages - for the pages list all pages are read in and displayed; when editing, all pages are read again do display the navigation structure. And of course the pages list will be quite long - but can easily be filtered.

Resume: I don't think you will have any problems with your site.
I18N, I18N Search, I18N Gallery, I18N Special Pages - essential plugins for multi-language sites.
Reply
#3
WHen testing one of my plugins I created a site with 2000 pages , each one on the menu so each page needed to be read everytime, with little or no impact on the site...

Mike...
My Github Repos: Github
Website: DigiMute
Reply
#4
To add to this thread:

I have created a large site with over 140 pages, with more than 500 images shown on the front-end. All works without problems.
Reply
#5
Its very good topic, thank you!)
It is believed that the sites with databases faster. But comparing the popular trinity (joo,wp,dru) and GS... I understand that this is not always true)
Reply
#6
(2013-03-10, 02:55:05)antanariva Wrote: It is believed that the sites with databases faster.

It is known that sites with XML are faster ;=)

and we have sites with around 500 pages and more,
|--

Das deutschsprachige GetSimple-(Unter-)Forum:   http://get-simple.info/forums/forumdisplay.php?fid=18
Reply
#7
(2013-03-10, 04:55:09)Connie Wrote:
(2013-03-10, 02:55:05)antanariva Wrote: It is believed that the sites with databases faster.

It is known that sites with XML are faster ;=)

and we have sites with around 500 pages and more,

Maybe it is a stupid question Blush but... then, why do most CMS use databases ? Is it because it is simpler to code ?
Reply
#8
It can be more complex, you can query any thing you can imagine in microseconds, and manage it all seperatly. With a file based backend you have to consider how to efficiently load all those files and create caches of the fields you need.

Say I want every tag of every file, for searching perhaps, I have to load every file and extract the tags. This can hit memory and time limits. So i wuold have to know in advance and do this once and craete a cache of these tags, but then what if i want some other metric I have to plan that also.

With gs we have a pagecache that holds everything for all pages except the content fields, so we can load 1 file and access all the metrics for the pages. It gets updated routinely when stuff changes.

I have a test site I use with 2000 pages of full content and metas, and the cache file it generates is only 1 mb and loads almost instantly.

But the issue it has is 2 fold, the menu sorting has not been updated for caching causing delays on the backend and the pages viewer cannot accomodate all these efficiently, it is one giant list.

Oh and FYI 3.2.1 + loads pagecache on the front end always, at least for now.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#9
OK, I understand now. Thanks !
Reply
#10
So up to about 400 pages it runs fine and managing is not to bad.
We have future plans to accommodate more.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply




Users browsing this thread: 1 Guest(s)