CMSimple needs a better plugin system

[cmb]

Hello snafu, hello developers,

really nice to read your opinion on this topic AFAIK you have real world experience with other CMSs except CMSimple.

anyway, speed optimation is always a good thing

+ 1

We should distinguish at least 3 different peepholes:
1. network delay
2. server response time (i.e. from starting to process the request till the response)
3. the time the browser needs to display the page

We can't do anything about 1. and 3. (at least, if there's no JS involved) This is in the hand of the user: which content he wants to be served (many or large images, or even videos), which hosting service he had chosen. And it's in the hand of the visitor: which browser he uses, which internet connection he has (56k modem vs. DSL2000).

And this is IMHO the greatest performance problem. Consider a gallery page with 100 thumbnails ('ve just took at look at your website; I found the galleries well divided, with far less than 100 thumbnails; but not all users will handle it that way). Even if the typical thumbnail is very small in size (say < 10KB), the server has to answer 100 separate requests just to serve the thumbnails, with several hundret KB total size, until the page can be fully displayed in the browser!

It is in the hands of the developers to influence 2. It is important not to waste ressources. But we have to consider the costs vs. the benefits of those optimizations. IMO the costs of neither an incompatible plugin loader nor parsing CMSimple scripting will rectify it's benefits.

And finally it's the users choice how many different plugins he wants to use on a single website. Are ten or more really necessary?

Christoph

[bjorn]

Hi again

@Gert
No need for changing the way CSS files are handled. The pluginloader does already write the address of it to $hjs. The only problem is that it is done for each plugin everytime no matter if it actually is used or not.

@Christoph and others
I don't get the point about a "stub solution". Can you give me an example of a plugin that would need such a solution.

In the front end as it is now the pluginloader does nothing except that it includes the files of each plugin. It willl not make any difference if this is limited so the plugin only is included when it actually is needed.

You ask:

Code: Select all

Code: Select all
    #CMSimple $output=preg_replace('/(<h[1-3]>).*?(<\/h[1-3]>)/i', '\\1New heading\\2', $output);#

Is there a plugin call involved?

No this is handled internal in cms.php

I have also done a little benchmarking. With 16 plugins it takes more than 0.4 second to load CMSimple on my local computer. Without plugins it only takes less than 0.08 second. A difference of more than 0.3 second.

I don't know how many simultaneous requests servers normally are running. But if a server gets 100 request and each request consumes an extra time of 0.3 second it would delay the last request 30 seconds.

Bjorn

[Gert]

No need for changing the way CSS files are handled. The pluginloader does already write the address of it to $hjs. The only problem is that it is done for each plugin everytime no matter if it actually is used or not.

The Pluginloader only writes the address of the css file to $hjs automatcally, if there is a stylesheet.css in a folder named "./plugins/the_plugin/css/".

If the css file is in another folder, and no folder "./plugins/the_plugin/css/" exists, the pluginloader does nothing, and the author can add the css file to the head section by the main function. So the css file is only loaded if the plugin is called, and not on every page.

With 16 plugins it takes more than 0.4 second to load CMSimple on my local computer.

That's not time enough for a cup of coffee

[cmb]

Hello Björn,

I don't get the point about a "stub solution". Can you give me an example of a plugin that would need such a solution.

Consider a very big plugin, having an index.php of e.g. 100KB. If it is written the classic way, all those 100KB must be read and parsed by the servers PHP-parser. If it is written as stub, only the small index.php of around 1KB must be read and parsed every time. The rest of the code will only be included, if the function actually gets called! (include() inside a php function definition will be executed only if the function is actually called).

Now consider the size of typical stylesheet.css, config.php and LANG.php. These will have a total size of say 10 KB. So with the stub solution, only 11KB have to be parsed, instead of 110KB (just 10%).

In the front end as it is now the pluginloader does nothing except that it includes the files of each plugin

To make it clear: the plugin-loader reads only particular files from the plugin's folder, i.e. index.php, config/config.php and languages/LANG.php AFAIK. Other files in the plugin's folder will not be read by the plugin loader, but only by the plugin.

Is there a plugin call involved?

With that question I was referring to your suggestion that the plugin loader should check every CMSimple script on the requested page for calls to special plugins. If it were possible to assume, that plugin-call names won't clash with such general script calls, this check might be very simple. But what is when a plugin has a function heading? Okay, it is possible to check for the '(' after the function name. But in the general case of very complex CMSimple scripting it might be impossible for the plugin loader to exactly find, which plugins have to be included.

And there still remains the problem of plugins called by template.htm.

With 16 plugins it takes more than 0.4 second to load CMSimple on my local computer. Without plugins it only takes less than 0.08 second.

That is quite a difference. But do you know of websites, which use that many or even more plugins? And have you checked the difference of having a very small and a very big content.htm?

But if a server gets 100 request and each request consumes an extra time of 0.3 second it would delay the last request 30 seconds.

Lets stick to this simple case (in a hosted environment the situation is by far more complex AFAIK). A day has 86,400 seconds. So if your server has 100,000 requests per day, there will be no delay, if the requests were evenly distributed (the server still has 860ms to respond to each request).

But: I see your point. The current solution is somewhat wasteful with a servers resources, but I can't imagine a solution for a better plugin loader that:
- is compatible with existing plugins
- can be used as easily as the current one from template.htm and content.htm
- can be realized without wasting more resources for websites with 0-2 plugins
- can be implemented with the typical effort for a CMSimple plugin

Christoph

[bjorn]

Hi Christoph

It could become a long discussion, but let us make it short.

It would be quite easy to change the loading of plugins when they are called from content.htm. But you are right. When they are called from template.htm they have to be loaded already. I didn't think about that

But still there is a problem. Perhaps we in the future should develop an alternative and parallel system of plugins or modules that only are included when they really are needed.

Thanks for the comments.

Bjorn
http://www.cmsimple-le.eu

[cmb]

Hello Björn,

When they are called from template.htm they have to be loaded already

AFAIK the current plugin loader is called before template.htm is included. So it would be possible for the plugin loader to scan template.htm in the same way that it scans the content. But as I've already written: I think it is too much overhead if none or only some plugins are installed. And it wont work if a plugin uses a function call other than it's name.

Perhaps we in the future should develop an alternative and parallel system of plugins or modules that only are included when they really are needed.

This could be a viable solution. But it would only be useful IMO, if many plugins would use this new plugin loader, because probably than two plugin loaders have to be called, so that the older plugins could be used further.

Another drawback: the new plugin loader has to be developed, and IMHO there might be more important things to do already.

But perhaps any of the developers will come up with a solution, that's simple to implement and to use. I'll be glad to hear of it.

Christoph

[bjorn]

Hello Christoph

If we define some rules for a new kind of modules like:
1. Only call from content.htm
2. Same name for the modules directory and main function
3. Structure and files like the present plugins.

Then we only need 10-15 lines of code in cms.php to extract the name and include the files before the main function is called. And perhaps the same to include the admin part, when admin is logged in.

Regards
Björn

[cmb]

Hello Bjorn,

Then we only need 10-15 lines of code in cms.php to extract the name and include the files before the main function is called

I guess you're right. But that would mean:
1. No plugin calls could be included in the template; so e.g. an advanced newsbox wouldn't be possible anymore
2. No plugin that uses another function name could be used unless the plugin was rewritten
3. A user who needs (1) or (2) he can't update to the new cms.php

(3) could be avoided if the changes where made in index.php of the plugin loader (IMO no problem). But I guess that (1) and (2) are very heavy restrictions. At least a user must know if (1) or (2) are no problem in his case, before he can update to the faster plugin loader.

Because of the incompatibilities I would not recommend to publish such a new plugin loader. But it could be used in particular projects, where (1) or (2) are no problem, and where the performance gain is needed, because there are many plugins installed.

Christoph

[johnjdoe]

Because of the incompatibilities I would not recommend to publish such a new plugin loader.

Full ack! But the ideas with the "stub solution" are not bad at all guys ...

[bjorn]

Hi Christoph

You are too pessimistic

A new INCLUDE-ON-DEMAND module system could be parallel to the present plugin system.

Plugins that are invoked from the templates have to be included every time CMSimple answer a request or you get a blank screen. Here your idea about having the plugin's index.php as a stub would be very good.

But still CMSimple has two wasteful solutions we should try to do something about: The automatic including of all plugins every time and the big content.htm. To compare I have done some testing with a CMS script where each page are a separate file and where plugins are included on demand. When I benchmark it I got 0.00x seconds per request when CMSimple usually spends 0.0x or at worst 0.x seconds.

Cheers!
Bjorn