¿Hay alguna razón por la que esto no sea una política o una directriz? — Omegatron 15:54, 14 de julio de 2006 (UTC)
No se habla mucho aquí, y el "mandato del desarrollador" de la historia no se sostiene: Desarrollador != superusuario. Voy a "degradar" esto a ensayo. ¿No debería contar también la directriz contra la extensión de instrucciones cuando se trata de la extensión de directrices?
152.91.9.144 05:36, 12 de diciembre de 2006 (UTC)
Lo siento, pero una pequeña minoría dedicada (usted) no impide que algo se convierta en política.
Y sí, los desarrolladores pueden establecer políticas, por ejemplo, sobre la carga del servidor, y ni siquiera una mayoría puede anular su decisión. Nuestras políticas sobre el tema son, en realidad, autorreferenciales en este sentido:
¿Cómo se inician las políticas?
El cambio de políticas proviene ahora de tres fuentes:
- La codificación de las convenciones actuales y las prácticas comunes. Se trata de propuestas que documentan el modo en que funciona Wikipedia. Por supuesto, un único usuario no puede dictar cuál es la práctica común, pero poner por escrito los resultados comunes de un proceso bien utilizado es una buena manera de elaborar políticas.
- Una política propuesta que se adopta por consenso (véase Wikipedia:Cómo crear una política ). Suelen ser propuestas para cambiar el modo en que funciona Wikipedia.
- Declaraciones de Jimmy Wales , la Junta o los desarrolladores , particularmente sobre derechos de autor, cuestiones legales o carga del servidor.
—¿Cómo se inician las políticas?
Ahora no lo sé. Quizás tengas razón. Quizás eso no se aplique aquí. Después de todo, esto es sólo una página con declaraciones textuales de los desarrolladores sobre la carga del servidor... — Omegatron 00:14, 13 de diciembre de 2006 (UTC)
Compárese, por cierto, con WP:AUM , que fue declarada política por razones del tipo "por mandato del desarrollador", y que Brion rechazó explícitamente en la misma diferencia citada en esta página de ensayo. — Simetrical ( discusión • contribuciones ) 01:46, 13 de diciembre de 2006 (UTC)
He dicho dos veces (una vez arriba y otra en un resumen de edición) que los desarrolladores no hacen políticas. No era esa mi intención, y sólo cuando leí la respuesta de S arriba vi mi error. A lo que me oponía era a la implicación de que los rumores de los desarrolladores eran políticas, en una especie de apelación de segunda mano a la autoridad. Mi respuesta también fue exagerada en general. Así que... No hay nada que ver aquí, sigamos adelante.
152.91.9.144 03:24, 13 de diciembre de 2006 (UTC)
Basándonos en la reciente entrada de Brion en wikitech-l, tal vez esta página debería ser redirigida a Wikipedia:Use el sentido común . Angela . 20:44, 16 de enero de 2007 (UTC)
Para ser de alguna utilidad, esta página debería dar ejemplos de lo que podría constituir problemas reales y lo que no. // habj 22:33, 23 de enero de 2007 (UTC)
Odio decirlo, pero leer esta página me hizo sentir menos cómodo que nunca con el desempeño de Wikipedia, porque todas las citas parecen consistir en ataques falaces y cosas raras que suenan a conspiración del tipo "no hay problemas porque decimos que no los hay". No, no creo que ninguno de los oradores tenga intenciones negativas reales, pero seguro que podrían estar expresando mejor sus intenciones positivas. Imagino que las citas se derivaron de su cansancio de escuchar a la gente expresar constantemente estos temores, pero eso no es una excusa para la ausencia de fuentes en esta página . Cuando la gente afirma que el contacto con sapos produce verrugas, no se dice simplemente: "¡Eso es una tontería! Te equivocas, y también dices 'teh' mucho". Se presentan pruebas de lo contrario, sin importar lo aburrido que parezca hacerlo.
Lo único que me pregunto es un dato (espero) simple: ¿cuál es, aproximadamente, la capacidad del servidor? ¿Cuánto de esto se ha "llenado"? ¿Cuál podría ser una buena analogía para lo increíblemente grande que es el espacio disponible? (Una respuesta para esta última pregunta, por forzada que sea, podría ser particularmente útil para que personas como yo se hagan una idea). ¿Estoy simplificando demasiado cómo funciona la capacidad del servidor (es muy probable, lo sé)? ¿O se trata de información confidencial para los hackers que no debería publicarse (aunque un viaje rápido a Tampa podría darnos la misma información...)?
En cualquier caso, "este es nuestro trabajo" no es suficiente para satisfacer a los más paranoicos (posiblemente me incluyo); es como si un policía les asegurara a los ciudadanos que no tienen que preocuparse por los delitos en su comunidad, no por la baja tasa de criminalidad documentada, sino porque son policías y es "su trabajo". Nadie cuestiona que los desarrolladores desarrollen, o que lo hagan extremadamente bien. Solo necesitamos una garantía de que (a) Wikipedia no se parece en nada a nuestros discos duros de escritorio, o (b) lo es, pero en un grado que está más allá de nuestra comprensión. (O (c) cualquier cosa que no se me haya ocurrido).
Además, no estaría mal encontrar una forma de conciliar esta directriz con la respuesta que tanto se pide: "¿Para qué necesitan donaciones , entonces?". Y estoy seguro de que se puede lograr esa conciliación, pero sólo si se acompaña de una disminución de esa actitud de "no se preocupen, lindas cabecitas de novatos". Lenoxus " * " 19:35, 26 de marzo de 2007 (UTC)
Si tienes experiencia técnica en administración de servidores y/o desarrollo de software, probablemente comprenderás de inmediato por qué la mayoría de las cosas prohibidas por lentitud son lentas, dada una síntesis de dos oraciones, y lo mismo ocurre con las cosas permitidas por no ser lentas. Si estuvieras interesado y supieras de lo que estás hablando (no digo que tú en particular no lo sepas, pero la gran mayoría de los no desarrolladores no lo saben), la mayoría de los desarrolladores probablemente no tendrían problema en hablar sobre otras implementaciones o cosas por el estilo. Si no tienes la experiencia para apreciar completamente las implicaciones de cualquier cambio en particular, simplemente no vas a entender correctamente nada de lo que estamos hablando y tendrás que conformarte con un "confía en nosotros" o algún galimatías técnico que equivale a lo mismo. Este es un hecho básico de la especialización tan intensa que tenemos hoy.
Para responder a tu pregunta, no es tan simple como "capacidad del servidor". Los servidores tienen muchos, muchos, muchos cuellos de botella que pueden ralentizarlos. No son dispositivos sencillos. Para resumir el estado aproximado del juego hasta donde yo sé (que no es extenso, porque aunque soy desarrollador no soy administrador de sistemas): tenemos espacio en disco efectivamente ilimitado, lo cual menciono porque es lo único que se puede decir que "se llena" en un sentido real. En muchos otros aspectos (CPU, memoria, número de servidores en general) tenemos carencias. El sitio es a menudo lento, y esto se podría solucionar en gran parte añadiendo más servidores. Actualmente no tenemos tantos servidores como podríamos utilizar, porque la Fundación Wikimedia funciona con un presupuesto que otros diez sitios web importantes gastarían en papel higiénico. Google es más rápido y más confiable porque posee aproximadamente 450.000 servidores y sigue creciendo; la Fundación Wikimedia posee alrededor de 300.
Nada de esto es confidencial. Más allá de las contraseñas y las claves criptográficas, solo unos pocos detalles son estrictamente confidenciales. Somos transparentes tanto en lo que respecta al aspecto técnico como al contenido.
Los agentes de policía son, sin ofenderlos, en el mejor de los casos semicalificados, casi inexpertos. Un profano no puede esperar entender los detalles del trabajo de un programador más que el de un físico teórico o un diseñador de propulsión de cohetes. Sólo se pueden entender los efectos, no los medios ni la lógica. Si esto no te gusta, puedes intentar aprender sobre este tipo de cosas y adquirir experiencia de primera mano con ellas, pero hasta entonces tendrás que confiar en nuestra palabra, partiendo de la base de que parecemos tener una idea mucho mejor de lo que estamos hablando que tú. Y, sin ofender, es así, como lo demuestra el hecho de que los servidores funcionan y el software hace en gran medida lo que se supone que debe hacer, algo que personas sin experiencia en los campos apropiados no podrían hacer que hicieran. No somos perfectos, pero sí sabemos algo; los que saben tanto o más pueden criticarnos, pero los que saben mucho menos no tienen forma de formular críticas.
Nada de lo que se dice en esta página pretende dar a entender que el rendimiento no es un problema. Es absolutamente necesario contar con más servidores, pero es un problema para los desarrolladores y otras personas con conocimientos técnicos. Decir que tal o cual cosa pondrá demasiada presión sobre los servidores implica que sabes de lo que estás hablando; si no lo sabes, no lo digas. En general, intentaremos impedir que los usuarios hagan algo demasiado perjudicial, pero en algunos casos no lo hemos hecho o no podemos hacerlo, y entonces tendrás que aceptar nuestras instrucciones (en particular, las de los administradores del servidor principal, como Brion, Tim, Domas y Mark) de no hacer cosas. El objetivo de esta página es decir que no debes inventar tus propias instrucciones de no hacer cosas, y no debes intentar generalizar o ampliar las instrucciones de personas que sí saben de lo que están hablando. Y vale la pena mencionar que incluso aquellos con una amplia experiencia en servidores no deberían dar sus propias opiniones a menos que tengan un amplio conocimiento de la configuración de nuestros servidores y del software que utilizamos.
En cualquier caso, creo que sería mejor reescribir esta página como un ensayo real, no como una colección de citas fuera de contexto dirigidas a otra cosa. Creo que lo haré ahora. — Simetrical ( discusión • contribuciones ) 04:21, 27 de marzo de 2007 (UTC)
He descartado las citas; estaban parcialmente fuera de contexto y no eran especialmente centradas ni esclarecedoras. En su lugar, he escrito un resumen personal de las ideas que hay detrás. Creo que es mejor dejar que esto esté escrito por desarrolladores por ahora, como era esencialmente en el pasado, así que estaré monitoreando la página y revisando los cambios. Si en algún momento alguien quiere tener grandes discusiones públicas y conseguir que esto se apruebe como una guía, la autoridad de un autor desarrollador podría no ser necesaria. De todos modos, creo que la versión actual enfatiza los puntos apropiados y es más refinada en comparación con algunas confusiones que hemos tenido sobre esto, a diferencia de las versiones anteriores. — Simetrical ( discusión • contribuciones ) 04:49, 27 de marzo de 2007 (UTC)
Además, estoy volviendo a agregar las comillas en la parte inferior, para que quede claro para los transeúntes que esta no es sólo mi opinión... ¿se ve mejor así? — Simetrical ( discusión • contribuciones ) 23:44 27 mar 2007 (UTC)
O, para usar un ejemplo más plausible, un novato podría tener alguna buena razón para hacer una serie de ediciones, digamos 30, al mismo artículo, en lugar de un gran cambio, y se preocupará de que si muchos otros siguen el ejemplo, esto impondrá una carga indebida a los servidores. (¿O es esto último realmente posible, según tu argumento de que "millones de personas ralentizan el sitio"?) De eso estoy hablando. ¿Son esas objeciones simplemente demasiado "extrañas" (lo cual yo entendería, supongo) para tener lugar en el ensayo? Ah, y por favor no te molestes en responder hasta que te sientas más elocuente; esto puede esperar mucho tiempo. Lenoxus " * " 02:44, 28 de marzo de 2007 (UTC)
De WP:POL , "El cambio de política ahora proviene de tres fuentes... Declaraciones de Jimmy Wales, la Junta Directiva o los Desarrolladores, particularmente sobre derechos de autor, cuestiones legales o carga del servidor" . > R a d i a n t < 08:42, 10 de abril de 2007 (UTC)
Por supuesto, cualquier persona a la que la Fundación le haya otorgado un puesto de autoridad (como administrador de sistemas) puede ejercer esa autoridad cuando sea necesario, lo que, dependiendo de su función, puede extenderse a declarar un comportamiento como oficialmente requerido o inaceptable, es decir, a establecer políticas. Eso no es exclusivo de los administradores de sistemas; recuerdo que cuando Essjay era funcionario electoral, amenazó con quitarle a Geni los privilegios de administrador de sistemas cuando Geni eliminó un anuncio del período de nominación del aviso del sitio. No tengo dudas de que habría tenido éxito si Geni hubiera insistido imprudentemente. Por eso, su cita me parece mal concebida.
Ah, y en caso de que quieras volver a añadirlo, soy un desarrollador, así que según tú tengo derecho a decirte qué hacer. Por lo tanto, si estás equivocado, no deberías volver a añadirlo porque está mal, y si tienes razón, no deberías volver a añadirlo porque yo, un sagrado desarrollador, dije que no lo hicieras. :P — Simetrical ( discusión • contribuciones ) 02:41, 12 de abril de 2007 (UTC)
Sin embargo, no me interesa entrar en una guerra de reversión. Si quieres dejarlo {{ guideline }} , no voy a intentar impedírtelo. — Simetrical ( discusión • contribuciones ) 17:32, 12 de abril de 2007 (UTC)
10 de julio de 2007: ¡Vaya! ¿Por dónde empiezo? La advertencia más apropiada es la siguiente: cuidado con " tentar al destino " (alardear de que algo no importa). Dicho esto, recibí el mensaje: "El barco de la wiki es insumergible" (refiriéndose al Titanic ), así que no te preocupes, sé feliz .
Ahora, volvamos a la realidad. Los cuellos de botella en el rendimiento se dan en casi cualquier entorno a largo plazo y en cualquier generación. Hay algunos problemas importantes que se observan en WP/Wikimedia:
Me detendré aquí. La tendencia general es (¿puede adivinar?): los datos de los vagabundos ahora están apareciendo en muchos artículos, haciendo que las velocidades de banda ancha sean casi tan lentas como lo eran las conexiones telefónicas hace años. La revolución del rendimiento de la banda ancha pronto será derrotada porque "no se preocupan por el rendimiento" y eso fue antes de que usted los alentara. "Señora, Dios mismo no podría hundir este barco". - Wikid77 08:50, 10 de julio de 2007 (UTC)
Nota para los lectores interesados: la discusión está en curso en Talk:Windows Vista#Windows Vista Snapshot changed to JPG y #All PNGs with JPEG . Powers T 19:30, 10 de julio de 2007 (UTC)
Y ese tipo de cosas es exactamente lo que quiero decir. No estás calificado para decir qué dañará o no el rendimiento del sitio, y por lo tanto no deberías tratar de abordar eso a nivel de políticas. En cambio, deberías dejar eso en manos de quienes pasan todo el día manteniendo el sitio en funcionamiento y saben exactamente qué puede causar problemas de rendimiento. Los problemas de los que te quejas no están siendo "eliminados por definición", nunca existieron en primer lugar. Lo que este ensayo/guía pide es que dejes de inventar problemas que no existen.
Si desea involucrarse seriamente en ayudar al rendimiento del sitio, necesita leer el código y los datos de creación de perfiles, ejecutar pruebas comparativas y obtener información de otro tipo. Si no lo hace, lo único que estará haciendo es hacer que los usos legítimos, útiles y no perjudiciales del sitio resulten inconvenientes o prohibidos. Matar tigres de papel no ayuda a nadie. — Simetrical ( discusión • contribuciones ) 17:19, 13 de agosto de 2007 (UTC)
Sí y sí. — Simetrical ( discusión • contribs ) 07:12 5 ago 2007 (UTC)
En la Wikipedia en holandés, la gente se preocupa por los usuarios que realizan demasiadas ediciones. Se advierte a los nuevos usuarios que no realicen demasiadas ediciones en una página, sino que utilicen siempre "mostrar vista previa" antes de guardar. A la gente le preocupa que los servidores se queden sin espacio libre debido a las demasiadas ediciones. Incluso tenemos una plantilla de advertencia especial para esto. Me parece que el espacio del servidor no debería ser algo de lo que preocuparse siempre que se trate solo de texto. ¿Puede algún administrador del sistema confirmar mi opinión o decirme que estoy equivocado?
JacobH 10:11 4 septiembre 2007 (UTC)
Sin embargo, editar en lugar de previsualizar puede resultar molesto en términos de saturar los historiales con ediciones repetidas cuando sólo una bastaría. Tal vez quieras desalentar las ediciones repetidas sobre esa base. Pero no te preocupes por los servidores. — Simetrical ( discusión • contribuciones ) 16:38, 4 de septiembre de 2007 (UTC)
He notado que esto se ha mencionado como una razón para usar imágenes de alta calidad en lugar de imágenes de baja calidad. Debo señalar, por lo tanto, que este ensayo se aplica únicamente a problemas de rendimiento del lado del servidor y, de hecho, definitivamente se puede ralentizar la carga de páginas si se las atiborra con imágenes de 100 KB. Si esto es aceptable para usted es una decisión editorial y no hay mucho que los desarrolladores o administradores de sistemas puedan o quieran hacer para prevenirlo o alentarlo. —Simetrical (discusión • contribuciones) 05:21, 11 de julio de 2007 (UTC)
¿Alguien ha visto ya la página de Wikipedia:Crisis de enlaces excesivos ? Wikid77 tiene una gran preocupación por el rendimiento y ha comenzado a cambiar cosas para solucionarlo. --Explodicle ( discusión ) 16:41 13 feb 2008 (UTC)
¿Por qué mencionarlo aquí? ¿Por qué no bloquear su eliminación y solucionar el problema? -- Emesee ( discusión ) 04:50 15 jun 2008 (UTC)
Tal vez esta página podría tener un recuadro que diga "esta página en pocas palabras", como muchas otras políticas de Wikipedia (por ejemplo, WP:NPOV ). -- OscarBor ( discusión ) 11:23 30 jul 2008 (UTC)
Se agregó uno. — Simetrical ( discusión • contribuciones ) 16:37 30 jul 2008 (UTC)
Gracias, se ve bien. -- OscarBor ( discusión ) 12:16 3 ago 2008 (UTC)
23 de junio de 2009: En 2007, escribí el ensayo " WP:Overlink crisis ", basado en las implicaciones matemáticas del creciente problema. No sólo "quería tener razón", pero, por supuesto, en diciembre de 2008, los servidores de Wikipedia ya no podían volver a formatear páginas, en el plazo de una hora, en las que se habían modificado los cuadros de navegación. ¿Qué tan mal se puso la cosa? (Si no estuvieras aquí, no lo creerías) a principios de 2008, los servidores reformateaban un conjunto de 400 artículos, que compartían un cuadro de navegación modificado, en 4 minutos (esa velocidad era la misma en muchos días diferentes); sin embargo, en diciembre de 2008, los servidores tardaron días en reformatear sólo 20 artículos que compartían un cuadro de navegación modificado. Al día siguiente, al revisar algunos de esos artículos, se reveló que el cuadro de navegación antiguo todavía se mostraba, más de 24 horas después. Simplificando el tiempo de demora a exactamente 2 días, o 48 horas, para reformatear los 20 artículos, cuando antes se habían hecho 400 en 4 minutos (en cualquier día a principios de 2008), la diferencia de velocidad es gigantesca.
La comparación de velocidad en cuanto a rendimiento es: antes 400 en 4 minutos, o 100 por minuto (1 cada 0,01 min), frente a 20 en 48*60 (o 2.880) minutos, o 1 en 144 minutos. El tiempo requerido en diciembre de 2008 era más lento en un factor de 144/0,01 = 14.400 veces más lento que a principios de 2008. Eso es lo que pasa cuando "no te preocupas por el rendimiento": no sólo empeora el doble, o es 10 veces peor, o 100 veces peor, o 1000 veces peor. Lo siento, pero el rendimiento empeora 14.400 veces (y esa es una estimación baja). La diferencia de velocidad no sólo es gigantesca, sino también, digamos, "titánica".
En cuanto a la analogía entre el RMS Titanic y WP:PERF , bueno, "Ese barco también se hundirá".
¿Cómo pudieron los desarrolladores estar tan equivocados, de modo que lo que hicieron los usuarios, en cambio, afectaría drásticamente el rendimiento de todos, durante días? ...porque los problemas de rendimiento son muy complicados, y lo que los desarrolladores entendieron fue solo una pequeña parte del sistema total. En realidad, todos deben preocuparse por el rendimiento, y cuanto más estudien las personas los problemas, más podrán concentrarse en los factores importantes y aprender qué problemas son relativamente menores y se deben ignorar. Contrariamente a la noción de "No te preocupes por eso (porque nunca lo entenderás)" , cuando las personas trabajan juntas y discuten los diversos problemas, entonces realmente se produce una comprensión más amplia, y las personas aprenden qué ignorar, y luego todos pueden trabajar juntos para hacer que las cosas funcionen más rápido y sin problemas.
Por lo tanto, vuelva a leer el ensayo " WP:Overlink crisis " y otros ensayos, póngase en contacto con algunos desarrolladores útiles y comience a aprender sobre los problemas de rendimiento y cómo ayudar. La forma en que se escriben los artículos, hoy, puede afectar drásticamente el rendimiento dentro de unos años. - Wikid77 ( discusión ) 08:02, 23 de junio de 2009 (UTC)
¿Qué tan mal se puso la cosa? (Si no estuvieras aquí, no lo creerías) a principios de 2008, los servidores reformateaban un conjunto de 400 artículos que compartían un cuadro de navegación modificado en 4 minutos (esa velocidad era la misma en muchos días diferentes); sin embargo, en diciembre de 2008, los servidores tardaron días en reformatear sólo 20 artículos que compartían un cuadro de navegación modificado.
Este es un caso estándar de post hoc ergo propter hoc . El hecho de que los cuadros de navegación se hayan hecho más grandes y el tiempo de análisis haya aumentado no significa que uno haya causado el otro. De hecho, puedo garantizar casi con certeza que no fue así. El tiempo que lleva analizar páginas no tiene esencialmente nada que ver con la cantidad de enlaces que van de un lugar a otro y, si existe alguna dependencia, debería ser aproximadamente lineal. Depende principalmente del tiempo de CPU disponible, de la cantidad de texto que se debe analizar y de qué otras tareas están en la cola de trabajos por cualquier motivo (en el caso de la actualización de plantillas).
En resumen, su creencia de que entiende qué causa los problemas de rendimiento en Wikipedia y cuál es la mejor manera de resolverlos; más que las personas que han pasado años optimizando el rendimiento del sitio; a pesar del hecho de que usted nunca ha contribuido significativamente a las operaciones del sitio, no ha realizado pruebas controladas sobre sus hipótesis y ni siquiera se ha molestado en llevar sus preocupaciones a la atención de los administradores de sistemas, sino que ha intentado persuadir a los usuarios de enwiki que no están en posición de juzgar su legitimidad; es exactamente el tipo de actitud y patrón de comportamiento que este ensayo intenta desalentar.
Si desea que sus argumentos sean considerados seriamente, le sugiero que:
Hasta entonces, diría que sus argumentos son exactamente el tipo de cosas que este ensayo pretende abordar, y espero que su existencia haya contribuido a la recepción de sus argumentos de una manera que beneficie al sitio. — Simetrical ( discusión • contribuciones ) 18:03, 23 de junio de 2009 (UTC)
30 de junio de 2009: Las métricas involucran miles de navboxes, en miles de artículos. No es el impacto de un solo usuario, sino el impacto combinado de miles de usuarios que realizan actividades similares. Los problemas han ido creciendo durante años, por lo que los comentarios anteriores no enumeran los miles de ejemplos que, combinados, constituyen el problema de rendimiento. Tal vez pueda mencionar un artículo, " Marruecos ", como un ejemplo de sobreenlace: ese artículo tiene 11 (once) navboxes en la parte inferior, duplicando el tamaño del artículo al agregar otros 840 enlaces wiki (que también duplicaron el tamaño de los datos HTML en kb). Es posible que sepas que, también, psicológicamente, la gente se "adormecerá con los navboxes" cuando la cantidad de enlaces de navbox crezca a solo un océano de "cosas" en la parte inferior (pero eso es un problema de rendimiento humano, no de carga del servidor). Además, estos "1 individuos" han estado muy ocupados (usando bots o convenciendo a otros) para que coloquen cuadros de navegación en "900" artículos a la vez. El concepto antiguo en informática se denomina "datos vagabundos" como datos no relacionados que requieren actualizar los módulos afectados (páginas) simplemente porque alguien colocó un elemento de datos (cuadro de navegación) en la parte inferior de 10.000 artículos.
Mientras tanto, me gustan los cuadros de navegación pequeños o limitados: está bien colocar un cuadro de navegación que rara vez cambia en 50.000 artículos, o colocar un cuadro de navegación grande e inestable en 40 artículos. Sin embargo, numerosas personas han colocado cuadros de navegación inestables en "900" artículos a la vez. Por qué se convirtió en un problema: si 900 artículos enlazan a un artículo compartido, esos 900 no necesitan actualizarse cuando se cambia ese artículo, pero 900 artículos que utilizan un cuadro de navegación compartido sí necesitan actualizarse (para proporcionar una lista precisa de "Qué enlaza aquí"). El impacto es 900 veces mayor, y cuando algo es 900 veces mayor, entonces es muy probable que el rendimiento se vea afectado. Las conexiones a Internet de alta velocidad son típicamente solo 50-70 veces más rápidas que las velocidades de acceso telefónico: si los usuarios aumentaran a 10 megapíxeles las imágenes en los artículos, entonces esos 900 veces más datos de imagen abrumarían una línea de Internet 50-70 veces más rápida (por 12-18 veces más lenta). De manera similar, cuando los artículos anteriormente enlazados solo por wikilink (o por navboxes utilizados en 30 artículos), entonces había poco tiempo de demora. Sin embargo, los navboxes se utilizan en miles de artículos, y muchos están diseñados para cambiarse cada semana (como "Productos y gerentes de la gran empresa ZZZ"). Anteriormente, la tendencia era simplemente enlazar 900 veces al artículo "Gran empresa ZZZ", pero ahora, la tendencia es transcluir 900 veces con los contenidos enmarcados de esa empresa-artículo como navbox "Productos y gerentes de la gran empresa ZZZ". Por eso el problema se está multiplicando por 900. Espero que esta explicación aclare las cosas. - Wikid77 ( discusión ) 10:25 30 jun 2009 (UTC)
Me repito, pero sí, el uso de plantillas genera mucha carga en el sitio y algo que realmente ayudaría al rendimiento del sitio sería tener más cuidado con las plantillas que se usan mucho. (Domas ha sugerido que expongamos los datos de creación de perfiles de plantillas a los usuarios y los alentemos a optimizar las plantillas más costosas en general. Ese sería un caso específico en el que este ensayo no se aplicaría, ya que los esfuerzos de optimización se realizarían a pedido del desarrollador).
Pero esto no tiene nada que ver con la cantidad de enlaces . El único costo aquí es volver a analizar todas las páginas. No importa si la plantilla contiene cien enlaces o un solo carácter ASCII, si se modifica, las páginas en las que se encuentra deben eliminarse de la memoria caché y volver a analizarse. Eso es todo lo que importa. Si hay enlaces, WhatLinksHere (la tabla de enlaces de página) debe actualizarse, pero incluso si es solo texto de página, tenemos que actualizar el contenido real de la página. El costo de actualizar los enlaces de página es insignificante en comparación con la operación de análisis real (que se requiere para determinar cómo se deben actualizar los enlaces de página).
Y si no puedes ejecutar métricas tú mismo para medir directamente si hay un problema, aún puedes sugerir que se agregue un perfil al software y tal vez escribir el soporte tú mismo. La evidencia anecdótica no es útil en ningún caso. — Simetrical ( discusión • contribuciones ) 21:18, 1 julio 2009 (UTC)
A finales de 2009, muchas personas eran conscientes de que el ensayo WP:PERF no era una excusa para utilizar imágenes grandes o plantillas enormes en artículos de lectura frecuente. Desafortunadamente, el uso de cuadros de navegación ha seguido aumentando, como en los artículos médicos, donde muchos han añadido varios cuadros de navegación que suman más de 2.500 enlaces wiki adicionales en los cuadros de navegación inferiores. Como era de esperar, la gente ha dejado de poner todos los cuadros de navegación en "todos" los artículos posibles, como por ejemplo utilizar un cuadro de navegación en sólo 50 de los 700 artículos enlazados en el cuadro de navegación. Las plantillas lentas o engorrosas generaban misteriosos errores fatales, todavía durante mayo de 2010 (ver a continuación: "#Los límites de plantillas causan: ERROR DE LA FUNDACIÓN WIKIMEDIA" ). - Wikid77 08:57, 8 de mayo de 2010 (UTC)
08-May-2010: Durante 2009 y 2010, algunas plantillas enormes, al usarse muchas veces por página, causaban un largo retraso seguido del cuadro de error de la Fundación Wikimedia, como se muestra a continuación:
Dado que la pantalla del lector queda completamente sobrescrita por ese cuadro de mensaje, es necesario que los usuarios se den cuenta de qué página, que estaban intentando leer, les ha llevado a la pantalla de Error de Wikimedia. Si la página que provoca el error se modifica para utilizar una plantilla más rápida, esa página de mensaje de WIKIMEDIA ya no se vuelve a mostrar. - Wikid77 ( discusión ) 8 de mayo revisado a las 11:37, 13 de mayo de 2010 (UTC)
¿La simetría era incorrecta y Wikikid tenía razón? TCO ( discusión ) 06:51 12 jul 2013 (UTC)
Estas informaciones: "Esta plataforma forma un cluster de más de cuatrocientos servidores, con más de cinco terabytes de RAM y más de 2.400 núcleos de procesador [...]" y "[...] las limitaciones a la inclusión de plantillas, el bloqueo a la eliminación de páginas con más de 5.000 revisiones y el tamaño máximo de las páginas de 2 MB" tienen ya unos 10 años. ¿Qué hay de hoy? También me interesaría la información sobre el espacio total de memoria de Wikipedia en todo el mundo. -- Bestoernesto ( discusión ) 22:30 9 jun 2016 (UTC)
Ese mensaje da la impresión de que los servidores web están "demasiado ocupados" para responder, pero a menudo se debe a la complejidad de la página que necesita mostrar. Es bastante común ver esto después de editar un artículo complejo como Barack Obama. Su edición generalmente ha tenido éxito, pero no puede ver el resultado de inmediato. Puede resultar molesto para el editor. Este es un efecto secundario conocido de las páginas complicadas y aparece como problema 19262.
Me gustaría ver una actualización de este artículo, y que se actualizara de nuevo a una guía. Todavía hay editores que piensan que eliminar los espacios en blanco de un artículo es de alguna manera beneficioso, lo que me entristece porque Wiki comenzó como un marcado supuestamente más fácil de leer y más amigable para los humanos. En un nivel técnico, las páginas de datos se comprimen en varios puntos antes de que lleguen al usuario de todos modos. En un nivel estructural y de contenido, siempre he pensado que dividir listas o tablas en subpáginas era una forma más productiva de reducir el tamaño de la página y los tiempos de carga, y mantener el texto más relevante donde los lectores lo necesitan.
Creo que a los lectores les vendría bien contar con algunos principios generales sobre qué es lo que debe preocuparles y qué no, o ejemplos de cosas mejores de las que preocuparse . Si se me permite intentar resumir las discusiones anteriores, el exceso de plantillas parece ser un problema, aunque es mejor dejar que lo solucionen los desarrolladores. Se ha mencionado Overlink, por lo que los lectores pueden ser redirigidos a otras pautas como WP:OVERLINK que abordan esos problemas como una cuestión de estilo y contenido en lugar de como un problema de rendimiento.
En lugar de decirles a los lectores lo que no deben hacer, sería mejor ser positivos y recomendar cosas que los editores deberían hacer, poniendo la sección "Los editores tienen un papel que desempeñar" más arriba en el artículo y explicando más cosas. -- 109.79.73.193 ( discusión ) 12:41 21 dic 2018 (UTC)
