Visvanath Ratnaweera

Whenever I think, "Too good to be true", I'm rarely disappointed. There goes text files.

On what motivates us: Tens of thousands posts and still misunderstood? Well, that is final.

Oh, wait! There is this new service called Chat something, something that explains the world to those who don't understand. Yes, yes, that makes any further participation unnecessary. Let's call it a (bad) day.

 

P.S. That one was not meant to go in a tangent. Little chance of seeing me even in the main discussion.

+1

I didn't plan to reply to this discussion, since it talks CPanel/WHM - not the Unix command language. It is your choice. AFAIC you have a native (VPS or dedicated) Linux server with the whole power of the shell. You are just giving it up.

OK, I believe the Cpanel/WHM-type (GUI) will work for a couple of Moodle instances. Try doing it for 79 Moodle sites! If you manage to keep your sanity, you co-worker/successor will definitely not!

 

The answer is scripting. For 79 I would go even further than mere shell scripts towards Ansible or something similar. With some leg work your aim can be reached with just plain shell scripts though. Yeah, for that you need to learn the Unix command language we sometimes call the Shell. With that alone you can make rudimentary scripts, say three different scripts to add Moodle site. Say "step1.sh foo bar" will create a foo.conf in /path/to/web/server/sites-available and create /path/to/html/bar as its web root.

 

Still, kudos to you: You've chosen pure text as the format for your documentation (as opposed to office formats). Although pure text is powerful, the original Unix design paper was plain text, as well as all the RFCs. But I doubt whether your audience will be able to digest plain text. Maybe mark-down is an alternative.

 

When we are at mark-down, how do you imagine the people here to contribute? In a never ending forum thread? We already have a couple of threads on the same or very much related subjects each reaching 100 posts (and still going). The Moodle-like solution would ne the Wiki activity. Or for more geeky, use a Git work-flow. But don't use blanks and other special characters in file names, if you want to collaborate with geeks!

You said:
> They [phones] are pocket sized internet connected computers with the ability to do almost everything traditional computers can do.

Really? I can't. Am I dumb?

BTW, the misnomer: Yeah, when the previous speaker said "mobile phones", he must have meant smartphones. This discussion is about smartphones, as the subject line says.

Ken

No the report builder is a GUI thing. Triggered the most suspicious one, a report of users and total file size. It is the source of two of the slow SQLs in the OP:

# Query_time: 19.804551 Lock_time: 0.000142 Rows_sent: 1 Rows_examined: 5450384
# Rows_affected: 0 Bytes_sent: 68

# Query_time: 12.460410 Lock_time: 0.000232 Rows_sent: 30 Rows_examined: 3768716
# Rows_affected: 0 Bytes_sent: 8322

Although I ran it at a busy hour, 8 am local time, it didn't cause the same violent reaction a couple of days ago (the reason to start this thread). Still monitoring, hoping that it will happen again. Till then nothing to do here.

Note that, the report is allowed (and expected) to be heavy - as long as it doesn't trigger at peak hours! For that I have to find out what that is, that is what this whole discussion is about.

 

It is clear to me that, I can't be 100% sure. When it happened the slow query logging was not active. I'm just speculating (hoping ;) that it'll happen again. See this reply for details.

It is indeed /report/questioninstances/. Ran is at a busy time, 8 am:

# Query_time: 22.115580 Lock_time: 0.000194 Rows_sent: 1098 Rows_examined: 7314774

Didn't cause any of the adverse effects I observed here. In that sense the search result is negative. I am still monitoring, therefore leaving this thread open.