Updated link to sfErrorLoggerPlugin manual

gentle-introduction/en/18-Performance.markdown

@@ -583,7 +583,7 @@ Listing 18-20 - Turning Features Off, in `frontend/config/filters.yml`
 
 Some features are useful only in development, so you should not activate them in production. This is already the case by default, since the production environment in symfony is really optimized for performance. Among the performance-impacting development features, the debug mode is the most severe. As for the symfony logs, the feature is also turned off in production by default.
 
-You may wonder how to get information about failed requests in production if logging is disabled, and argue that problems arise not only in development. Fortunately, symfony can use the `sfErrorLoggerPlugin` plug-in, which runs in the background in production and logs the details of 404 and 500 errors in a database. It is much faster than the file logging feature, because the plug-in methods are called only when a request fails, while the logging mechanism, once turned on, adds a non-negligible overhead whatever the level. Check the installation instructions and [manual](http://plugins.symfony-project.org/plugins/sfErrorLoggerPlugin).
+You may wonder how to get information about failed requests in production if logging is disabled, and argue that problems arise not only in development. Fortunately, symfony can use the `sfErrorLoggerPlugin` plug-in, which runs in the background in production and logs the details of 404 and 500 errors in a database. It is much faster than the file logging feature, because the plug-in methods are called only when a request fails, while the logging mechanism, once turned on, adds a non-negligible overhead whatever the level. Check the installation instructions and [manual](http://www.symfony-project.org/plugins/sfErrorLoggerPlugin).
 
 >**TIP**
 >Make sure you regularly check the server error logs--they also contain very valuable information about 404 and 500 errors.