Merlijn van Deen wrote:

If a connection pool were to be implemented, this problem should be fixed, too. It would just make searches a bit slower, as the 16th search would have to wait for an earlier search to finish.

--valhallasw

If connections -made by a human asking the service- need to wait, more will arrive and need to wait for the 16th to end (when users may have already canceled/refresh the request).

I believe the search capacity is limited due to server load. ~~~~

On 2/20/07, Sean Whitton (Xyrael) sean@silentflame.com wrote:

On a side point, this is an extremely impressive tool. I've noticed that MediaWiki's search isn't great, and I was wondering if there is any particular reason for this that has been documented somewhere. It'd make an interesting read.

Thanks.

On 2/20/07, Larry Pieniazek lar@miltontrainworks.com wrote:

...

Hi all!

Apologies if this was already asked, but TangoTango wrote a very nifty search tool, mayflower.

http://tools.wikimedia.de/~tangotango/mayflower/search.php?q=mayflower&t...

...

See it here on the test wiki:

http://test.wikipedia.org/wiki/Special:Search

...

(you may need to be logged in)

It's really great, and it got added to commons http://commons.wikimedia.org/wiki/Special:Search

But unfortunately it's bumping into the 15 connection limit already.

---

Advanced search Please wait, searching for "mayflower"...

Warning: mysqli::mysqli() [function.mysqli-mysqli]: (42000/1226): User 'tangotango' has exceeded the 'max_user_connections' resource (current value: 15) in /home/tangotango/public_html/mayflower/search.php on line

258

...

Warning: mysqli::query() [function.mysqli-query]: Couldn't fetch mysqli

in

...

/home/tangotango/public_html/mayflower/search.php on line 287

Warning: main() [function.main]: Couldn't fetch mysqli in /home/tangotango/public_html/mayflower/search.php on line 469

Error:

Warning: mysqli::close() [function.mysqli-close]: Couldn't fetch mysqli

in

...

/home/tangotango/public_html/mayflower/search.php on line 472

---

Please consider raising that limit, a lot. Not sure how much but a lot because commons searches are quite frequent.

Thanks!

Larry Pieniazek Work mail: lpieniaz at us.ibm.com Hobby mail: lar at miltontrainworks.com

...

Message: 1 Date: Sun, 18 Feb 2007 00:25:47 +0100 From: "DaB." wp@daniel.baur4.info Subject: [Toolserver-l] New limitation of mysql-connections To: Toolserver-ML toolserver-l@lists.wikimedia.org Message-ID: 1171754747.3681.2.camel@DanielX.intern.baur4.info Content-Type: text/plain; charset="us-ascii"

Hello all,

I created a new limitation of 15 mysql-connections at the same time by a user (after a user flooded mysql with a few dutzend connection a few time ago).

If someone need more connections, please mail me, the limit can set per user.

Have fun :).

Sincerly,

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

-- —Sean Whitton (Xyrael/xyr) sean@silentflame.com http://xyrael.net/

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

On 3/1/07, Peter M Dodge twicescorned@gmail.com wrote:

The connection limit is really killing Shadow1's Shadowbot that is an essential spamfighting tool on the English wikipedia. Is there no better way we can limit traffic? Can it not be throttled to a certain throughput, for example?

Why does a bot need many simultaneous connections?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I honestly have no idea why the bot is stalling. I highly doubt that it's tripping the 15 per second limit, as it makes that many reversions per hour on average. The only problem I can see is that I have ridiculously inefficient MySQL code, so I'm planning on optimizing that so that it makes less queries per revert.

I'm going to do some debugging and see what's up.

Alex Rowe

On 13:09 Thu 01 Mar 2007, Peter M Dodge wrote:

You'd have to ask Shadow1, I'm not privvy to the inner workings of the bot, but ever since that limit was put in place the bot's been repeatedly stalling.

Peter M Dodge aka Wizardry Dragon Wikipedia Editor, CheckUser Clerk, en.wikipedia.org

On 01/03/07, Gregory Maxwell gmaxwell@gmail.com wrote:

...

On 3/1/07, Peter M Dodge twicescorned@gmail.com wrote:

...

The connection limit is really killing Shadow1's Shadowbot that is an essential spamfighting tool on the English wikipedia. Is there no

better

...

way we can limit traffic? Can it not be throttled to a certain

throughput,

...

for example?

Why does a bot need many simultaneous connections?

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

While I don't know much about how the bot works, but as I understand it is one continuously running IRC bot. The only situation I can image when the bot is hitting the limit is when it establishes a new connection every time it runs a query, which would be a Bad Thing (TM). But if that's the case, a better solution (both for the database server's and bot's efficiency) would be to create and maintain only one mysql connection for the entire bot's operating time (or one per running thread).

Regards, Misza

2007/3/4, Peter M Dodge twicescorned@gmail.com:

Nonetheless we cannot deny that it has started acting up since then. Of course tightening the MySQL code will help, but ultimately I think that realising that the connection limits may need to be a little more flexible isn't a bad thing. -- Peter M Dodge aka Wizardry Dragon Wikipedia Editor, CheckUser Clerk, en.wikipedia.org

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

As far as I (and the silent members of #perl) can tell, the Perl Object Environment (Shadowbot's multitasking module) doesn't use fork or threads to run queries with the MySQL object in Shadowbot. So, the bot should only have one connection to the MySQL server at any point. And even if there is one MySQL object being established for each thread, ie each reversion, they would still be destroyed at the end of the revert.

Alex Rowe

On 17:04 Mon 05 Mar , Andrew Garrett wrote:

Right. The solution is better code, not more permissive systems administration.

---

Andrew Garrett aka Werdna ex-Wikipedia Editor, Developer, ate muesli bar for breakfast, currently drinking a Coke, got elected to SRC when he was 10. www.mediawiki.org

-----Original Message----- From: toolserver-l-bounces@lists.wikimedia.org on behalf of Misza13 Sent: Sun 3/4/2007 8:57 PM To: toolserver-l@lists.wikimedia.org Subject: Re: [Toolserver-l] Raising the connection limit for tangotango

While I don't know much about how the bot works, but as I understand it is one continuously running IRC bot. The only situation I can image when the bot is hitting the limit is when it establishes a new connection every time it runs a query, which would be a Bad Thing (TM). But if that's the case, a better solution (both for the database server's and bot's efficiency) would be to create and maintain only one mysql connection for the entire bot's operating time (or one per running thread).

Regards, Misza

2007/3/4, Peter M Dodge twicescorned@gmail.com:

...

Nonetheless we cannot deny that it has started acting up since then. Of course tightening the MySQL code will help, but ultimately I think that realising that the connection limits may need to be a little more flexible isn't a bad thing. -- Peter M Dodge aka Wizardry Dragon Wikipedia Editor, CheckUser Clerk, en.wikipedia.org

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

On 05/03/07, Peter M Dodge twicescorned@gmail.com wrote:

On 05/03/07, Alex Rowe alex.d.rowe@gmail.com wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

As far as I (and the silent members of #perl) can tell, the Perl Object Environment (Shadowbot's multitasking module) doesn't use fork or threads to run queries with the MySQL object in Shadowbot. So, the bot should only have one connection to the MySQL server at any point. And even if there is one MySQL object being established for each thread, ie each reversion, they would still be destroyed at the end of the revert.

Alex Rowe

On 17:04 Mon 05 Mar , Andrew Garrett wrote:

...

Right. The solution is better code, not more permissive systems

administration.

...

---

Andrew Garrett aka Werdna ex-Wikipedia Editor, Developer, ate muesli bar for breakfast, currently drinking a Coke, got elected to SRC when he was 10. www.mediawiki.org

-----Original Message----- From: toolserver-l-bounces@lists.wikimedia.org on behalf of Misza13 Sent: Sun 3/4/2007 8:57 PM To: toolserver-l@lists.wikimedia.org Subject: Re: [Toolserver-l] Raising the connection limit for

tangotango

...

While I don't know much about how the bot works, but as I understand

it is

...

one continuously running IRC bot. The only situation I can image when the bot is hitting the limit is

when it

...

establishes a new connection every time it runs a query, which would

be a

...

Bad Thing (TM). But if that's the case, a better solution (both for the database

server's

...

and bot's efficiency) would be to create and maintain only one mysql connection for the entire bot's operating time (or one per running

thread).

...

Regards, Misza

2007/3/4, Peter M Dodge <twicescorned@gmail.com >:

...

Nonetheless we cannot deny that it has started acting up since

then. Of

...

...

course tightening the MySQL code will help, but ultimately I think

that

...

...

realising that the connection limits may need to be a little more

flexible

...

...

isn't a bad thing.

Peter M Dodge aka Wizardry Dragon Wikipedia Editor, CheckUser Clerk, en.wikipedia.org

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

...

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7MXbSP+CFq0x+hYRAv9XAJwIAYOh9v5WOkmpBWewHU/cZRzujgCgpBBY /pb7fVBtfmyVoFnDWgNReZs= =CaH6 -----END PGP SIGNATURE-----

---

Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l

That's what has me confused, myself. It shouldn't be creating multiple connection instances.

Peter M Dodge aka Wizardry Dragon

It occurs to me - is the limit 15 *connections* or 15 *transactions* because if it is the latter that would be it right there.

Peter M Dodge aka Wizardry Dragon Wikipedia Editor sco.wikipedia.org