貼文的作者是 Visvanath Ratnaweera

Particularly helpful Moodlers的相片 Translators的相片
Could "MaxConnectionsPerChild 0" be the critical setting? Counter-intuitively allowing the to rise indefinitely released a throttle? You mentioned a DOS earlier. Is it possible that Chrome in combination with a router at the server end flood the server network sockets?

The classical Linux tool to check is netcat. Only recently I came to know about a BSD tool called netsock(?) compiled for Linux.
Particularly helpful Moodlers的相片 Translators的相片

The first thing that came to my mind was H5P. There is a forum dedicated to H5P. Have a careful look. There were some ups and downs recently - at least in my view.

There other products that appear in this connection are Gambas, GeoGebra,.. 

評比平均分數:Useful (2)
Particularly helpful Moodlers的相片 Translators的相片
Hi Marcus

So, you say that you see the exercise as hugely problematic. Noted.

@others

Have you done a major upgrade of that scale? What was the strategy you followed? Were you happy with it? What were the problems encountered?
Particularly helpful Moodlers的相片 Translators的相片
Hi Marcus

Thanks for sharing your experience!

> I would always start with code from Git and if your local code has changes from that on Git then things can be problematic.
 
So you vote for starting with fresh core code, forgetting whatever the small changes I made in my (old) code tree. You must be right, those "core hacks" must be unnecessary in the new version - that is the whole idea. Since my code too is under Git I can always step through those changes, if necessary. As already said, I don't have problems with the core code - either way.
 
> One of the issues is that a plugin may work on it's own but have issues with updated versions of other plugins (rare but possible).
 
I want a working strategy, not issues!
 
Seriously, I took part and initiated my own discussions on versioning of plug-ins, which I don't want to repeat here in the hope that things have improved in the meantime.

> One of the issues is that you can never be sure if/how/what a 3rd party plug supports. To take an example..
 
So, left on their own, a plug-in may fall in to one of the following categories. I am taking 4.1 > 4.5 as an example, it is true for any major upgrade.
 
Type A. The same plug-in version I have from 4.1 is compatible with 4.5 - in the documentation and in practice.
 
Type B. The same plug-in version I have from 4.1 is compatible with 4.5 - in practice but not documented as such.
 
Type C. The plug-in version I have from 4.1 is not compatible with 4.5 but there is a version that is compatible - in practice but not documented as such.
 
Type D. The plug-in version I have from 4.1 is not compatible with 4.5 but there is a version that is compatible - in practice and documented as such.
 
Type E. The plug-in doesn't have a compatible version for 4.5 - according to the documentation and in practice.
 
Type F. The plug-in doesn't have a compatible version for 4.5 - the documentation is just silent.
 
Type G. The plug-in doesn't have a compatible version for 4.5 - according to the documentation and in practice but will break since it depends on a plug-in of type E or F.
 
Now to the question: Given a plug-in from that list of 100, how do you know to which category it falls in to?
 
P.S. I know, I should have made a table for those A-G types. I will make one, if an upcoming strategy requires that.