Daemon mode

[Alexander Obuhovich]

There are situation, when there is a need to process large amounts of data in short time. 

To do that I propose to minimize action count, that In-Portal performs during it's initialization including:

• doing database queries that won't help to perform requested action (e.g. loading phrase cache, when phrase are not used at all)
• performing initialization of system parts that are not used (e.g. session initialization, when no login is made)

In total In-Portal is temporarily converted to sort of unix-like daemon (standalone service), that quickly performs given requests. That's why I called such operation mode as "daemon mode".

Usage (one of following):

- add $_CONFIG['Misc']['DaemonMode'] = '1'; to "system/config.php" file when system-wide daemon mode is required

- add define('DAEMON', 1); in PHP file, where daemon mode is required (e.g. cron.php, run_event.php, index.php, etc.); it should happen before FULL_PATH constant definition

Tables never used in daemon mode: 

- CachedUrls (mod-rewrite caching won't work)

- PhraseCache (phrase and configuration variable caching won't work)

- Counters (counters, like member count won't work)

- ThemeFiles (for mod-rewrite url parsing)

- CustomField (no custom field data can be accessible)

- Forms (new forms are not added to admin tree for their submission reviewing)

Proposed database table permissions that should be at least for this to work:

GRANT SELECT ON `inportal_database`.`inp_Phrase` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_ConfigurationValues` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_Language` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_Modules` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_Theme` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_Skins` TO 'inportal_user'@'localhost';

GRANT SELECT ON `inportal_database`.`inp_SiteDomains` TO 'inportal_user'@'localhost';

As you can clearly see there is only 7 database table needed, instead of 71 tables, that could be used (I'm not saying that all of them are used on each run).

What won't be working:

- building links using "use_section" parameter of "m_Link" tag

- new agents are not added based on found "RegularEvents" unit config option (already existing agents will work of course)

- new records in Category table are not added based theme file scanning (so you should do "Rebuild Theme Files" while daemon mode is off)

- importing language pack

- new theme file discovery (for mod-rewrite url detection)

For all this to work you need to enable memcache caching.

Task: http://tracker.in-portal.org/view.php?id=973

Ready for testing.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

Impressive work, thank you for this usefull patch, improving request execution time is critical for serious websites!

2011/1/25 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

As I've suspected you thought, that you just could enable daemon mode on the site to make it faster. 

Unfortunately that's not the purpose of that patch. Since it completely disabled usage of custom fields and mod-rewrite urls and template-based phrase caches, then you will only break things down. By dramatically increasing performed database query count.

While daemon mode in effect it can't be used for template display or link building.

[Phil -- wbtc.fr --]

hehe, thanks for clarification :)

2011/1/25 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Pretty impressive.

Do you think we should consider this for 5.1.x or 5.2.x? I personally this we need to find the way to skip the IFs and make it flexible using the powers OOP which means 5.2.x might suit it better.

Also, imagine you need to merge this if we still do it for 5.1.x. What's your opinion?

DA

[Alexander Obuhovich]

I'm not in a hurry to commit this patch, since we don't have any direct application for this.

Maybe later.

[Dmitry A.]

Ok, Agreed - let's wait for 5.2.0.

Please try to see how it can be properly plugged-in into 5.2.0 architecture.

DA