![]() Its performance is closer to the speed of RAM than commonly used spinning disks on cheap hostings or even some basic SSD storage. What should be noted here is that Wordpress database is on localhost of a tested container and is stored on Intel Optane - the fastest NVMe storage drive at the moment of writing. WP object cache combined with Redis gave improvements well below expectations (only 3%) considering the speed and potential of Redis itself.Site with TTFB being too long will be perceived as slow, laggy, un-responsive. Somehow this time became very critical for UX as patience is not on the list of things a webpage owner can count on. It is a "passive time" on his side while he is waiting, during which he is not being able to do anything else to speed up things. Most of that time consists of making a connection with the server that hosts the webpage, distance between the user-server and often the bigest part due to a server preparing the (HTML) response which depends on hardware speed, load on a server, code, cache, database lookups, file lookups.įrom a UX perspective TTFB is the duration leading up to the moment when a user will get a feeling "Ok, something happened and I will see content in a very short time". With that info browser can start preparing things for display. In technical terms it's the moment when the users' browser starts receiving information from a server response (headers and HTML content of a page). How fast is the site loading? How fast it's responding to my clicks? And among key performance indicators of speed is TTFB (Time to first byte). One of the most important UX parameters for users' browsing the webpage is its "perceived speed". BASE performance numbers provide raw (uncached) performance of used software (Linux, PHP, Wordpress.) running on a given server hardware. ![]() Cache was cleaned and all key applications - NGINX, PHP-FPM 7.4 and Redis server - restarted before running each test.It could make a noticeable change if serving visitors on other continents, but only a minor impact if your target users are within the same region or even country. This does not encompass real-world effect of distance between the user and the server. Tests were performed within the same LAN/network, but from a different server and with SSL termination.Defining the BASE performance (without any cache) in terms of Reqs/sec and avg.Benchmarking tools in use: Apache Benchmark and Google Chrome (developer Tools).Sed -i 's/= 99999/= 9999999/' benchmark.Main objective is to measure the impact on performance by different cache enhancements on a Wordpress webpage with TTFB as the main key performance indicator: Hope somebody will be able to reproduce my results and the maintainer of php will be able to take some actions if possible at all. I rerun the tests a number of time and the numbers stay in the same range - this is a very large difference - my speculation is that either the CentOS gcc produces better code or some optimization flags were not set when compiling php on Alpine. the important value is the ratio between the run times - in this case Alpine was close to 40% slower ). On the same system running CentOS 7 and Alpine 3.16 as containers with both having php 8.0.26 I got 28.478 sec for CentOS and 39.605 sec for Alpine 3.16 ( the actual run time is not important - the values are for an older system - on a modern Xeon based system it takes about 17 sec. ![]() I run a very simple benchmark script link with count increased by 100 to get larger values. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |