Entradas etiquetadas con cache

WordPress 3.x para desarrolladores: Temas y plantillas, widgets.php

hace 11 años

by Mikel en Programación y sistemas

administración cache PHP plantilla tema widget Wordpress

El siguiente archivo que vamos a crear es widgets.php que generará un widget para mostrar diferentes tipos de contenido, como citas estados, etc.

WIDGETS.PHP

Creamos el archivo inc/widgets.php y añadimos el siguiente código:

[codesyntax lang=»php»]

<?php

/**
 * Makes a custom Widget for displaying Aside, Link, Status, and Quote Posts available with New Theme
 *
 * Learn more: http://codex.wordpress.org/Widgets_API#Developing_Widgets
 *
 * @package WordPress
 * @subpackage Nwe_Theme
 */
class New_Theme_Ephemera_Widget extends WP_Widget {

}

[/codesyntax]

Creamos la clase New_Theme_Ephemera_Widget que nos permitirá crear el widget.

Dentro de la clase añadimos los siguientes métodos.

[codesyntax lang=»php»]

<?php

	/**
	 * Constructor
	 *
	 * @return void
	 **/
	function New_Theme_Ephemera_Widget() {
		$widget_ops = array( 'classname' => 'widget_newtheme_ephemera', 'description' => __( 'Use this widget to list your recent Aside, Status, Quote, and Link posts', 'newtheme' ) );
		$this->WP_Widget( 'widget_newtheme_ephemera', __( 'New Theme Ephemera', 'newtheme' ), $widget_ops );
		$this->alt_option_name = 'widget_newtheme_ephemera';

		add_action( 'save_post', array(&$this, 'flush_widget_cache' ) );
		add_action( 'deleted_post', array(&$this, 'flush_widget_cache' ) );
		add_action( 'switch_theme', array(&$this, 'flush_widget_cache' ) );
	}

[/codesyntax]

Este método es el constructor del widget, le indica a WordPress la clase que utilizará, la desripción y el nombre del widget. Además se añaden varias acciones para volver a generar la cache cuando se guarde o elimine un post o cuando se cambie de tema.

[codesyntax lang=»php»]

<?php

	/**
	 * Outputs the HTML for this widget.
	 *
	 * @param array An array of standard parameters for widgets in this theme
	 * @param array An array of settings for this widget instance
	 * @return void Echoes it's output
	 **/
	function widget( $args, $instance ) {
		$cache = wp_cache_get( 'widget_newtheme_ephemera', 'widget' );

		if ( !is_array( $cache ) )
			$cache = array();

		if ( ! isset( $args['widget_id'] ) )
			$args['widget_id'] = null;

		if ( isset( $cache[$args['widget_id']] ) ) {
			echo $cache[$args['widget_id']];
			return;
		}

		ob_start();
		extract( $args, EXTR_SKIP );

		$title = apply_filters( 'widget_title', empty( $instance['title'] ) ? __( 'Ephemera', 'newtheme' ) : $instance['title'], $instance, $this->id_base);

		if ( ! isset( $instance['number'] ) )
			$instance['number'] = '10';

		if ( ! $number = absint( $instance['number'] ) )
 			$number = 10;

		$ephemera_args = array(
			'order' => 'DESC',
			'posts_per_page' => $number,
			'no_found_rows' => true,
			'post_status' => 'publish',
			'post__not_in' => get_option( 'sticky_posts' ),
			'tax_query' => array(
				array(
					'taxonomy' => 'post_format',
					'terms' => array( 'post-format-aside', 'post-format-link', 'post-format-status', 'post-format-quote' ),
					'field' => 'slug',
					'operator' => 'IN',
				),
			),
		);
		$ephemera = new WP_Query( $ephemera_args );

		if ( $ephemera->have_posts() ) :
			echo $before_widget;
			echo $before_title;
			echo $title; // Can set this with a widget option, or omit altogether
			echo $after_title;
			?>
			<ol>
			<?php while ( $ephemera->have_posts() ) : $ephemera->the_post(); ?>

				<?php if ( 'link' != get_post_format() ) : ?>

				<li class="widget-entry-title">
					<a href="<?php echo esc_url( get_permalink() ); ?>" title="<?php printf( esc_attr__( 'Permalink to %s', 'newtheme' ), the_title_attribute( 'echo=0' ) ); ?>" rel="bookmark"><?php the_title(); ?></a>
					<span class="comments-link">
						<?php comments_popup_link( __( '0 <span class="reply">comments &rarr;</span>', 'newtheme' ), __( '1 <span class="reply">comment &rarr;</span>', 'newtheme' ), __( '% <span class="reply">comments &rarr;</span>', 'newtheme' ) ); ?>
					</span>
				</li>

				<?php else : ?>

				<li class="widget-entry-title">
					<?php
						// Grab first link from the post content. If none found, use the post permalink as fallback.
						$link_url = newtheme_url_grabber();

						if ( empty( $link_url ) )
							$link_url = get_permalink();
					?>
					<a href="<?php echo esc_url( $link_url ); ?>" title="<?php printf( esc_attr__( 'Link to %s', 'newtheme' ), the_title_attribute( 'echo=0' ) ); ?>" rel="bookmark"><?php the_title(); ?>&nbsp;<span>&rarr;</span></a>
					<span class="comments-link">
						<?php comments_popup_link( __( '0 <span class="reply">comments &rarr;</span>', 'newtheme' ), __( '1 <span class="reply">comment &rarr;</span>', 'newtheme' ), __( '% <span class="reply">comments &rarr;</span>', 'newtheme' ) ); ?>
					</span>
				</li>

				<?php endif; ?>

			<?php endwhile; ?>
			</ol>
			<?php

			echo $after_widget;

			// Reset the post globals as this query will have stomped on it
			wp_reset_postdata();

		// end check for ephemeral posts
		endif;

		$cache[$args['widget_id']] = ob_get_flush();
		wp_cache_set( 'widget_newtheme_ephemera', $cache, 'widget' );
	}

[/codesyntax]

Este método es un poco largo, así que voy a dividirlo y explicar el código.

[codesyntax lang=»php»]

<?php

		$cache = wp_cache_get( 'widget_newtheme_ephemera', 'widget' );

		if ( !is_array( $cache ) )
			$cache = array();

		if ( ! isset( $args['widget_id'] ) )
			$args['widget_id'] = null;

		if ( isset( $cache[$args['widget_id']] ) ) {
			echo $cache[$args['widget_id']];
			return;
		}

[/codesyntax]

Primero recuperamos los datos del widget desde la caché de WordPress.

Comprobamos que en caso de que no sea un array le damos el valor de un array vacío.

Comprobamos también que $args[‘widget_id’] no esta establecido y le damos el valor null.

Por último comprobamos que la caché disponga de algún contenido para el widget, si es así se muestra ese contenido y se devuelve un return para que php no siga ejecutando el método.

[codesyntax lang=»php»]

<?php

		ob_start();
		extract( $args, EXTR_SKIP );

		$title = apply_filters( 'widget_title', empty( $instance['title'] ) ? __( 'Ephemera', 'newtheme' ) : $instance['title'], $instance, $this->id_base);

		if ( ! isset( $instance['number'] ) )
			$instance['number'] = '10';

		if ( ! $number = absint( $instance['number'] ) )
 			$number = 10;

		$ephemera_args = array(
			'order' => 'DESC',
			'posts_per_page' => $number,
			'no_found_rows' => true,
			'post_status' => 'publish',
			'post__not_in' => get_option( 'sticky_posts' ),
			'tax_query' => array(
				array(
					'taxonomy' => 'post_format',
					'terms' => array( 'post-format-aside', 'post-format-link', 'post-format-status', 'post-format-quote' ),
					'field' => 'slug',
					'operator' => 'IN',
				),
			),
		);
		$ephemera = new WP_Query( $ephemera_args );

[/codesyntax]

En el caso de que no haya contenido en la caché de WordPress, el método continuará ejecutandose.

En este extracto de código vemos como primero se abre el buffer de php utilizando la función ob_start(). Esta función permite que en vez de mostrar cualquier contenido que le siguiente, lo almacena en buffer para después poder mostrarlo donde corresponda con ob_get_flush().

A continuación se recupera el título y el número de post a mostrar.

Se crea un array con los parámetros para ejecutar una consulta SQL.

Por último se crea una nueva instancia de WP_Query() que devolverá los registros encontrados en la base de datos.

[codesyntax lang=»php»]

<?php

		if ( $ephemera->have_posts() ) :
			echo $before_widget;
			echo $before_title;
			echo $title; // Can set this with a widget option, or omit altogether
			echo $after_title;
			?>
			<ol>
			<?php while ( $ephemera->have_posts() ) : $ephemera->the_post(); ?>

				<?php if ( 'link' != get_post_format() ) : ?>

				<li class="widget-entry-title">
					<a href="<?php echo esc_url( get_permalink() ); ?>" title="<?php printf( esc_attr__( 'Permalink to %s', 'newtheme' ), the_title_attribute( 'echo=0' ) ); ?>" rel="bookmark"><?php the_title(); ?></a>
					<span class="comments-link">
						<?php comments_popup_link( __( '0 <span class="reply">comments &rarr;</span>', 'newtheme' ), __( '1 <span class="reply">comment &rarr;</span>', 'newtheme' ), __( '% <span class="reply">comments &rarr;</span>', 'newtheme' ) ); ?>
					</span>
				</li>

				<?php else : ?>

				<li class="widget-entry-title">
					<?php
						// Grab first link from the post content. If none found, use the post permalink as fallback.
						$link_url = newtheme_url_grabber();

						if ( empty( $link_url ) )
							$link_url = get_permalink();
					?>
					<a href="<?php echo esc_url( $link_url ); ?>" title="<?php printf( esc_attr__( 'Link to %s', 'newtheme' ), the_title_attribute( 'echo=0' ) ); ?>" rel="bookmark"><?php the_title(); ?>&nbsp;<span>&rarr;</span></a>
					<span class="comments-link">
						<?php comments_popup_link( __( '0 <span class="reply">comments &rarr;</span>', 'newtheme' ), __( '1 <span class="reply">comment &rarr;</span>', 'newtheme' ), __( '% <span class="reply">comments &rarr;</span>', 'newtheme' ) ); ?>
					</span>
				</li>

				<?php endif; ?>

			<?php endwhile; ?>
			</ol>
			<?php

			echo $after_widget;

			// Reset the post globals as this query will have stomped on it
			wp_reset_postdata();

		// end check for ephemeral posts
		endif;

[/codesyntax]

Se comprueba si existen post para mostrar y si es que sí se muestran diferentes valores antes de iniciar el búcle que dará formato al contenido.

Se muestra cualquier contenido posterior al widget, se reincian los post globales que esta consulta haya podido pisar.

[codesyntax lang=»php»]

<?php

		$cache[$args['widget_id']] = ob_get_flush();
		wp_cache_set( 'widget_newtheme_ephemera', $cache, 'widget' );

[/codesyntax]

Por último se guardan los datos del buffer en la caché de WordPress.

[codesyntax lang=»php»]

<?php

	/**
	 * Deals with the settings when they are saved by the admin. Here is
	 * where any validation should be dealt with.
	 **/
	function update( $new_instance, $old_instance ) {
		$instance = $old_instance;
		$instance['title'] = strip_tags( $new_instance['title'] );
		$instance['number'] = (int) $new_instance['number'];
		$this->flush_widget_cache();

		$alloptions = wp_cache_get( 'alloptions', 'options' );
		if ( isset( $alloptions['widget_newtheme_ephemera'] ) )
			delete_option( 'widget_newtheme_ephemera' );

		return $instance;
	}

[/codesyntax]

Este método permite verificar que los datos que ha introducido el administrador sean correctos y se guarden en la caché para futuros usos.

[codesyntax lang=»php»]

<?php

	function flush_widget_cache() {
		wp_cache_delete( 'widget_newtheme_ephemera', 'widget' );
	}

[/codesyntax]

Este método elimina el widget de la caché de WordPress.

[codesyntax lang=»php»]

<?php

	/**
	 * Displays the form for this widget on the Widgets page of the WP Admin area.
	 **/
	function form( $instance ) {
		$title = isset( $instance['title']) ? esc_attr( $instance['title'] ) : '';
		$number = isset( $instance['number'] ) ? absint( $instance['number'] ) : 10;
?>
			<p><label for="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>"><?php _e( 'Title:', 'newtheme' ); ?></label>
			<input class="widefat" id="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>" name="<?php echo esc_attr( $this->get_field_name( 'title' ) ); ?>" type="text" value="<?php echo esc_attr( $title ); ?>" /></p>

			<p><label for="<?php echo esc_attr( $this->get_field_id( 'number' ) ); ?>"><?php _e( 'Number of posts to show:', 'newtheme' ); ?></label>
			<input id="<?php echo esc_attr( $this->get_field_id( 'number' ) ); ?>" name="<?php echo esc_attr( $this->get_field_name( 'number' ) ); ?>" type="text" value="<?php echo esc_attr( $number ); ?>" size="3" /></p>
		<?php
	}

[/codesyntax]

Este último método crea el formulario donde el administrador podrá modificar el widget.

Symfony, creando el archivo schema.yml para una base de datos ya existente

hace 13 años

by Mikel en Programación y sistemas

base bd build-schema cache cc conexion configurar configure construir database datos limpiar pdo pdo_mysql propel schema.yml symfony

Sí, sigo dándole caña a Symfony… y cometiendo errores de novato xD.

Para ir probando Symfony con un proyecto real, he decidido utilizar una base de datos ya existente para generar una nueva versión del proyecto anterior, y como ya sabrás para que Symfony (bueno, en este caso Propel) genere las clases necesarias para trabajar con la BD es necesario que la estructura de ésta esté en el archivo schema.yml dentro de la carpeta /config del proyecto.

Para ello, primero hay que configurar la conexión a la base de datos en symfony de la siguiente manera:

~~symfony configure:database «mysql://login:password@localhost/basededatos»~~
symfony configure:database «mysql:host=localhost;dbname=nombreBD» root pass

Ahora le decimos a Propel que genere el archivo schema.yml a partir de la base de datos:

symfony propel:build-schema

Propel coge los datos de configuración de la BD que le hemos dado anteriormente.

Y con esto se genera el archivo schema.yml y symfony está listo para generar las clases.

PD1: Propel utiliza PDO para conectar con la BD, si por alguna razón os muestra un error diciendo que no encuentra el driver o algo por el estilo, simplemente id al archivo php.ini y habilitad la extensión pdo_mysql y reiniciar apache, esto lo debería arreglar.

PD2: Cada vez que tengas que generar el modelo recuerda de limpiar la caché de symfony para evitarte problemas:

symfony cc

PD3: Si al generar el modelo, Propel te devuelve un error de «tabla duplicada» o parecido, solo tienes que ir a la carpeta /config del proyecto y eliminar un archivo llamado generated-schema.yml (si no recuerdo mal).

Mi última pesadilla: Optimizar el VPS para WordPress

hace 13 años

by Mikel en Programación y sistemas

apache AppServ blog cache CentOS cpu db eaccelerator hosting lamp linux memoria MySQL optimizacion optimizer PHP plesk plugin ram reloaded servidor ssh super supercache vps Wordpress wp zend

Pesadilla… de tres semanas y pico. Anoche soñé con la lista de procesos del comando top de Linux. Apache consumía cada vez más y más memoría. Por consumir, consumió el Kernel de Linux y se transformó en el Kernel de Windows. Y no se porqué antes de despertarme entre sudores fríos apareció Bill Gates descojonandose a moco tendido. Dios, ¡Qué imagen!, no se me quita de la cabeza.

Durante este tiempo me he didicado a «intentar» optimizar tanto el VPS como WordPress para reducir el consumo de memoría. Aunque he hecho algunas mejoras (pocas por desgracia) sigue cayendose Apache; pero comenzaré por el prinicpio:

¿Porqué un VPS?

Por el precio: Ví un VPS más o menos al mismo precio que un hosting y apliqué el dicho «burro grande ande o no ande».
Por aprendizaje: Nunca había probado un VPS y quería saber como poder administrarlo, que se puede hacer con él. No jodes tantas cosas como con un dedicado y hasta cierto punto tienes menos responsabilidad y es mucho más barato. Y es el paso lógico antes de administrar un dedicado, en el que ahí estas solo completamente.
Por unificar mis proyectos web: Dispongo de cinco dominios. Para cada uno tengo planes para crear una web con ellos,o en algunos casos ya está creada y online, en otro, estoy esperando a ver que pasa con el VPS y otros solo estan proyectados. Disponer de todas las webs en un solo servidor, ya que no tienen muchas visitas, es muy pero que muy cómodo, además de económico.
Por ahorar costes: Cinco dominios, cinco hostings. Aunque los hay muy baratos (desde un euro) siempre te limitan alguna cosa y no me convencian.
Por libertad: La posibilidad de hacer y deshacer a mi antojo, en definitiva, de tener el control de la máquina (virtual) es una gozada.

Características del VPS

Memoría RAM: 256 MB
Espacio en disco: 5 GB
Transferencia mensual: 150 GB
Sistema operativo: CentOS 5
Panel de control: Plesk
Y obviamente el resto de características habituales: Perl, PHP, MySQL, etc, etc, etc.

El principio

Cuando contraté este VPS, era un puto ignorante, así de claro, desconocía muchas cosas sobre la administración de servidores, su optimización, y sobre todo, las características que había que observar detenidamente antes de contratar nada (en VPS. En hosting, tengo bastante idea). Menos mal que era el más barato xD.

Desde el tercer o cuarto día comenzó a fallar Apache. Los datos que obtenía tanto de Plesk como de Virtuozzo me indicaban que la memoría se saturaba y paraba los servicios. Claro, como un ignorante creé un ticket al proovedor. La respuesta fué rápida (y ahora la más lógica), «actualice su VPS a uno superior». No comprendía como me podían decir eso. ¡Que sólo es un blog! ¡Que el día que llega a 100 visitas monto la fiesta padre! !Coño, que no es Digg, ni el Mundo! ¿Cómo podía ser que con solo al acceder a la página principal de la administración (el escritorio de WordPress), Apache ya se viniese abajo? ¿Cómo era posible?.

Sólo había una idea en mi cabeza: «Estos del hosting quieren sacarme más pasta» (Viendolo ahora, en cierto sentido, tenía razón). Pero esa idea no soluciona el problema, aunque mi cabezonería la convirtió en mantra y como con levantar Apache o reiniciar el contenedor volvía todo a funcionar, se quedo así durante meses.

Primeros intentos

No soy una persona que se rinda fácilmente. Yo siempre digo que en informática no hay nada imposible, sino poco presupuesto. Así que comencé a informarme sobre VPS, WordPress, Apache, etc. De esto puede dar fe mi navegador (uso Opera) que ahora mismo tengo abiertas unas 50 pestañas.

Lo primero fue buscar una forma para averiguar cuánta memoría consumía WordPress. Encontré el siguiente código:

$memoria_usada = round(memory_get_usage(1) / 1024,1);
echo ‘Memoria usada: ‘ . round(memory_get_usage() / 1024,1) . ‘ KB de ‘ . $memoria_usada . ‘ KB’;

Este código indica la memoría que había antes de ejcutar el script (que se guarda en la variable $memoria_usada y se pone al inicio del archivo) y la memoría consumida después de ejecutar el script (que se pone al final). Los datos en local que saqué fueron los siguientes:

9 plugins: Memoria usada: 27462 KB de 67.1 KB
Sin plugins: Memoria usada: 20468.8 KB de 67.2 KB
Actualizando el theme: Memoria usada: 21049.1 KB de 67.1 KB (Utilizando el theme que tengo en el blog actualmente, sustituyendo al theme por defecto)

Siento no tener los datos del VPS, pero no varían mucho. Ahora mismo consume 29,5 MB con ocho plugins activos (no son los mismos plugins han variado desde entonces) más el theme.

Las pruebas las realicé con WordPress 3.0.1 con la base de datos tal cual se instala, bajo Windows con la suit de AppServ sin modificaciones.

Yo, cuando ví las cifras, me quedé alucinado: ¡Wordpress consume casi 20,5 MB!. Realicé pruebas con otras versiones de WordPress para verificar que esto era así, es decir, comprobar que con el paso de las versiones el consumo de memoria había aumentado. Que no era cosa mía, sino que es así de chupón. Aunque aquí puede variar el consumo de memoría dependiendo de las reglas de mod_rewrite de Apache, de como esté optimizado PHP y MySQL, etc. El único culpable no es WordPress, pero acojona.

Viendo lo visto, era hora de actuar.

WordPress a dieta

Sabía que existian varios plugins que permitian cachear las páginas del blog y reducir el consumo de memoria y procesador, pero simpre lo había visto en blogs con miles de visitas, no en uno cutre con theme gratuito que no llega a las cien visitas diarias (triste pero cierto).

El primero en activar en el blog, wp-cache, me costó un poco instalarlo, más por mi inexperiencia con cachés que otra cosa (mira que es sencillito el plugin). Al final no se lo que me paso, no lo recuerdo, que lo desactivé. Busqué otro.

WP Super Cache, no mienten los que hablan bien de él, funciona estupendamente, es un poco más complicado de configurar que wp-cache pero el resultado es magnífico. Pero el blog seguía consumiendo casi 30 MB de memoría y Apache se caía. Mejoró la estabilidad del blog un poco, al menos de cara al visitante sí. Pero seguía con el mismo problema: en cuanto entraba en el Escritorio Apache se escoñaba.

Antes de esto probé cada uno de los plugins para ver cual era el que hacía que Apache se cayera nada más entrar en las administración del blog. WordPress.com Stats era el culpable, la establidiad mejoró sustancialmente teniendo este plugin desactivado. Durante unos días pensé que estaba solucionado el problema, nada más lejos de la realidad. Aunque el blog consumia menos memoría, en cuanto hacía algo que requiriese más esfuerzo por parte de la RAM, Apache se venía abajo. Simplemente con entrar varias veces en el escritorio del blog o activar un plugin, Apache caía. Fue frustrante.

Un plugin del que no conocía su existencia es DB Cache Reloaded. Como su nombre indica, permite cachear las consultas a la base de datos, evitando que se conecte a la base de datos cada vez que haya una petición a esta. Reduce el consumo de recursos. Bien. Activado está y funciona de maravilla, aunque de momento no termina de cachear todas las consultas. Tendré que mirar porqué.

Pero el problema continuaba, Apache se caía. Había que entrar en el servidor.

SSH

Tengo que admitir que no me había conectado nunca a otro ordenador a través de SSH, si a través de VNC y VPNs.

Trabajo con Windows XP SP3 principalmente, pero no le hago ascos a las distribuciones linux, todo lo contrarío: en VirtualBox tengo instalados Debian, CentOS, Ubuntu y ChromeOS, y excepto para el tema de configurar la tarjeta gráfica que aun no he conseguido (creo que VirtualBox es el que no la reconoce y por algún motivo envía al SO una tarjeta gráfica compatible con la que tengo, pero me obliga a estar con una resolución de 800×600).

Bien, ¿porqué cuento esto?. Además de por que quería contarselo a alguien xD, por que así comprenderás que después de varios intentos por conectarme al servidor con varios programitas para Windows, arrancase una máquina virtual para conectarme por la consola de linux. ¡Bendita seas!. Hasta que descubrí que lo que me fallaba era el puerto para poder acceder. ¡La ignorancia da la felicidad!.

Una vez conectado al servidor lo primero que hice fue un top de la máquina para conocer el consumo de RAM (la leche no) en tiempo real.

Me indicaba que tenía 512 MB de RAM total y la memoría consumida oscilaba entre los 170 y los 220 MB, aunque en algunos podía llegar a 270 MB. El problema radica en que el VPS no tiene 512 MB de RAM sino 256 MB; los otros 256 es memoría compartida, con lo que no puedo contar con ella para realizar el cálculo.

También hice un free -m para comprobar la memoria, pero top me ofrece más datos.

Observé que cuando se pide al servidor una página apache ejecuta cuatro procesos de sí mismo llegando en varios casos a consumir un 12 por ciento de memoría RAM. Lo normales un 10 por ciento.

A por Apache

Optimizar Apache. Me costó un huevo y medio encontrar la ubicación de los archivos de configuración, pero cuando me enpeño… (/etc/httpd/conf en CentOS). Bien, leí que si realizaba ciertas modificaciónes en el archivo httpd.conf de Apache podría reducir el consumo de memoría. Por defecto la configuración de Apache era la siguiente:

<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

Se quedo así:

<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 30
MaxClients 30
MaxRequestsPerChild 40000
</IfModule>

No solucionó mucho, o por lo menos yo no lo noté. Reduje también varios parámetros más, como el tiempo que espera Apache para cerrar una conexión permanente, etc.

Esto seguía sin mejorar. Probemos con la base de datos

MySQL

Poca optimización realicé aquí, la verdad. Me limite a añadir la configuración para habilitar la caché de la BD, pero no ha hecho mucho. También puede deberse a que el plugin de WordPress que cachea las consultas ya lo está haciendo. No sé. La configuración quedo del siguiente modo:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 8M

PHP

Para optimizar PHP necesitaba instalar en el VPS Eaccelerator y el Zend Optimizer, mis pocos intentos me han llevado a pensar que no puedo instalar nada que no sea a través de Plesk o que necesite el comando yum. Por tanto, a día de hoy, PHP está sin optimizar, habrá que enviar un ticket a ver si ellos me lo isntalan…

VPS

CentOS consume memoría, como todos los SO, las veces que he podido ver el consumo de memoría sin Apache, está rondaba entre 60 y 80 MB. Pero no sólo es el sistema operativo el que consume RAM, Plesk también consume lo suyo (unos 50 MB), he deshabilitado el antivirus que me consumía 70 MB cada vez que se iniciaba. Pero aunque el VPS se ha estabilizado hay momentos en los que Apache tiene cuatro procesos abiertos de 50-60 MB cada uno (según el comando top). Excesivo.

Intenté crear un archivo SWAP pero el comando swapon no lo tengo permitido, al menos por SSH.

CONCLUSIONES

Sigo valorando distintas opciones respecto a la optimización del VPS, ahora mismo mi mejor baza es Eaccelerator y que me lo instalen en el VPS para reducir la memoría.
Seguiré probando con algunnos plugin de WordPress a ver que tal.
Si estas interesado en la contratación de un VPS andate con ojo con la RAM.
Me he planteado incluso cambiar de VPS o ampliarlo con la misma empresa o marcharme a otra, ya se verá en septiembre.
Lo mejor de todo esto: lo aprendido por el camino. No solo conozco un poco mejor los sistemas Linux, sino también Apache, PHP, MySQL y Plesk, y su administración.
Bueno, ¿Y vosotros?¿Qué experiencia habeis tenido con los VPS?¿Qué consejos podeis darme? o simplemente ¿Qué opinais? Los comentarios son vuestros… mientras Apache lo permita xD.

LINKS

Os dejo unos links y así libero al navegador de carga, pobre.

Optimización del VPS

Optimización de WordPress

Optimización de PHP

Optimización de Apache

Symfony: Archivos de configuración

hace 13 años

by Mikel en Programación y sistemas

apliación app archivos cache configuracion etiquetas filters framework meta modulo PHP routing security symfony view Web yaml yml

Bueno, sigo dandole caña a Symfony a través del manual en español, y después de practicar un poco con los conocimientos que he adquirido últimamente, puedo haceros un resumen de lo que os vais a encontrar.

(más…)

Pasar un proyecto symfony de un servidor a otro (a capón xD)

hace 13 años

by Mikel en Programación y sistemas

AppServ archivo cache configuracion error Problema Programación servidor solución symfony wamp yml

Sí, soy un poco bestia para algunas cosas jejeje; en este caso tuve que pasar el proyecto con el que estaba trabajando en el portatil al ordenador de sobremesa. En el portatil tengo instalada una versión de WAMP y en el sobremesa AppServ así que cuando pasé la carpeta del proyecto con un copy&paste y fui a ejecutarlo al navegador, obviamente no funcionaba, exactamente daba este error:

Warning: sfAutoload::require(C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php) [sfautoload.require]: failed to open stream: No such file or directory in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

Fatal error: sfAutoload::require() [function.require]: Failed opening required ‘C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php’ (include_path=’.;F:\AppServ\php5\pear’) in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

(más…)

Interadictos

Entradas etiquetadas con cache

WordPress 3.x para desarrolladores: Temas y plantillas, widgets.php

WIDGETS.PHP

Symfony, creando el archivo schema.yml para una base de datos ya existente

Mi última pesadilla: Optimizar el VPS para WordPress

Symfony: Archivos de configuración

Pasar un proyecto symfony de un servidor a otro (a capón xD)

Iniciar sesión