My impressions on the need or uselessness of a control panel for a commercial single-server web project with a part-time admin are based on an experience I had a couple of years ago.
(https://www.ovhcloud.com/sites/default/files/styles/large_screens_1x/public/2020-08/Serveur%20Plesk.png)
Some friends needed my technical assistance in purchasing a news website, where we had to ensure that everything was transferred correctly and figure out what improvements could be made. The website was running on an old Debian6 with a self-written CMS, nginx, php7.3 FPM, mysql tuned Percona, and it worked well. However, the new owner decided to find a programmer to optimize the website and migrated it to a $10 shared web hosting controlled by his usual IS ****er.
Soon enough, the website slowed down, and we found some security issues through the control panel. Ultimately, we moved to RuVDS, where we installed Plesk to automate basic tasks and ensure safety quickly and efficiently. This experience taught me the importance of having the right tools in place, especially with a part-time admin.
The recent challenge was to handle 2000 connections, which prompted us to upgrade to Plesk 17.8 with nginx caching features. When the Yandex.zen feed stopped working and nginx mistakenly cached a 500th error, we experimented with memcached through Laravel's built-in support. Installing it through a docker image and pecl module was straightforward, though there's no significant increase in throughput yet.
We even updated to Plesk Obsidian (18.0) without any issues and found its interface to be more modern and convenient, including the Advanced Monitoring feature on Grafana. SSL management is also easy with Let's Encrypt. While Plesk has some limitations like the lack of clustering options, overall it has been a stable and reliable software that doesn't consume too many resources.
What do 1000 simultaneous connections mean for a news website? A significant amount of users are needed to create that many parallel requests, each with a processing time of around 100 ms. However, php-fpm may not be sufficient to handle this workload due to insufficient workers or issues within the code itself.
While some may argue for using Laravel on a news site, it may not be the most efficient choice in terms of speed and size of the codebase. Micro-frameworks with a router and DI functionality can cover most tasks and lead to faster performance.
Allocating one and a half gigs of memory to memcached may not be necessary for a regular site, and it may be better to allocate the memory to php-fpm or mysql instead. Additionally, transferring SSH to a non-standard port can deter bots and improve security.
High load averages (LA) are not only caused by percentage; disk crashes can also bring up LA, which can be critical for certain tasks. While it may be difficult to identify the cause of such issues, a larger budget for a better web server can help handle the number of visitors. Ideally, separate machines for the web and database are preferred, but allocating higher capacities for web and MySQL on the same machine can also work.
Additionally, allocating tmpfs to /tmp can assist php scripts if memory allows for it. SSD/NVMe storage is also recommended, though it may already be in use. Be cautious with memcached usage and check internal stats to optimize memory allocation. VDS on HDD may no longer be viable.
While the architecture could have been improved, the sudden traffic increase at the start was unforeseen. While separation of servers by role can be optimal, it can also create additional complications and may not be feasible in terms of time and resources. Instead, focusing on maximizing the current configuration may be beneficial.
Older versions of Plesk also had issues with restoring backups on new servers, leading to potential site loss. As a result, other control panel options such as Vesta or DirectAdmin were utilized.
Moving to shared hosting from a dedicated setup is a critical decision for any project. In your case, the transfer to a $10 shared hosting environment illustrated the immediate drawbacks of limited server resources. Shared hosting environments are often oversubscribed; the performance can degrade significantly under load, which was evident when the website experienced slowdowns. This leads to a crucial consideration: the suitability of infrastructure for the expected traffic and application demands.
The revelation of security issues through the control panel on the shared host indicates that management tools can provide visibility into potential vulnerabilities. A well-configured control panel can often notify administrators about common security risks or misconfigurations, which is particularly beneficial when the admin may not be full-time or dedicated to the task. With a self-written CMS and a unique stack like Percona MySQL, having proactive security checks could prevent potential exploits that are otherwise difficult to monitor on an ad-hoc basis.
When you transitioned to RuVDS and installed Plesk, it clearly marked a shift towards a better-managed solution. The ease of use provided by Plesk is critical in a scenario where the admin may not have extensive experience with server management. The automation of repetitive tasks—like backups, updates, and security patching—liberates time and allows admins to focus on more strategic improvements to the website, rather than getting bogged down in routine maintenance.
Handling 2000 connections brings light to scalability challenges typical of growing websites. Upgrading to a version of Plesk that includes Nginx caching features demonstrates an effort to enhance performance proactively. Understanding how caching works can fundamentally change the way web applications respond to user requests, but it can also introduce complexities, such as the cached error you encountered. This highlights the need for careful configuration and monitoring to ensure that caching works as intended without introducing errors that compromise user experience.
Your experimentation with memcached through Laravel showcases the iterative approach to performance optimization. Leveraging containers, like Docker, for deploying such services is a modern approach that offers flexibility and isolation, but it also requires expertise in both Docker and the frameworks you are using. The fact that you didn't see a significant increase in throughput suggests that various factors, such as application design or network latency, could be influencing performance more than caching. This illustrates an essential lesson: performance tuning is often an iterative process that requires comprehensive monitoring and analysis to identify bottlenecks.
Updating to Plesk Obsidian without issues speaks to the stability and user-friendliness of the platform. Software updates should not be overlooked, as they can introduce new tools and features that further enhance site management capabilities. The advanced monitoring features you mentioned provide critical insights into server health and traffic patterns, empowering admins to make informed decisions based on real-time data.
SSL management through Plesk's integration with Let's Encrypt simplifies the previously complex process of certificate management, ensuring that security certificates are renewed automatically. With increasing focus on site security and encryption, an intuitive interface for SSL management helps ensure compliance with best practices and enhances user trust.
Without user intervention. Disadvantages of clustering are complexity and inability to recover from database corruption.
Quote from: spinneren on Sep 04, 2022, 08:10 AMMy impressions on the need or uselessness of a control panel for a commercial single-server web project with a part-time admin are based on an experience I had a couple of years ago.
(https://www.ovhcloud.com/sites/default/files/styles/large_screens_1x/public/2020-08/Serveur%20Plesk.png)
Some friends needed my technical assistance in purchasing a news website, where we had to ensure that everything was transferred correctly and figure out what improvements could be made. The website was running on an old Debian6 with a self-written CMS, nginx, php7.3 FPM, mysql tuned Percona, and it worked well. However, the new owner decided to find a programmer to optimize the website and migrated it to a $10 shared web hosting controlled by his usual IS ****er.
Soon enough, the website slowed down, and we found some security issues through the control panel. Ultimately, we moved to RuVDS, where we installed Plesk to automate basic tasks and ensure safety quickly and efficiently. This experience taught me the importance of having the right tools in place, especially with a part-time admin.
The recent challenge was to handle 2000 connections, which prompted us to upgrade to Plesk 17.8 with nginx caching features. When the Yandex.zen feed stopped working and nginx mistakenly cached a 500th error, we experimented with memcached through Laravel's built-in support. Installing it through a docker image and pecl module was straightforward, though there's no significant increase in throughput yet.
We even updated to Plesk Obsidian (18.0) without any issues and found its interface to be more modern and convenient, including the Advanced Monitoring feature on Grafana. SSL management is also easy with Let's Encrypt. While Plesk has some limitations like the lack of clustering options, overall it has been a stable and reliable software that doesn't consume too many resources.
Plesk simplifies site clustering with its intuitive interface, enabling efficient management and scaling of multiple websites from a single control panel.
Limitations: However, Plesk's clustering capabilities may be limited by its compatibility with specific server configurations and potential performance issues under high traffic loads.