Meta:Historical/Why Wikipedia runs slow

Deleted via RfD in July 2009, after a surge of interest

January 6, 2022

I'm a regular editor on the English Wikipedia. I've noticed huge lag within the edit box yesterday and today. I use the wikicode editor, not the visual editor. The lag affects insertion-point movement and typing within the edit box but nowhere else (e.g. the edit-summary box is unaffected) and is most pronounced on lengthy articles. I don't remember ever having this issue before. It's occurring on Chromium (basically Chrome) on Linux, Chromium on Windows, and Microsoft Edge (now based on Chromium) on Windows. Conversely, Mozilla Firefox on Linux is unaffected, leaving me to believe that Chromium-based browsers are getting struck in a loop (faulty JavaScript?) when editing. Chromium's task manager reveals 100% processor usage in the parent browser process, but not any Wikipedia tabs (which run in separate processes). Any ideas? — voidxor 19:46, 6 January 2022 (UTC)

Update: I get significantly better when Chromium's built-in spell checker is disabled. That's a bit of a sacrafice sacrifice for me though, because it helps me spot mispellings misspellings within wiki pages. I'm still not sure why it suddenly gives a huge performance hit; something in Chromium or MediaWiki must have changed. — voidxor 00:21, 8 January 2022 (UTC)

Same with me. I also use Chromium and can't edit articles no more with the wikicode editor. TheGlobetrotter (talk) 13:19, 27 January 2022 (UTC)

November 8, 2017

Wikipedia has been slow to load for the past few days. Nothing wrong with my computer, browser or the Internet.

September 2, 2017

Wikipedia has been really slow for me in the last couple of days. Pages take over 10-20 seconds to load (depending on their size). My edits now take over 30 seconds to show up after I click 'publish changes'. I doubt it's my internet because every other website runs (normally) fast. Is it Wikipedia's fault? Btw, I'm in Sydney Australia. ~ Meganesia (talk) 03:14, 2 September 2017 (UTC)

Even slower for me here in Perth. Taking 30 seconds for edits to show up would be great. More like 5 minutes for me today! Ishel99 (talk) 09:56, 4 September 2017 (UTC)

September 15, 2014

Some delays seem to depend on your IP address (or your router?). There is an add-on called "Wikipedia Speedup" for Google Chrome: https://chrome.google.com/webstore/detail/wikipedia-speedup/ppmagkdpdaaabpmdppckemgkngkpchdl?hl=en . Send the developer your network performance log as displayed by chrome if you can see something there (look at the screenshots). Currently it just disables the loading of a single javascript file hanging for 10 seconds and then failing depending on where you connect from.

November 07, 2013

Crawling for me here in L.A. today. Pages load in dial-up text, although the pictures are still there. I'm on a cable broadband modem and the DL speed test I just ran clocked in at 13Mbps.Pithecanthropus4152 (talk) 01:17, 7 November 2013 (UTC)

July 15, 2009

• Its slow for me in Texas. IE loads up the page but it locks up for about 50-65 seconds then loads the entire page up. Is this an issue that is going to fix any time soon.

July 12 2009

• Slow for me in Missouri. Taking several minutes to load Wikipedia pages when I do a search from the search menu in Firefox; clicking from page to page while already on Wikipedia is normal speed. When loading it seems to linger on upload.wikimedia.org.

• From chicago - a portion of the page loads, then it locks up IE for a while. Almost seems like some sort of a script is running which slows it down...

• Very slow here in Ohio. It was yesterday too.

• I'm in New York and page loads have been slow today. I've noticed it get worse over the past month or so.

• London, ON - intermittently slow here as well. Seems to work at normal speed about 20% of the time. Some pages do not completely load. Stall point seems to be at upload.wikimedia.org.--74.14.67.197 00:56, 13 July 2009 (UTC)

July 11 2009

Same problem in Greece for 2 days now... At first thought it was a local server issue but it seems to be global.

Now the pages won't even load. If I go onto iTunes, which as we all know takes forever, the page loads in the snap of a finger. Whats wrong? 11:07 AM-July 11 09'-Saturday

I'm having the same problem. Some pages are taking over five minutes to load.I've noticed a few other sites with the same problem. Is something going on? --24.208.157.184 16:17, 11 July 2009 (UTC)

Presumably nobody looks at this page on a good day. The failure notice has a broken link to IRC. Is there a non Wikimedia site where we can see the latest whining and possibly information about current delays? Jim.henderson 16:27, 11 July 2009 (UTC)

Looks to me like upload.wikimedia.org is delayed. The pages load after a bit for me, but sure could use some laxative. Loading various pages of varying lengths resulted in a similar delay. Encountered the same painful delay when loading the "File:image.jpg" links. Also the page hangs when completely loaded, polling the same DNS. Perhaps this is a particular server? Thanks all for your time and attention in this matter. --Zach

Thought it was Firefox 3.5 playing up, upload seems to be causing it.

It's indeed slow today... Although a quick refresh seems to be helping sometimes.

I'm glad I'm not the only one who noticed it was slow. Have they said whether or not they were/are the target of any of the recent network attacks?

Perhaps related to the North Korean cyber attacks?

Yep slow from Ireland too and a refresh does not help. Slow (im in the UK btw) but it only seems to be certain pages.

The site is running a bit slow. The page would load up but the Wikipedia symbol will not show so maybe it's recovering, who knows?

I find that stopping a page that is taking a long time to load, then manually refreshing it makes it load quicker -Technic

Also pretty slow from Spain. At the moment I am unable to load several pages. 212.22.56.27 18:55, 11 July 2009 (UTC)

Uh...It's slow in Middle Earth en' all.

Slow here too, in Massachusetts, US. Found this page via google search, wondering why everything was slow... :-( -Agamemnus

Slow in Australia. Some pages don't load at all.

It's alright here on Tatooine, Maybe it's a server problem.

it is slower than normal in scotland but not majourly slow..

been incredibly slow all day in UK

Yep, I agree with everyone. Very slow in Michigan too.

4chan is loading faster than Wikipedia. Something is absolutely wrong.

It's FABULOUS In Gotham City!

Read somewhere on an ANI page that there were problems with an Image server....

Appears to be fine now. Yay.

What is going with wikipedia. I bet 500,000 bucks that it could be some cyberpunks from North Korea or some former KGB spies.

It's being slow as hell for me and it's really pissing me off. ARGHHH! (UK) Same here , UK , what's wrong with iy

July 2 2009

This is the worst I've ever seen Wikipedia. Both English Wikipedia and Meta have been terrible all afternoon. --Bobak 21:39, 2 July 2009 (UTC)

April 03 2009

Wikipedia is very slow right now. I am on corporate LAN connection. Still taking a whole lot of time for the page to load. And most of the time, the images fail to load Completely. Currently the logo for this page is missing

March 12 2009

The loading times are dreadfully slow right now. On many Broadband Connections, although loading most pages takes about 4 seconds, and possibly a further 4 seconds to load the pictures. Right now, Wikipedia is taking about 18 seconds to load, although once it loads, all pictures are already loaded. The servers are getting slower as time moves on.

October 8 2008

Took me an hour to put this update in, took me two hours to get to the Wikipedia index page. 82.45.8.15 21:34, 08 October 2008 (UTC)

2007: PNG files 20x slower than JPEG?

In 2006 & 2007, the English Wikipedia has been displaying PNG-format files as many times more kilobytes than JPEG-format images, using 10x-15x times longer to display. Over the past 3 months, I reloaded about 50 JPEG versions of PNG files to Wikipedia and Wikimedia Commons resulting in JPEG display times often 10x times faster than PNG, sometimes saving 30-40 seconds (dial-up) in display time, for each image.

PNG files do show slightly better precision (in a magnifying-glass), but JPEGs are so fast, they can be displayed larger in articles even faster than small PNGs: JPEG images linked as 15% larger ("|thumb|210px") still load 7x faster than smaller PNG images. Automatic resizing of PNGs (& some GIFs) still leaves 50-kb-size thumbnails, where the JPEG thumbnail would be below 7 kb (with ~1 second display even on dial-up).

JPEGs can distort, so PNGs have a purpose. Distortion in some JPEG files can be seen viewed full-size, but usually speed is more important, and PNG files can be directly linked "click-to-enlarge" when fine precision is needed for full-size viewing. I also leave PNG image versions stored as "Image:xxx.png" when changing articles to use new rapid JPEG-versions of those images, just in case someone needs to access the massive PNG versions. Also, I try to prioritize which articles to improve, since there are a zillion large PNG images in use. Tiny PNG images/drawings (less than 15 kb) are not a problem.

Overall, large PNG usage is probably 20x times slower than JPEG files, for 2 other reasons: (1.) There is a bizarre phenomenon in English Wikipedia where some auto-sized thumbnails of PNG files display, perhaps, 33% larger than full-size [yes, a 90kb PNG can "thumbnail" as 121kb!]; (2.) upon re-displaying an article, any unstable PNG images, that did not cache fully, will start transfering again and again. Hence, those complicating factors make the true impact of PNG files, perhaps, 20x times slower than JPEGs, due to the negative synergy between the massive size of PNGs and their actual thumbnailing and re-loading. Overhead of PNG files is a major performance issue in 2007. -209.214.45.22 18:01, 21 January 2007 (UTC)

But, what does any of this have to do with Wiki running so slow? Who knows! -[206.82.83.109 12:53, 25 April 2007]

• The widespread use of PNG images has made displaying articles 5x times slower. Formerly, using JPEG thumbnails, articles were about 70% text versus 30% image data. However, PNG-format images are thumbnailed by wiki software as high-resolution format (even though PNG could support a compact form): due to the hi-res PNG overhead, articles are often 80% PNG data versus 20% text. In terms of response time, the usage of PNG images has made a typical article 5x times slower to display. The article text portion might display quickly at first, but then the processing to download images would typically run another 4x times slower than before. If a wikiserver formerly displayed typical pages with JPEG images within 15 seconds, now the equivalent PNG-image version might delay 75 seconds to show a page (which could seem like an eternity). If a wikiserver was formerly 100% busy displaying the quick JPEG pages within 15 seconds each, then now each person has to wait, in multiple delays, to get their total of 75 seconds per page: the accumulated delays could extend the 75 seconds into several minutes for each user. The delays might be compounded, even more, if the load-balancing formerly assigned 50 users to a wikiserver that now can only adequately handle 10 users with PNG images during the same time period. The problem is amplified because PNG wiki-thumbnails are hi-res PNG not compact PNG format. I cannot emphasize enough about the impact of transmitting 5 times more data, per article, to display PNG images. It's like saying 3 people could be comfortable in a car, with the 3rd person resting in the back seat, but now 5 times that number must be handled, 5*3=15 people in the same car: not so comfortable. Another analogy would be traffic handled by a 10-lane highway, facing a 5-fold impact, by reducing the highway as 10/5=2: just 2 lanes to handle the former 10-lane traffic. Articles becoming 5x times larger to display PNG images could have a massive impact on slowing response times, especially when considering the additional factor of redisplaying PNG images that did not cache properly (as noted in the original comment above) with the compound impact of 20x more data transmitted per image, on average. Think of the 15-people car analogy, with the car stopping periodically because people keep sliding out windows due to a lack of space inside: a trip takes even longer than the delay to put 15 people in a car; that's the compounding effect of slow PNG images having to be retransmitted because they failed to cache on the first page download. -209.214.44.83 18:49, 28 March 2008 (UTC)

June 26 07

Very slow this morning...pages taking 5 minutes to load. 24.111.45.250 15:20, 26 June 2007 (UTC)

January 2007

Extemely Slow. Lots of Errors are being Caused. --68.149.29.87 17:06, 9 January 2007 (UTC)

July 2006

It's going so slow right now. 68.37.44.253 19:28, 21 June 2006 (UTC)

March 2006

USE ADVERTISING TO MAKE SOME CASH TO BUY NEW SERVERS!!! U.K. user here. Wikipedia incredibly slow at the moment; some articles taking up to 10 minutes on a broadband connection (1Mbps) to load. About 40% of all page requests are failing; no images in any articles being downloaded.

Australian user (User:Beneaththelandslide ) attempting to edit several articles. Wikipedia is timing out and not responding. Image uploads have over the past few days taken hours to upload, timing out countless times. I understand the pressure wikipedia is under, but would you be able to at least tell users if there are problems, how you are countering them and such? It's times like this I wish the wiki heads accepted Google's offer of free hosting. It's annoying beyond belief.

Too frequently, pages just don't load at all for me. --129.234.4.10 13:30, 23 May 2006 (UTC)

November 2005

Wikipedia remains incredibly slow especially the image servers (upload.wikimedia.org).

December 2004, January 2005

Possibly due to a deliberate DoS attack, or a poorly-coded search engine spider, Wikipedia is running highly unreliably, occasionally speeding up, but generally ususably slow, and very few edits are successful. There seems to be a lot of variation in availability and editability between languages at any given time, but this could just be due to the general variable performance. As of January 12th, 2005, there is no official word on Wikipedia about the outages, just theories and discussion on the IRC channel and the OpenFacts Wikipedia Status page]. Interestingly, this edit has been without difficulty, and meta-wiki does not seem to be affected. Boffy b 12:32, 12 Jan 2005 (UTC)

UPDATE: According to this entry on Wikimedia's LiveJournal, the problems are simply due to configuration issues and poor load-balancing, which is being worked on, although there does not appear to be a time scale for the completion of this yet. Boffy b 10:05, 13 Jan 2005 (UTC)

April, May, June 2004

I hate to disagree but WikiPedia does currently run very slow (meaning a minute to load a page) and often gives the error "unable to access the database server". Presumably this page dates from last time it got bottle-necked and now it is bottle-necked again? At some times of day (3pm ish UK time) it is so bad I end up using the April copy saved at [1] and noting down things to fix later. But I was told that this current problem is being worked on so perhaps it is only this page which is out of date --AndrewCates 13:47, 20 May 2004 (UTC)(talk)

After the speedup from the January order the site was fast until mid April. Increased load again resulted in slowness. To avoid cascade effects at the database server when there were many waiting operations, the Apache web servers were set not to make more than a set number of database connections. At that point, they would return an "unable to access the database server" error. Retrying in 30 seconds would generally result in a successful operation. This prevented a very large buildup of slow queries on the server and maintained better overall performance. Net result was these errors instead of a steady fall to the performance level of late 2003.

The upgrade discussion April 2004 resulted in a hardware order May 2004. That added three more web servers on 27 May, shortly after delivery, a new Squid cache server on 12 June (one of the web servers was switched) and acquired a new database server, Ariel. After extensive testing, Ariel started serving some slow read requests on 21 June. The amount of reads it handles will be increased prior to the expected switch to using it as the master database, instead of Suda. As the reads switch, the frequency with which the "unable to access the database server" error happens should fall, if it's not eliminated completely.

In late April one of two Squid cache servers failed, resulting in significant performance degradation until it was replaced. There are now three and a greater total number of hits may result in adding a fourth so that loss of one doesn't cause slow performance.

On Sunday 6 June at 16:00 UTC the site went down due to database trouble, at a time when the replicated child database was not in synch, causing an outage which lasted until 02:48 UTC on 8 June. At present Ariel is serving reads as a replicated child and Zwinger is hosting a backup-only replicated child. It's likely that at least one more backup replicating child will be used to further decrease the chance of an extended unplanned outage.

The hardware provisional budget and Wikimedia servers network proposal are currently planning some future developments to handle the expected increase in traffic. In general, it's likely that at least one new web server is going to be purchased every month, on average, and it seems quite likely that there will be three database servers in use by the end of 2004. The software work to spread the load across multiple database servers is currently in a fairly early stage of rollout and future development is expected. Given the very large file transfers sometimes involved it is likely that there will be some use of gigabit ethernet on the network by the end of the year, since the current 80GB combined database size takes about two and a half hours to transfer on 100 megabit ethernet and has been a factor in some downtime for maintenance being longer than desired.

Ongoing in all planning are efforts to eliminate single points of failure which can take the whole site down or dramatically impact performance. The seven web servers in use now means we've had several of them down at times for software reasons or operating system upgrades without people noticing much. The image server is currently a single machine (though with backups) and the DNS server which does round robin DNS load balancing among the three Squid cache machines is a single point of failure for the whole site. One of the new machines from the May order is going to be used as an image server with RAID 1 to preserve the images and another machine as it's backup. At some point there may also be load balancing between two image servers, with the Apaches switching based on performance or availability.

Jamesday 06:36, 23 Jun 2004 (UTC)

Late 2003, January 2004

See also: Why Wikipedia ran slow in late 2003 and the hardware order January 2004 which ended that situation for a couple of months.