• Location
• Operating System (Windows, Linux, Apple, OS2, AIX, etc.)
• Browser (Internet Explorer, Mozilla, AOL, Opera, Lynx, etc.)
• Connection speed (Modem, DSL, Cable, Carrier Pidgeon, etc.)

And once again, thank you for using Perl Monks!

()-()
 \"/
  `                                                     

I --'ed your node because you present a problem without any indication that you are familiar with the background behind the current setup of the site.

A better way to phrase your query would be to ask about the current setup (as I understand it, two dedicated web servers talking to a single database server, web site engine by Everything2 -- see bottom of page).

Doubtless it could be made a little faster by adding more web servers or beefing up the database box (I don't know where the current bottlenecks are) but considering that good old pair Networks is providing the hosting (at some reduced price), we've probably got as much horsepower as we're going to get.

And I imagine that the open source code on which the site is based has been gone over by a number of fanatical programmers and is pretty efficient.

So apart from shelling out some $$$ (as previous respondents have indicated) I'm not sure what else can be done to speed the site up.

--t. alex
but my friends call me T.

Update: I understand that the 'Refresh' problem is one that eats up horsepower and bandwidth -- but I don't think there's a way to prevent it. Once one gets used to Perl Monks, you should never have to refresh your browser -- everything's a link or a button away.

It takes a while for most new Monks to find out about one of the CB clients: perhaps an entry in one of the starter nodes in Tutorials#monkstart would be a step in the right direction?

rdfield

<toot>I like to think my node about Perl as a coffee house explains the position well .. instead of posting right off the bat, hang out for a while and get the lay of the land. Then, when you think you know what you're talking about, ask a question.</toot>

And I'm reminded of an on-line community I belonged to in the past (don't think it was Perl Monks) where one of the members said that, being from Texas, the following was important when disagreeing with some one:

Be sure that your words are soft and sweet, on the off chance that you have to eat them.
Words to live by.

--t. alex
but my friends call me T.

Not that I've tossed any money on there myself, but I'm not expecting them to put on more hardware for me, either.
--
Mike

On behalf of the Everything Development Company, the Everything Engine, the PerlMonks founders squad, and the International League to Insure Reasonable Website Response Times I sincerely apologize.

The slowness of Perlmonks has nothing to do with resources available to us. The fine people at PAIR have given us much more hardware than we had to work with before, and have offered to get us more hardware if we need it.

The problem isn't an infrastructure issue, however -- and speaking as one of the handful of people who've had a hand in developing the site's software: It's our own gosh-darn fault. Perlmonks is WAY more complex than when it originally launched. It does a crapload of perl evals and sql queries per page. It's vulnerable to resource hogs. Searching can cripple the database. And right now, I don't think we're gonna fix these problems any time soon.

This has been a long standing issue with The other site as well -- and it seems like every site I've worked on has grown to the point where it uses it's max resources, until someone with a vested interest combs through the code and figures out a way to make it work a little bit faster for a while. Then it gets a little bit bigger and some other bottleneck pops up. It's not a matter of computer resources, as much as human engineering resources.

Please don't be ungrateful to PAIR and the resources that they've already given us. Without their and YAPC's support this place probably wouldn't exist anymore. Right now, it's enough that it's up and it's functioning, even if it's a bit retarded at times.

--Uncle nate

Please make it faster. Way faster.

I'm reminded of a sales prospect from hell that I had a few months back.

He turns from looking at my portfolio of web sites, puts it down and says, "The problem with all the web sites out there .." (I lean forward, expecting to hear something profound) ".. is that they all suck. Build me a web site that doesn't suck. And can you make it so that the web site comes out at the top of the list on all of the search engines?"

Well, gee, all you had to do was ask.

All that to say (or reiterate, as it seems you've touched a nerve here today), this site hasn't been built to be slow. That's not an undocumented feature. Behind the scenes there are a lot of things going on to keep the content up to date.

If you are seriously interested in helping make Perl Monks faster, excellent!

Now tell us what you can do to support this terrific on-line community.

--t. alex
but my friends call me T.

1. Learn the Everything engine. Literally everything you see around the monastery runs on the Everything engine. I've looked at the source code and it is by far one of the best code I'd ever seen in my career as a Perl programmer. For one, I know I couldn't have written any better. Once you've learned the trade, spend some time hacking away at a solution. And as soon as you notice anything viable, let the rest of the community know. If proven worthwhile, I'm sure the gods will amend the way monastery runs (in the back-end).

2. Donate as much as you possibly can. This will help the gods to invest in better hardware to run their monastery on. This is by far the simplest solution, yet comes at a cost, not surprisingly :). However, if you seem to value your time more than the total sum you could dedicate towards the offerring plate, then by all means consider this option.

# Under Construction
[download]

update: by the way, I --ed you cause your comment is ignorant at best (you made no mention of your connection speed or any kind of relevant concrete details~ how many bytes is an average page you download?).

____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy.

Go to User Settings and turn off your own nodelets. That will help some.

-sauoq
"My two cents aren't worth a dime.";

Must be your end too, Jaap, I get them (at least partially) in under three seconds - that's on an ISDN connection 13 hops away from the server (only one of them being any bottleneck at all). Try tracerouting and see if the problem ain't more on your end.

Yes, the server does a fair deal of work for each page request, but I can't complain. Since the move about half a year ago PM isn't any slower than the rest of the web for me and the limited bandwidth I have. Get a 56k and you won't be so spoiled.. :^)

Makeshifts last the longest.

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.

MAJOR speed improvements can be mase with small changes.

Go for it.

If 5 seconds is such a problem for you, then go to user settings and select the "All Nodelets Off" option and it will only take about 2 seconds (based on my testing) per page.

Voting is a bit of a fickle thing. It is easy for people to be put off by you criticizing the site without demonstrating (in your original node) any understanding of how the site is implemented, its history, how it is administered, etc.

You don't mention that you realize that you aren't paying anything for the benefit you get from this site and you don't acknowledge that those who would have to make it faster do all of their work without being paid a penny for it. And then you casually say just "Make it way faster". Yep, I can see how many could be a little put off by that.

And the nature of the voting system is such that if you write something that will make a small impression on a large number of people, then you get a large number of votes. So you didn't do anything horrible, but you might get quite a few downvotes because of it. But checking, I see that your root nood currently has a rep of -2! How do you jump from such a slightly low rep to "Well, it is obviously 'not done' to complain"??

But as i understand, MAJOR speed improvements can be mase with small changes.

Yes, and we have tons of these simple, huge speed changes sitting around but we haven't put any of them into effect because it never occurred to us to do so. Thanks for pointing out that we should just make a simple change to cause the site to be "way faster".</sarcasm> (: Do you assume we are just completely imcompetent? If it were trivial to make the site lots faster, we probably would have already done so.

We actually have made quite a few changes to make the site faster. Of course, these don't always keep up with the increasing popularity of the site. We have quite a few more changes that should help make the site faster as well. Unfortunately, I don't have a lot of free time to work on finishing these changes with working the job that pays to feed my family and trying to help raise my children. The situation is much the same for the others that volunteer to work on this site.

I enjoy working on this site, but I really can't spend much time doing it (I wish I could spend more). If you seriously think you can make a big difference in the speed of the site, then you'll have to do a whole lot of research without taking up other peoples' times with lots of questions if you hope to save "us" more time than you consume. I encourage you to do that. The source code for the basis for this site is just three mouse clicks away right now.

        - tye (but my friends call me "Tye")

On average i would say it takes about five (5) seconds for a page to display, where an average page on the internet would take 0.5 secs.

Whatever you may think of it, I can't see it as good publicity for the Everything system.