A part of the information entered by users is cached and served directly from cache when requested. At the moment of writing this documentation all blog posts and all profile answers entered by members are saved to disk. In the future more data may be cached if needed. Caching data takes the load off the database which is the main bottleneck when serving data so it should improve page loading times and should allow for more visitors at once on your site.
However, caching data presents at least one downside: the displayed data might not always contain the most recent changes. This is especially visible when searching for a member right after he/she joined the site. The cache is refreshed by the cron job every 10 minutes. To save some work, it refreshes only the changed profiles, no point in refreshing a profile that has not been changed lately.
If a profile doesn't appear in searches within 10 minutes after approval then it is a sure sign that your cron job is not running.
See the cron job documentation for more info on how to set it up.
This 10 minutes delay is acceptable for a dating or social networking site especially comparing the advantages the caching system provides. In a live site, it doesn't really matter if a member appears in results now or in 10 minutes from now on. This could be a confusion only in test environments when the tester is not aware of this delay.
One thing to note is that the admin interface is not using the cached data, it always works with the database on the most recent data available. This is because an admin might want to approve/reject a member profile faster than 10 minutes and it should do it based on the most up to date information.
Same thing happens in the member interface when viewing and modifying your own profile. Making a change to your profile then seeing the cached (old) data would lead to confusion. That's why there are 2 scripts that display the profile: profile.php is used to display the profiles of all other members but yours and it uses the cached information and my_profile.php is used to display your own profile and it uses the database and the most up to date information. When viewing your profile after you made a change, other members would still see the old data for up to 10 minutes, until the cache is refreshed.
To further lower the cost (time and resources consumed) of a search against the database, the results of a search are saved and further use of exactly the same search will retrieve the results much faster and without putting much load on the database. This cache is very useful when moving to the next page of a multi-page result list: Instead of searching for members on every page then selecting only results from say 10 to 20 for the second page, we simply select members from 10 to 20 from the list of members already found when looking at the first page. But this search cache is used between different member searches too: if one member did the exact same search as another member, there's no point in searching again, we already have the results in the search cache and we're using that instead.
Etano community builder is sending headers to the visitor browser that provide information regarding page "freshness". Browser caching helps reducing server load by caching visited pages on the visitor's computer. If a page hasn't been changed since the last visit then the page is not requested again from the server but is instead served from the browser cache. This may lead in some cases to slightly inaccurate data on pages but the advantages of having such a caching system active are greater than the disadvantages. For example if a member has an unread message in his/her inbox, clicks on it to read it and then hits the back button of the browser to return to the inbox, the message would still be displayed as unread until the browser cache is refreshed with the latest data.
How it is organized, how to change the time between 2 tasks, how to add or remove new tasks.
Use your shared memory, Memcache, PHP accelerators, Compressed content, Mysql optimization (buffers/query cache/queries), More servers & separation of tasks