in reply to Multithreaded (or similar) access to a complex data structure

Up front. I've done very little CGI/webserver stuff at all.

That said, I think that you are breaking the cardinal rule of presentation layer work, by mixing your presentation layer code and your 'application logic' code together in your CGI code.

(IMO) your application should be split into two distinct parts:

  1. The Application Logic.

    This is a process that talks to your DB (and any other places it gets information) to build and maintain your datastructure.

    And periodically -- once a minute or once every 10 seconds or whatever frequency makes sense -- uses the information it holds to write a formatted web page to the web servers filesystem.

  2. The CGI script (URL responder).

    This is a standard CGI or mod_perl script that when it receives a connection, just reads the latest formatted page from the file system and sends it to the browser.

By disconnecting the production of the page from the connections to the webserver, you ensure that no matter how thick and fast the connections arrive you can deal with them in a timely manner whilst imposing minimal load on your critical, public-facing front end, because they are in effect just responding with a static page. The latest updated version that is available. It also ensure that you don't hammer your DB requesting the same information over and over for every page request that arrives.

Indeed, you could do away with the cgi completely and serve the webpage directly from the file-system though I don't know how the webserver would handle it if the file was in the process of being written when a request came in?

And by disconnecting the production of the page from inbound requests, it allows you to choose the frequency with which you update that page. Whether that be on the basis of every few seconds, or when a significant event occurs or whatever makes sense to your application. And you only need to maintain one copy of your complex data structure in memory.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Multithreaded (or similar) access to a complex data structure

Replies are listed 'Best First'.
Re^2: Multithreaded (or similar) access to a complex data structure
by FloydATC (Deacon) on Nov 07, 2011 at 06:00 UTC
    Up to a hundred changes can happen to the data structure every few seconds and there are so many ways to view it, this would mean literally hundreds of thousands of pages that would have to be cached every few seconds just in case some operator decided to have a look at it from just that perspective. (And that's just with the current data set, which is expected to expand tenfold over the next few years)

    Presentation logic is built into each object node because only "it" knows how to present itself based on information about the connected nodes and its own capabilities. For instance, if there is a problem somewhere in the network that affects "it" in one of many ways, "it" will show a warning color. This warning state propagates to other nearby nodes like site/area status pages, dynamic maps and so on. Except when an operator has told "it" not to, e.g. because a device is in maintenance mode.

    I try not to think of this in terms of web pages but rather as a visual representation/manipulation of a dynamic data structure using SVG glued together with HTML.

    It works beautifully. If only I could find a way to do it in paralell, it would be awesome.

    -- Time flies when you don't know what you're doing
[reply]
      (And that's just with the current data set, which is expected to expand tenfold over the next few years)

      And therein lies the root of your problem. It's not just your implementation that doesn't scale, but your design.

      You are running a very complex simulation representing many discrete, real-world entities that communicate asynchronously. And you are running that simulation on single processor that has to iterate its way over a single, huge God-object in order to simulate all those asynchronous communications and concurrent state changes.

      If you attempt to then further complicate that by having multiple threads concurrently iterating their way through that God-object deriving their own particular views of it, they will need to apply locks either universally or to discrete chunks of the data structure in order to derive a consistent 'snap-shot in time' view of the entire entity.

      Each new viewer will therefore be impinging and impeding every other viewer, and as the number of viewers grows, so the time spent waiting for locks will grow exponentially. And as the size of the network grows, so the time required to perform a single traversal -- whether to update the status of the nodes as the effects of the state changes of individual nodes ripple through to their neighbours, and then to their neighbours, and then to theirs; or in order to gather a particular view of the instantaneous state of the network for a particular viewer -- grows exponentially as well.

      Sorry to be the bearer of bad tiding, given that you've almost certainly expended considerable effort on achieving what you have already, but your design is unsustainable. Adding further complexity to it -- in the form of concurrent viewers with all the additional lock contention and the potential for cascading deadlocking they represent -- will only further hamper your ability to run the simulation in anything like real time.

      The only realistic way forward is to:

      1. Distribute your network representation across multiple processors.

        Ie. break your God-object into manageable chunks each maintained by a different processor.

      2. Distribute the view building.

        By divorcing the presentation logic from the state maintenance.

        I encourage you to think about how Google et al. manage to respond to millions of viewers to their simulations of the entire web in real time. They distribute the state of their model (and the maintenance of that state) across a huge farm of processors. And then service view requests by having front-end processors request the relevant state from that back-office farm before gathering it all together to build their particular view.

      That is a bitter pill to deliver, and far worse to swallow, but I seriously believe it is your only way forward. Sorry. I wish you the very best of luck.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Well, you've certainly reminded me why I hate and fear multithreading. A flawed design is only a waste of time if you don't learn from it, right? I'll keep meditating on this. :-)
        -- Time flies when you don't know what you're doing
[reply]

In Section Seekers of Perl Wisdom