Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Assuming that there is little that can practically be done to speed up the engine to the site, is there anything practical that could be done in other areas?

Given the large number of members (even if only the 'active' ones are considered), I for one would be more than happy to contribute a one-off $10 to a dedicated hardware fund if this would cut my waiting time for pages. If a (preferably dedicated) fund for faster hardware was established, it might be easily fulfilled.

  • Would the ISP agree to allow the new hardware to be used?
  • Would moving the existing codebase and database to new hardware be a reasonably simple transition?
  • Would a straight 1-4-1 replacement do any good? I don't know what the current hardware is, but if it was already a dual-2MHz set-up, it would require more than just a simple/ cheap hardware replacement.
  • Would it be possible, given the current software setup, to gain by adding a another box, rather than replacing one?
  • If adding boxes is possible and beneficial, what are the limits? There are probably more than a few Monks that have 'old boxes' lying around that they would be willing to donate to the cause if this was a viable solution.
  • Given the site already violates the taboo of frames (the <IFRAME> used by the advert), would it not be a reasonably simple process to modify the Chatterbox nodelet to sit in an <IFRAME> of its own, and have the whole CB laid off to a separate, dedicated box?

    Given that it is only transient data, it wouldn't have to access the DB (I think?) so could be a pretty much stand alone entity, and (so long as people use the talk button for refresh), would probably go a long way to relieving the CB related loads on the main server(s)?

  • Maybe there is some mileage in have a second database box. It could be a fall-over backup for the main DB server, and could be used to handle such things as the titlebar search box and super search pages. It could be trickled updates/ new content from the main server by a low priority process on the main DB.

    I realise that this means that these searches would possible miss on the very latest content. Would this be a disaster? If the current backup (to whatever medium) from the main DB were done as replicates to the backup server, the backup server could takeover the backup to tape/CD whatever.

I also realise that I know nothing of the Everything engine nor the current hardware set-up, and that if these types of optimisations are to be considered, the first step would be to do the analysis to see what and where the bottlenecks in the system are.

I currently have both the time and enthusiasm to take on some of this work if it was deemed desirable. Whilst I don't have the requisite skills in the Everything engine (nor probably Perl) to be let loose on the servers, if (for example) the logs were zipped up and made available to me, I do have the skills and the time to perform analysis of them. I could then return the results to tye or whomever for verification and further action.

If there is any other way (beyond the obvious cash contributions) that would help in this particular regard, I'm all ears.


Well It's better than the Abottoire, but Yorkshire!

In reply to Re: perlmonks too slow by BrowserUk
in thread perlmonks too slow by Jaap

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2024-03-29 05:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found