No you did not offend me. I was only highlighting that your words were strong. Which means that by labeling something as a bad idea, you are closing the door on an possibly feasible solution. if you use analytics on your server, you might have already noticed that almost all analytics solutions provide their "counters" via javascript. Depending on what you are counting, it may be a "bad idea" to do counting on the server side before requests are served. In case of pageviews, until a page is actually served completely on the browser, it might be a "bad idea" to count it as a pageview - that is one of the reasons why analytics tools count pageviews after browsers render them. (additionally, analytics tools may count the number of images, or number of links on a page and other such info). as for persistence, many high volume sites prefer to do counters (analytics) after the page has been served because they dont want any additional performance in the path of a view viewing the page. Moreover, as your original query suggested, most high volume sites will cache their pages either in a cache such as the opencms flexcache or fatwire's (another cms) satellite cache or something as rudimentary as apache web server's memcache. For them, it is a "bad idea" to make a network request from the cache layer to the application layer just for incrementing a counter.<br>
<br>All this is in the interest of good ideas and good discussion and i would highly recommend to not just ignore it even if it does not ring a bell.<br><br>Best,<br>Tim<br><br><div class="gmail_quote">On Wed, Mar 24, 2010 at 5:11 AM, Roman Uhlig  Maxity.de <span dir="ltr"><<a href="mailto:roman.uhlig@maxity.de">roman.uhlig@maxity.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
I'm sorry if I offended you with what I said. It was meant constructive and should only raise your awareness that your proposed solution intentionally doubles every one of your requests. If that is not a potential problem for your server environment or doesn't ring bells at least, then just ignore it. ;)<br>

<br>
Chuck, we have a similar solution running right now with OpenCms, which would basically have to an database update/insert for every request. Through buffered database writing (application bean buffer + jdbc bulk insert) every 100 requests or so this is not a performance problem at all (at least not for the database server).<br>

<br>
Roman<br>
<br>
________________________________<br>
<br>
Von: <a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a> [mailto:<a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a>] Im Auftrag von Chuck Mysak<br>
Gesendet: Mittwoch, 24. März 2010 08:21<br>
<div><div></div><div class="h5">An: The OpenCms mailing list<br>
Betreff: Re: [opencms-dev] Flexcache counters<br>
<br>
<br>
Request are not bad ideas. And there are no bad ideas, only problems that appear.<br>
<br>
The most important problem that arises is the persistence that has to happen at the request. For instance, the database that holds these values for each page that has to be updated on each request. Or the big hashtable (pages, counts) that has to be serialized and persistent between sessions. That could bring down the server performance-wise.<br>

<br>
Thanks,<br>
<br>
Chuck<br>
<br>
<br>
On Wed, Mar 17, 2010 at 6:23 AM, Tim Daschner <<a href="mailto:timd@thedoleco.com">timd@thedoleco.com</a>> wrote:<br>
<br>
<br>
        those are strong words. But I take your word that those must surely be bad ideas for the world you are in. in general, a web request to your server is not exactly a bad idea. in general network is cheap and fast. again, in general, client side technology is also capable of javascript/ajax and such. so i dont see that as a bad idea in general.<br>

<br>
<br>
<br>
        On Mon, Mar 1, 2010 at 5:58 AM, Roman Uhlig Maxity.de <<a href="mailto:roman.uhlig@maxity.de">roman.uhlig@maxity.de</a>> wrote:<br>
<br>
<br>
<br>
                In your suggestion the Ajax is client sided, so every Ajax call creates an additional request, thus doubling the requests to your server. Bad idea.<br>
<br>
                I'd stay pure server sided, e.g. with an application bean or something similar.<br>
<br>
                Roman<br>
<br>
<br>
                ________________________________<br>
<br>
                Von: <a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a> [mailto:<a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a>] Im Auftrag von Tim Daschner<br>

                Gesendet: Freitag, 26. Februar 2010 05:35<br>
<br>
                An: The OpenCms mailing list<br>
                Betreff: Re: [opencms-dev] Flexcache counters<br>
<br>
<br>
                would an ajax call from your html to a servlet work? that servlet could count hits to your page and update the html too. just an idea.. i would say the code would be trivial too.<br>
<br>
<br>
                On Tue, Feb 23, 2010 at 9:04 AM, Roman Uhlig Maxity.de <<a href="mailto:roman.uhlig@maxity.de">roman.uhlig@maxity.de</a>> wrote:<br>
<br>
<br>
<br>
                       > find someone who will implement  this<br>
<br>
<br>
                       Hmmm, my planner says NO. ;)<br>
<br>
                       But I'll put it on my open source TODO list, maybe there's an unexpected gap between projects. *hope springs eternal*<br>
<br>
<br>
                       Roman<br>
<br>
<br>
                       -----Ursprüngliche Nachricht-----<br>
                       Von: <a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a> [mailto:<a href="mailto:opencms-dev-bounces@opencms.org">opencms-dev-bounces@opencms.org</a>] Im Auftrag von Achim Westermann<br>

<br>
                       Gesendet: Dienstag, 23. Februar 2010 15:21<br>
<br>
                       An: The OpenCms mailing list<br>
                       Betreff: Re: [opencms-dev] Flexcache counters<br>
<br>
<br>
                       Hi Roman,<br>
<br>
                       > Tho plain storage of resource access counters in a database would not work with OpenCms pages with high load in terms of performance (1 insert per hit).<br>
<br>
                       hmmm doubts!<br>
                       In a clean website with optimal caching the idea is that those insers would only happen for each variation in the cache. OK after something<br>
                       is published that will happen all over again.<br>
<br>
                       > I.e. we've developed an application bean for that, which collects these data, processes and consolidates them and stores them as bulk data in a database. Still creates about 20 GB of data per year. ;)<br>

<br>
                       OK, then lets add that requirement too and continue to find someone who will implement  this for the benefit of being a hero!<br>
<br>
                       kind regards,<br>
<br>
                       Achim<br>
<br>
                       _______________________________________________<br>
                       This mail is sent to you from the opencms-dev mailing list<br>
                       To change your list options, or to unsubscribe from the list, please visit<br>
                       <a href="http://lists.opencms.org/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/mailman/listinfo/opencms-dev</a><br>
<br>
                       _______________________________________________<br>
                       This mail is sent to you from the opencms-dev mailing list<br>
                       To change your list options, or to unsubscribe from the list, please visit<br>
                       <a href="http://lists.opencms.org/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/mailman/listinfo/opencms-dev</a><br>
<br>
<br>
<br>
<br>
                _______________________________________________<br>
                This mail is sent to you from the opencms-dev mailing list<br>
                To change your list options, or to unsubscribe from the list, please visit<br>
                <a href="http://lists.opencms.org/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/mailman/listinfo/opencms-dev</a><br>
<br>
<br>
<br>
<br>
<br>
        _______________________________________________<br>
        This mail is sent to you from the opencms-dev mailing list<br>
        To change your list options, or to unsubscribe from the list, please visit<br>
        <a href="http://lists.opencms.org/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/mailman/listinfo/opencms-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
This mail is sent to you from the opencms-dev mailing list<br>
To change your list options, or to unsubscribe from the list, please visit<br>
<a href="http://lists.opencms.org/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/mailman/listinfo/opencms-dev</a><br>
</div></div></blockquote></div><br>