tag:blogger.com,1999:blog-13314484178610195452024-02-02T01:37:19.814-08:00Massive ScaleNews on website scalability, high availabilty and high speed web applicationsAnonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.comBlogger55125tag:blogger.com,1999:blog-1331448417861019545.post-57658858144152893172018-04-12T00:33:00.000-07:002018-04-12T00:33:19.922-07:00Dropping the botnetGoogle Analytics sent me an email earlier today about changes in their data retention policy:<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
Today we introduced granular data retention controls that allow you to manage how long your user and event data is held on our </blockquote>
<blockquote class="tr_bq">
servers. Starting May 25, 2018, user and event data will be retained </blockquote>
<blockquote class="tr_bq">
according to these settings; Google Analytics will automatically delete </blockquote>
<blockquote class="tr_bq">
user and event data that is older than the retention period you select. </blockquote>
<blockquote class="tr_bq">
Note that these settings will not affect reports based on aggregated data.</blockquote>
<blockquote class="tr_bq">
<br /></blockquote>
<blockquote class="tr_bq">
Action: Please review these data retention settings and modify as needed.</blockquote>
<blockquote class="tr_bq">
<br /></blockquote>
<blockquote class="tr_bq">
Before May 25, we will also introduce a new user deletion tool that allows </blockquote>
<blockquote class="tr_bq">
you to manage the deletion of all data associated with an individual user </blockquote>
<blockquote class="tr_bq">
(e.g. site visitor) from your Google Analytics and/or Analytics 360 </blockquote>
<blockquote class="tr_bq">
properties. This new automated tool will work based on any of the common </blockquote>
<blockquote class="tr_bq">
identifiers sent to Analytics Client ID (i.e. standard Google Analytics </blockquote>
<blockquote class="tr_bq">
first party cookie), User ID (if enabled), or App Instance ID (if using </blockquote>
<blockquote class="tr_bq">
Google Analytics for Firebase). Details will be available on our Developers </blockquote>
<blockquote class="tr_bq">
site </blockquote>
</blockquote>
I decided to delete Google Analytics tracking code from both <a href="https://massivevps.net/">Massive VPS</a> and <a href="https://massivescale.net/">Massive Scale</a> websites. It was an invaluable tool in the early days when we still had to advertise in Adwords but these days there's really no excuse for voluntarily sending our visitors' data to Google.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-10649121423274171422017-01-21T11:54:00.001-08:002017-01-21T11:54:45.404-08:00The first performance issue I've fixedThe first performance problem I've found and fixed in code written by someone else was in Gadu-Gadu. GG was an Windows instant messenger very popular in Poland in the early 2000s. It was closed, binary-only code but due to its popularity a modding "underground" has been formed quickly and soon, its protocol was reverse engineered.<br />
<br />
I was about 18 years old at the time and I had a running competition with a friend to make our Windows systems look and feel like Amiga OS. We had the basic things covered, but some programs were not themeable at the time. GG was one of them and I thought: challenge accepted.<br />
<br />
I decided to use PowerGG, a live patching framework by Ajron. I've quickly found out that the conversations were displayed in an embedded Internet Explorer control and were plain old HTML + Javascript. Then I've found a way to patch that HTML code and it looked just like Amiga.<br />
<br />
GG always had this annoying bug that the longer your conversation was the slower the program was. And boy, our conversations were long these days, we were teens and had lots of time on our hands. Sometimes we talked so much that the program froze for several seconds after I pressed Enter.<br />
<br />
After looking at the Javascript code it quickly became obvious why this is happening: GG was looking for a <div> containing the last message, and then appended the new message after that <div>. But instead of getting the number of <div>s and finding the last one, it iterated over all of them. And, since these were days long before the V8 engine, Javascript wasn't very fast on 400 MHz CPUs and iterating several hundred DOM elements took a lot of time. It was a three-line code change and it made the messages send instantly.<br />
<br />
If you want to verify my story. the PowerGG plugin was briefly named "Amigo" and then released as "Foolteen".Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-12194625329436208502015-07-27T03:17:00.002-07:002015-07-27T03:18:35.303-07:00Varnish for Joomla maintenance releaseIt seems that with Joomla! 3.4.3, our patch for Varnish support could not be applied, so we made a maintenance release - as usually, available for free for the existing clients. There are no new features, so you won't need it unless you're planning to upgrade to Joomla! 3.4.3 or later.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-54506698433651959502015-04-27T09:55:00.001-07:002015-04-27T09:55:06.439-07:00Apache mod_status page mangled by mod_rewrite?Quicktip: if a complicated mod_rewrite setup is making your /server-status inaccessible, just paste the following two lines above all the rewrite rules:<br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">RewriteCond %{REQUEST_URI} /server-status</span><br />
<span style="font-family: Courier New, Courier, monospace;">RewriteRule .* - [L]</span><br />
<br />
and you're ready to set up <a href="http://massivevps.net/monitoring.html">monitoring</a> of Apache processes.<br />
If the rules are in /etc/apache2, not in .htaccess, you need to reload the web server too:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">/etc/init.d/apache2 reload</span><br />
<br />
You know you shouldn't use .htaccess anyway because it hurts performance, right?Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-72497587400546540252015-04-14T11:05:00.001-07:002015-04-14T11:08:33.219-07:00Upgrade your Varnish!Surprisingly, Varnish Software <a href="https://www.varnish-cache.org/lists/pipermail/varnish-announce/2015-April/000702.html">announced</a> that they will not update Varnish 3.0 and that users need to upgrade to 4.0 as soon as possible. This is not an expected decision, it has been stated more than once on the varnish-misc list that 3.0 will be supported for a long time in the foreseeable future. This means it's not secure to use Varnish Cache 3 on your server, if you keep running this software you may get hacked.<br />
If you need help upgrading your setup from Varnish 3 to 4, <a href="https://massivescale.net/contact.html" rel="nofollow">contact us</a>. We can convert your old configuration file in-place on your server or set up a staging environment and update your server after it's tested.<br />
<a href="https://massivescale.net/varnish-joomla.html">The Varnish-Joomla package</a> includes a Varnish 4 VCL since it has been released a year ago, so the upgrade path is straightforward.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-77480843290403296092015-03-11T12:05:00.001-07:002015-03-11T12:07:05.643-07:00Varnish for Joomla! 3.4The latest <a href="https://massivescale.net/varnish-joomla.html">Varnish Cache package for Joomla!</a> v1.3.5 is available. Now you can <a href="https://massivescale.net/site-boost-joomla.html">accelerate Joomla CMS</a> version 3.4.<br />
Existing clients can contact us to get the new version for free.<br />
If you're running a high traffic website and don't want to lose clients to downtime, perhaps we can interest you in our inexpensive <a href="http://massivevps.net/monitoring.html">server monitoring</a> services?Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-79497726310374149532014-09-19T03:00:00.000-07:002014-09-19T03:00:02.055-07:00How not to check if Varnish is working.Our new Varnish clients who choose to install everything themselves want a way to verify if it's working - and often fall in the same trap: they use the isvarnishworking.com website which has good SEO and promises to be an easy way to check if everything is running correctly.<br />
Most often the answer is "Nope" - indicating that Varnish isn't operating - even thought the cache is running. I checked I can work around that - maybe they're doing some simple check that can be passed with a minor modification to the VCL file.<br />
Unfortunately, I've found out that the data presented on this website is completely useless - the headers they show to visitors are different from actual headers sent by the server!<br />
You can see that yourself below:<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUf3wOy65DoCRO1oSHbJ5e-SiAFAXthkxIeyxlKx-yNAvDX5M2SML7zPucqmuy6Vt7qBYuR0f7Up8i_4NW5nQ38Ew9GjP1KQlWhFbr_GmY7BrySLexco-o3uD_QMZ6FW7L8M8Hrxn5Hlo/s1600/isvarnishworking1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUf3wOy65DoCRO1oSHbJ5e-SiAFAXthkxIeyxlKx-yNAvDX5M2SML7zPucqmuy6Vt7qBYuR0f7Up8i_4NW5nQ38Ew9GjP1KQlWhFbr_GmY7BrySLexco-o3uD_QMZ6FW7L8M8Hrxn5Hlo/s1600/isvarnishworking1.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The headers isvarnishworking.com shows</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj380Fpr8R8K1aHjESYRyfPkOfqicA54k_d8-v2Coqv1j_a_zwU-jgVgTPA8y-bHb-v6pFQVtWsddB1ty-scM9c-_fzWPyUdZ1SoxCLCkdHloBV6v-gTtaezZdl9uO1pwBlVmW_UsuVaOs/s1600/isvarnishworking2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj380Fpr8R8K1aHjESYRyfPkOfqicA54k_d8-v2Coqv1j_a_zwU-jgVgTPA8y-bHb-v6pFQVtWsddB1ty-scM9c-_fzWPyUdZ1SoxCLCkdHloBV6v-gTtaezZdl9uO1pwBlVmW_UsuVaOs/s1600/isvarnishworking2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Actual headers, as seen by wget</td></tr>
</tbody></table>
<br />
I don't understand what's the point of building a service showing fake HTTP headers.<br />
<br />
When testing, just use the Network tab in developer tools in your browser, or wget/wbox if you're a command line user.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-62161179091557278462014-06-19T01:40:00.001-07:002014-06-19T01:40:35.316-07:00Patch for 3.3.1Joomla! 3.3.1 changed some of the patched code, so the patches from 3.3.0 won't work with 3.3.1. Existing users need to ask for the new version (for free, as usually).Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-81212937442051327562014-06-17T06:26:00.001-07:002014-06-17T12:04:46.871-07:00VividCortex reviewEDIT: Baron Schwartz kindly asked me to remove this blog post. I'm not going to do this, but I agree it was too harsh, it's my fault I didn't read the terms of service I was going to review.<br />
<br />
Back story: I reviewed free trial of a service. The legal document I accepted when registering did not allow trial users to publish their reviews. They contacted me about it and you can see my original reaction below. I don't think this is the best way to promote a product, but it's just my personal opinion, and Baron - being an experienced blogger - claims it's normal practice.<br />
<br />
Remember, kids: use only Free Software if you don't want any trouble!<br />
<br />
<strike>There was a 3 pages long VividCortex review here, but they said writing a public review violates their ToS unless they accept it. If they don't want free publicity, I don't care and wish them all the best promoting their product this way.</strike>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-44191551696970456272014-05-16T09:30:00.000-07:002014-05-16T09:30:02.320-07:00Varnish 4 support and benchmark<p> A <a href="">Varnish4</a>-ready configuration file for the <a href="http://massivescale.net/varnish-joomla.html">Varnish-Joomla pack</a> is now ready. We also made a little benchmark. <strong>TLDR: there are no significant differences between Varnish 3 and Varnish 4</strong>.</p>
<p> The Varnish under load has been a <a href="http://massivevps.net/#le1024">2-core VPS with 1GB RAM</a>. Varnish 3.0.4 from repos has been tested against Varnish 4.0.0 built from a source tarball. Both were configured in an identical way, except from the VCL of course. There was Joomla 3.3 behind Varnish, and cache has been pre-warmed before testing in both cases.</p>
<p> The machine generating load has been a 6-core hardware server with 32 GB RAM. The software used to generate load was the Apache Benchmark.</p>
<p>The machines were in different data centers owned by the same company, the traffic has been routed via internal network (6 hops, 2ms ping). Both machines were connected using a gigabit ethernet card. Bandwidth usage has been around 500 Mbit/s at all time. Traffic volume has been bound by CPU usage on the Varnish machine with system load approaching 20 at the end of the test for both Varnish versions.</p>
<p> Both Varnish versions performed similarly. It was worrying that Varnish 4 had a number of failed connections - the test has been repeated more than one time, and the failed connections always were there. This did not happen with Varnish 3.</p>
<p> Without further ado: <a href="http://pastebin.com/0kpeLfJK">Varnish 3</a> and <a href="http://pastebin.com/Yc4bFeZE">Varnish 4</a> results from AB.</p>
<p> If you need help building the new Varnish from source, converting your configuration or vmods, or anything else Varnish-related, don't hesistate to <a href="https://massivescale.net/contact.html">contact us</a>.</p>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-25627850708099918922014-05-13T08:52:00.001-07:002014-05-13T08:53:02.347-07:00Varnish for Joomla! 3.3<p>The <a href="http://massivescale.net/varnish-joomla.html">Varnish-Joomla pack</a> has been upgraded to support Joomla! 3.3 which has been released last week. Existing clients are eligible for a free upgrade after <a href="http://massivescale.net/contact.html">contacting us</a>.</p>
<p>Originally we planned this release to support Varnish 4 which has been released two weeks ago, but it was more work than expected and clients were more interested in Joomla 3.3 support.</p>
<p>Varnish 4 doesn't bring any significant performance gains for small-to-middle sized web sites, it has separate backend and frontend processing threads, which could be better in certain high-traffic scenarios. It looks like this release was more focused on cleaning up the Varnish Configuration Language and bringing log analysis features (which are <a href="https://www.varnish-cache.org/docs/trunk/reference/vsl-query.html">awesome</a>, by the way).</p>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-79191615206951739822014-02-18T09:18:00.001-08:002014-02-18T09:18:25.060-08:00The future of Varnish-JoomlaWe got a lot of questions recently about the <a href="https://massivescale.net/varnish-joomla.html">Varnish-Joomla package</a> and support for future Joomla versions. Of course the package is going to be still developed in foreseeable future, and Joomla 3.5 support is planned.<br />
This larger than usual volume of questions made me try to get my hands on a copy of Joomla 3.5 development code - only to discover that <a href="https://groups.google.com/forum/#!topic/joomla-dev-general/7nZ9eeiXnzo">there is none yet</a>. The next release of Joomla will be version 3.3 and it will be released on the <a href="https://en.wikipedia.org/wiki/April_Fools%27_Day">April Fool's Day</a>. 3.5, the long-awaited Long Term Support release initially scheduled for March 2014, is postponed to October.<br />
Long-time Joomla users are used to rapid changes of plans, and I can have a hassle-free summer (after releasing our software for 3.3 in April, of course).Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-12103189277461579082014-01-08T14:00:00.000-08:002014-01-08T14:00:04.447-08:00e503 no service<a href="http://www.apsis.ch/pound">Pound</a> is a popular load balancer / SSL terminator. As it usually happens with open source programs, there is plenty of documentation and self-help available on the internet, but there's one error message I could not find. Pound denied access to the web site and logged the following message:<br />
<br />
<code>
pound: (756000001700) e503 no service "GET / HTTP/1.1" from 12.34.56.78 www.thedomain.com
</code>
<br />
<br />
I've found out that access to a <a href="http://linux.die.net/man/8/pound">service</a> has been blocked by a <b>HeadDeny</b> directive. The specific problem was denying requests containing the X-Forwarded-For header - which blocked access by users behind proxies. Changing HeadDeny in service to a HeadRemove in listener fixed the problem.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-39632171188766785082014-01-07T09:39:00.000-08:002014-01-07T09:39:17.219-08:00Speed your HikaShop with Varnish<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCjI7lWlqKyIhSjOwpWysAMq-x1CmEvVJUAGfTvM0TwhvYDhMqFMFfJe5U872ZXW2q-o5uRUB5P9mYD1OosdGr3idLJPf5JLP0-oc03TciDp5oAFpaZFzd5FP19cO6A4VyckKQnohTSCk/s1600/logo-hikashop.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCjI7lWlqKyIhSjOwpWysAMq-x1CmEvVJUAGfTvM0TwhvYDhMqFMFfJe5U872ZXW2q-o5uRUB5P9mYD1OosdGr3idLJPf5JLP0-oc03TciDp5oAFpaZFzd5FP19cO6A4VyckKQnohTSCk/s1600/logo-hikashop.png" height="200" width="188" /></a><a href="https://www.hikashop.com/">HikaShop</a> is an e-commerce solution for Joomla. They have a pretty usable free edition, and reasonably priced commercial editions with support.<br />
We worked together with the Hikari team to make our <a href="http://massivescale.net/varnish-joomla.html">Varnish-Joomla</a> integration work with all editions of their extension. The result of this work is available in version 1.3.1 of our package, which was out in November 2013.<br />
No matter if your shop receives thousands or millions of view every day, your prospective clients deserve fast page loads. Visitors who don't have anything in their cart will enjoy viewing pages from cache, and more server processing power will remain for these who actually need it (visitors with items in their carts, visitors doing checkouts, your staff). Everybody wins.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-38254745498783302302013-12-12T06:49:00.004-08:002013-12-12T06:49:42.097-08:00Joomla 1.0 spamThis news comes from our <a href="http://joomla-10.net/">secure Joomla 1.0 hosting</a> department. Recently some of our Joomla 1.0 sites became sources of spam. Apparently somebody (with a narrow range of IP addresses geolocating to Malaysia) has found a security problem in VirtueMart recommendation module which allows them to send emails with POST requests.<br />
The solution was to paste the following code into Apache configuration (or .htaccess):<br />
<code>
# vm spam patch<br />
RewriteEngine On<br />
RewriteCond %{THE_REQUEST} ^.*(page=shop\.recommend).* [NC]<br />
RewriteRule ^.*$ - [F,L]<br />
</code>
<br />
<div>
<br />
If you're fed up dealing with lack of security in old Joomla versions, <a href="http://joomla-10.net/">give us a shot</a>. We run Joomla on latest Apache, PHP and MySQL versions, keep a month worth of backups and have several security measures.</div>
Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-49924310192430748682013-11-19T04:44:00.000-08:002013-11-19T04:44:24.351-08:00Varnish-Joomla Pack 1.3.1 with Joomla 3.2 support is outNew features:<br />
<br />
<ul>
<li>Support for Joomla! 3.2</li>
<li>Support for <a href="http://www.hikashop.com/">HikaShop</a></li>
</ul>
<div>
Joomla! 3.2 support has been tested with core components and the following extensions:</div>
<div>
<ul>
<li>JomSocial</li>
<li>Akeeba Backup</li>
<li>Admin Tools</li>
<li>Kunena Forum</li>
<li>Community Builder</li>
<li>HikaShop</li>
</ul>
<div>
Virtuemart does not support 3.2 (and <a href="https://forum.virtuemart.net/index.php?topic=114342.0">never will</a>), and that's the only reason why it's not included in the test. We continue to support it. As explained <a href="http://massivescale.blogspot.com/2013/11/varnish-for-joomla-32-on-its-way.html">here</a>, the patch for Joomla! 3.2 does not prevent creating new sessions for anonymous users. If you have a lot of cache misses caused by anonymous users, there will be an extra disk write operation per cache miss - if this concerns you, move your sessions to memcached or XCache.</div>
</div>
<br />
Upgrade from 1.3.0 and 1.2.2: Just replace the default.vcl file. As always, the upgrade is free for existing users.<br />
<br />
New users - order to <a href="https://massivescale.net/varnish-joomla.html#order">speed up your Joomla! and its extensions</a>.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-9890906938536427272013-11-15T09:34:00.003-08:002013-11-15T09:34:52.323-08:00Varnish for Joomla! 3.2 on its wayVarnish for Joomla 3.2 will be released next week. The plan was to release it this week, but Joomla 3.2 increased its dependence on sessions and the patch can not operate the same way it did before.<br />
In previous versions, we did what we could to not even create sessions in the database, thus lowering the number of disk writes required to serve users' requests. Unfortunately it doesn't look like it's possible any more and the best we can do is not sending session cookies to the user.<br />
This is a new approach and while it passes all internal tests against a vanilla Joomla install, it needs more testing with supported 3rd party components. <br />
I'm sorry for the delay, we got many requests about 3.2 availability in the past two weeks.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-28717363619522927892013-11-05T10:53:00.002-08:002013-11-05T10:53:49.380-08:00Varnish-Joomla package 1.3.0 released, with cache purgingThe new <a href="http://massivevps.net/varnish-joomla.html">Varnish-Joomla package</a> 1.3.0 is now available. New features include:<br />
<br />
<ul>
<li><b>Purging cache when saving articles</b></li>
<li>Support for more Joomla! extensions and static file types</li>
<li>Improved cache hit rate because of Accept-Encoding normalization</li>
<li>Support for Piwik and CloudFlare</li>
<li>More debugging headers</li>
</ul>
<div>
The biggest news is cache purging - this means that the moment you save your article, it is visible to your visitors. Behind the curtains, our Joomla plugin connects to your Varnish and tells it to remove cached copies of the saved page, pages of categories it belongs to, and the front page. This feature is optional, you don't need to install the plugin if this is not the desired behavior.</div>
<div>
The package has support for Joomla 2.5.4+, 3.0.x and 3.1.x, just like the previous version.</div>
<div>
There is good news for our existing customers: the patch to Joomla core didn't change, all features are implemented with the Varnish VCL file and an easily installable Joomla plugin.</div>
<div>
As usually, the upgrade is free, <a href="https://massivescale.net/contact.html">contact us</a> to receive the latest package if you've already purchased it.</div>
Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-51874222463811441802013-10-28T14:13:00.000-07:002013-10-28T14:13:00.188-07:00Make Joomla's Nextend Menu faster If you're using Nextend's Accordion Menu for Joomla, there's a good chance it's slowing you down. Adding this simple patch to make it use cache cut down average loading time by 900 ms on a Joomla 2.5 site.<br />
<br />
<br />
<ul>
<li>Open libraries/nextend/accordionmenu/treebase.php</li>
<li>Find the following part:</li>
</ul>
<br />
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> $this->renderItem();</span></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> function renderItem() {</span></div>
</div>
<div>
<br /></div>
<div>
<ul>
<li>Replace it with:</li>
</ul>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> $cache = & JFactory::getCache();</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> $cache->call(array($this, 'renderItem'), JURI::getInstance()->toString());</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> function renderItem($dummy=NULL) {</span></div>
</div>
</div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-83664589278487477132013-10-24T06:13:00.001-07:002013-10-24T06:14:52.505-07:00Alternatives to mod_rpafFor years, <a href="http://www.stderr.net/apache/rpaf/">mod_rpaf</a> has been the standard module for running Apache behind a reverse proxy. Fortunately, it's not the only one and there are alternatives.<br />
<br />
<ul>
<li><a href="http://www.cotds.org/mod_extract_forwarded2/">mod_extract_forwarded</a> which is available in EPEL, so it's available for CentOS systems without compling</li>
<li><a href="http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html">mod_remoteip</a> which is built into Apache 2.4 (but good luck finding a production server running 2.4)</li>
<li><a href="https://github.com/y-ken/mod_rpaf">mod_rpaf</a> modified to support X-Forwarded-Proto/X-Forwarded-HTTPS/X-HTTPS</li>
</ul>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-35537149889423665782013-10-22T05:07:00.001-07:002013-10-24T06:15:11.548-07:00New software available: HTML5 prerender support for Joomla! CMSMassive Scale is proud to announce its new software: <a href="https://massivescale.net/joomla-prefetch.html">HTML5 Prefetch/Prerender for Joomla!</a>. It makes use of <a href="https://massivescale.net/joomla-prefetch.html">prerendering</a> capabilities of web browsers like Chrome, Firefox or Internet Explorer 11 using machine learning techniques. You will learn more about <a href="https://massivescale.net/joomla-prefetch.html">prefetching, prerendering and Joomla!</a> on the product page.Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-47080509613843641302013-10-07T04:40:00.001-07:002013-10-07T04:53:23.986-07:00Thread creation error in Varnish<p> Today I installed Varnish on a pretty standard system (CentOS + WHM) and the service wouldn't start. The system log (/var/log/messages) contained the following:</p>
<pre>
Oct 7 04:15:46 server varnishd[20836]: Child (20846) Panic message: Assert error in WRK_BgThread(), cache_pool.c line 582:#012 Condition((pthread_create(thr, ((void *)0), wrk_bgthread, bt)) == 0) not true.#012errno = 11 (Resource temporarily unavailable)#012thread = (cache-main)#012ident = Linux,2.6.32-358.2.1.el6.x86_64,x86_64,-sfile,-smalloc,-hcritbit,no_waiter#012
</pre>
<p> The settings for number of processes and file descriptors in /etc/security/limits.{conf,d} were correct and it still didn't start. The problem turned out to be with stack size - I have no idea why this is happening in just this one system and works with every other centos, but the solution was as following:</p>
<p> 1. Patch /etc/init.d/varnish adding a new ulimit call in start()</p>
<pre>
# Stack size
ulimit -s unlimited
</pre>
<p> 2. Increase system limits in /etc/security/limits.conf accordingly</p>
<pre>
varnish stack soft unlimited
varnish stack hard unlimited
</pre>
<p> 3. Restart Varnish</p>
<p> After successfully running Varnish this way, be sure to change the stack limit back to a reasonable size! Unlimited is not a very wise setting, but helps debugging the problem. Now <a href="http://massivescale.net/varnish-joomla.html">Varnish and Joomla</a> could happily work together.</p>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-61292427177727813532013-09-04T03:49:00.001-07:002013-09-25T10:27:20.117-07:00Nextend modules for Joomla behind Varnish Cache<p> <a href="http://www.nextendweb.com/">Nextend</a> makes pretty and well-written modules for Joomla and Wordpress. I've optimized a website which uses one of them and it had a weird issue: sometimes the module would appear unstyled and CSS/JS files in the "media/nextend/cache/" directory returned 404. After reading some code the solution was obvious: Varnish was set to cache pages for at least 2 hours, while the Nextend module only cached it for 15 minutes, and deleted old files. Because every time it creates a new directory for updated cache content, it deletes old ones - cached HTML pages were referencing URLs which did not exist any more.</p>
<p> The solution was very simple: in Joomla admin go to Extensions - Plugins - Nextend Library, then click Configure in the Basic Options and set the cache time to the same value your Varnish installation uses. For the best <a href="http://massivescale.net/varnish-joomla.html">Varnish + Joomla</a> experience, see our offer.</p>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-66518996184385015442013-06-23T08:51:00.001-07:002013-06-23T08:55:07.939-07:00Zend opcode cacher in PHP 5.5: a security perspective<p> The new <a href="http://www.php.net/manual/en/book.opcache.php">zend opcache</a> extension built into the latest version of PHP is, <a href="http://massivescale.blogspot.com/2013/06/php-55-zend-optimiser-opcache-vs-xcache.html">as we've checked</a>, a bit faster than the current best - XCache. There's, however, a security concern.</p>
<p> Both extensions make it possible to clear the whole cache programatically (from within a script). In Zend it's the <a href="http://www.php.net/manual/en/function.opcache-reset.php">opcache_reset()</a> function and in XCache it's <a href="http://xcache.lighttpd.net/wiki/XcacheApi#AdministratorFunctions">xcache_clear_cache(XC_TYPE_PHP)</a>.</p>
<p> If you run shared hosting, you allow your users to execute arbitrary code in your PHP interpreter. This, naturally, includes the two functions mentioned above. If you rely on the opcode cache to provide desired level of service for your customers, you don't want them to clear everybody's caches. If a malicious or badly written script clears your cache, say, every minute - there is no benefit from caching. The whole idea is that you cache the most used files once, and use the cached version from RAM. What this means for a shared host is increased CPU and possibly disk IO usage. In some cases, this can turn into a Denial of Service (DoS) attack.</p>
<p> So let's take this simple script and see what Zend Opcache will do when you execute it:</p>
<pre>
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
opcache_reset();
echo 'OK';
</pre>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhc0BFT3ub1vJlWUDYbKXO7CNmQoB8SN9CiJ_97Wbndc5V5B3mrzFdxpJHWXumtdUwkQAOOG6BzAmEg7GUPIl5yoRmbwXC4FGVbCJCzrRdRqZjRRwwglvJPeOk2zxRuCSRdDs64Qq4VtX4/s1600/opcache-zend-clear.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhc0BFT3ub1vJlWUDYbKXO7CNmQoB8SN9CiJ_97Wbndc5V5B3mrzFdxpJHWXumtdUwkQAOOG6BzAmEg7GUPIl5yoRmbwXC4FGVbCJCzrRdRqZjRRwwglvJPeOk2zxRuCSRdDs64Qq4VtX4/s320/opcache-zend-clear.png" /></a></div>
<p> Well, Zend happily cleared the cache. Now let's see what XCache does:</p>
<pre>
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
xcache_clear_cache(XC_TYPE_PHP);
echo 'OK';
</pre>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0SmrneyC63Ink5hDF-GmTh9WgOgyeW28Um5swfJwYOzT44SesrvPL0uauys5zWHKzF8sJaMbgXoJbE3Iso8cF2QHsJZisk6LwiL4T2sKQKjh-a4qImCXBfH7kaAdn4HwJ6BhbL3BSkTM/s1600/opcache-xcache-clear.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0SmrneyC63Ink5hDF-GmTh9WgOgyeW28Um5swfJwYOzT44SesrvPL0uauys5zWHKzF8sJaMbgXoJbE3Iso8cF2QHsJZisk6LwiL4T2sKQKjh-a4qImCXBfH7kaAdn4HwJ6BhbL3BSkTM/s320/opcache-xcache-clear.png" /></a></div>
<p> The XCache developer envisioned this problem. Certain functions, which affect other users' experience, trigger a login page. The username and password is set by an administrator system-wide in php.ini and is not viewable by regular users.</p>
<h3>Conclusion</h3>
<p> If you run a shared host and want to speed it up using opcode caching, you should use XCache rather than the new Zend Opcache. Zend is only better by 10%, it's not a number worth risking a DoS attack. On the other hand, if you and only you control the code that's run on your servers, this security issue won't affect you.</p>
<h3>Possible fix</h3>
<p> You could (and should) use the <a href="http://www.php.net/manual/en/ini.core.php#ini.disable-functions">disable_functions</a> directive in php.ini</p>
<p> (<a href="http://massivescale.net/performance-tuning.html">Need help installing XCache or securing Zend?</a>)</p>
Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com0tag:blogger.com,1999:blog-1331448417861019545.post-9517273070240111282013-06-23T08:51:00.000-07:002013-07-15T03:09:46.683-07:00PHP 5.5: Zend Optimiser+ OPcache vs XCache<p> PHP 5.5 has a new feature: built-in opcode cache! It's an alternative for extensions like XCache, APC or eAccelerator. Let's see how it performs compared to established solutions.</p>
<h3>Test environment</h3>
<p> Server: OpenVZ container running on 1 Xeon W3520 CPU core, high I/O priority (to ensure CPU-bound execution), 1 GB RAM. Requests originating from another <a href="http://massivevps.net/">VPS</a> on that system.</p>
<p> Software: Debian 7.0 i386, nginx 1.2.1, PHP 5.5.0 from <a href="http://www.dotdeb.org/2013/06/20/php-5-5-0-is-out-and-available-for-debian-7-0-wheezy/">dotdeb</a>, XCache SVN trunk from 2013-06-23 (r1269).</p>
<p> (This test may or may not reflect what is happening on dedicated servers. Unfortunately, we don't have a spare server-grade physical machine at the moment. That being said, the machine which held the VPS is under a small network and IO load.</p>
<h3>PHP-FPM configuration</h3>
<pre>
pm = dynamic
pm.max_children = 25
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.max_requests = 5000
</pre>
<p>Zend Opcache has been configured as following:</p>
<pre>
root@opcode:/var/www# grep ^opcache /etc/php5/fpm/php.ini
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=4
opcache.max_accelerated_files=3907
opcache.fast_shutdown=1
</pre>
<p>XCache has been configured as following:</p>
<pre>
xcache.size = 128M
xcache.count = 3
xcache.cacher = On
</pre>
<h3>Joomla</h3>
<p> Joomla! 3.1.1. Installation was tricky, <code>installation/application/framework.php</code> had to be edited, this line in particular: <code>ini_set('display_errors', true);</code> - otherwise AJAX calls didn't succeed because JSON has been polluted with error messages.</p>
<p> The "Default English" sample data set has been installed. Joomla cache has been disabled because it's not what we want to test.</p>
<h3>Test</h3>
<p> The Apache Benchmark has been used to measure average response time and number of requests served per seconds. The command line was:</p>
<pre>
ab -n 10000 -c 20
</pre>
<p> Ten thousands requests have been performed by 20 concurrent threads. This corresponds with the <code>pm.max_children=25</code> setting in php.ini.</p>
<h3>No cache</h3>
<p> Performance is clearly CPU-bound. CPU usage is 100%, RAM utilization is about 880 MB out of 1GB. Disk I/O is negligible measured from both within the container (%wa 0) and the hypervisor (%wa 7).</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl9_JQq1btGOhFmHNEcF-p8UrVo9uoSEeFQAbieWvqekUQFSZYuLTZ9VADUgplse9Esxvqc8d2Ye-g4dW8cbgLrm7wWrayR8I7qH5UsfXAZtddu1lIeJez-Aw7Ln3tloKiurrr69phTts/s1600/opcache-no-cache-top.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl9_JQq1btGOhFmHNEcF-p8UrVo9uoSEeFQAbieWvqekUQFSZYuLTZ9VADUgplse9Esxvqc8d2Ye-g4dW8cbgLrm7wWrayR8I7qH5UsfXAZtddu1lIeJez-Aw7Ln3tloKiurrr69phTts/s320/opcache-no-cache-top.png" /></a></div>
<p>Apache Benchmark output (<a href="#" onclick="document.getElementById('ab-opcache-nocache').style.height='';">Unfold</a>)</p>
<pre id="ab-opcache-nocache" style="height: 200px; overflow: scroll">
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 176.31.28.48 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.2.1
Server Hostname: 176.31.28.48
Server Port: 80
Document Path: /
Document Length: 8626 bytes
Concurrency Level: 20
Time taken for tests: 1743.994 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 89890000 bytes
HTML transferred: 86260000 bytes
Requests per second: 5.73 [#/sec] (mean)
Time per request: 3487.989 [ms] (mean)
Time per request: 174.399 [ms] (mean, across all concurrent requests)
Transfer rate: 50.33 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 656 3483 1020.6 3166 9587
Waiting: 403 2999 778.5 2812 8757
Total: 656 3483 1020.6 3166 9587
Percentage of the requests served within a certain time (ms)
50% 3166
66% 3528
75% 3849
80% 4091
90% 4797
95% 5540
98% 6695
99% 7420
100% 9587 (longest request)
</pre>
<h3>Zend OPcache enabled</h3>
<p> It looks like the CPU hasn't been fully utilized with 20 concurrent requests. The usage fluctuated between 70% and 90%. I/O and memory usage were, as previously, within reasonable limits.</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTNRlMAab8VHn8dHiV0ndKKDkQfsAQnPdJ_12DaR12n-T2IGZYpaKzLK1Vpz5ULJsY40j4uQHE8J2kL8W3SrCygsjuHfXNJAb_-KZ3LaVQzP9bQ5Jt-fI8n4Hw2ngY2Wy7JkPOYRnhftM/s1600/opcache-zendcache-top.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTNRlMAab8VHn8dHiV0ndKKDkQfsAQnPdJ_12DaR12n-T2IGZYpaKzLK1Vpz5ULJsY40j4uQHE8J2kL8W3SrCygsjuHfXNJAb_-KZ3LaVQzP9bQ5Jt-fI8n4Hw2ngY2Wy7JkPOYRnhftM/s320/opcache-zendcache-top.png" /></a></div>
<p>Apache Benchmark output (<a href="#" onclick="document.getElementById('ab-opcache-zendcache').style.height='';">Unfold</a>)</p>
<pre id="ab-opcache-zendcache" style="height: 200px; overflow: scroll">
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 176.31.28.48 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.2.1
Server Hostname: 176.31.28.48
Server Port: 80
Document Path: /
Document Length: 8626 bytes
Concurrency Level: 20
Time taken for tests: 658.408 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 89890000 bytes
HTML transferred: 86260000 bytes
Requests per second: 15.19 [#/sec] (mean)
Time per request: 1316.817 [ms] (mean)
Time per request: 65.841 [ms] (mean, across all concurrent requests)
Transfer rate: 133.33 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 421 1316 426.2 1214 5664
Waiting: 275 1053 355.8 986 4329
Total: 421 1316 426.2 1214 5664
Percentage of the requests served within a certain time (ms)
50% 1214
66% 1333
75% 1448
80% 1537
90% 1826
95% 2065
98% 2484
99% 2780
100% 5664 (longest request)
</pre>
<h3>XCache</h3>
<p> Just like previously, the load has been CPU-bound even after enabling XCache.</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMOeTEbj2D6jQpLuKTDqPSpripyxQlLMajIdXpAfCbloaFgokOQ_4iia0FDab0E1yCCzlFkzGyvipDE4RUHFOR6ufneZOBLoh5XCLpC9mZKHK0prm_lpcTAtGMX8xguQVGq66n9ZH4Pzw/s1600/opcache-xcache-top1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMOeTEbj2D6jQpLuKTDqPSpripyxQlLMajIdXpAfCbloaFgokOQ_4iia0FDab0E1yCCzlFkzGyvipDE4RUHFOR6ufneZOBLoh5XCLpC9mZKHK0prm_lpcTAtGMX8xguQVGq66n9ZH4Pzw/s320/opcache-xcache-top1.png" /></a></div>
<p>Apache Benchmark output (<a href="#" onclick="document.getElementById('ab-opcache-xcache').style.height='';">Unfold</a>)</p>
<pre id="ab-opcache-xcache" style="height: 200px; overflow: scroll">
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 176.31.28.48 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.2.1
Server Hostname: 176.31.28.48
Server Port: 80
Document Path: /
Document Length: 8626 bytes
Concurrency Level: 20
Time taken for tests: 769.788 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 89890000 bytes
HTML transferred: 86260000 bytes
Requests per second: 12.99 [#/sec] (mean)
Time per request: 1539.576 [ms] (mean)
Time per request: 76.979 [ms] (mean, across all concurrent requests)
Transfer rate: 114.04 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 601 1538 431.1 1439 4401
Waiting: 393 1232 361.6 1178 4205
Total: 601 1539 431.1 1440 4401
Percentage of the requests served within a certain time (ms)
50% 1440
66% 1582
75% 1696
80% 1784
90% 2079
95% 2333
98% 2847
99% 3179
100% 4401 (longest request)
</pre>
<h3>Graphs</h3>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPM-g5TTR50yddzfd9a1s-gEySWygmHdVPybzWUTMpVzPLRwYDEfJqaoDpk17dVvfY24lQjdU7iJd_A-8fgD1PrwEKIpY7IOdWZ1u6ERZktck3VCCrTFtaW02O8HacvQc6oFZ1c3uJ8SU/s1600/opcache-time.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPM-g5TTR50yddzfd9a1s-gEySWygmHdVPybzWUTMpVzPLRwYDEfJqaoDpk17dVvfY24lQjdU7iJd_A-8fgD1PrwEKIpY7IOdWZ1u6ERZktck3VCCrTFtaW02O8HacvQc6oFZ1c3uJ8SU/s400/opcache-time.png" /></a></div>
<p> Time graph: less is better</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0p0q_DjtpHDqZloXmTc27ebBrBIMSnJ65H4gpW49E3BE5lxTC6edLqY4vyGSpwO9d-8Llw7tL6rWH0GLX6_MPa1mAzXgHzysMNpiPWGcHx3qn7oZ1GdMKKRegQac8ckPDyN0LNiKrteg/s1600/opcache-reqsec.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0p0q_DjtpHDqZloXmTc27ebBrBIMSnJ65H4gpW49E3BE5lxTC6edLqY4vyGSpwO9d-8Llw7tL6rWH0GLX6_MPa1mAzXgHzysMNpiPWGcHx3qn7oZ1GdMKKRegQac8ckPDyN0LNiKrteg/s400/opcache-reqsec.png" /></a></div>
<p> Requests per second graph: more is better</p>
<h3>Comment</h3>
<p> Well, XCache is no more the best opcode cache around. We're looking forward to widespread adoption of PHP 5.5+. Unfortunately, there is currently no GUI for nicely analyzing cache usage, like XCache has. However, Zend exposes a new function, <code>accelerator_get_status()</code>, which could be used to create such a GUI - so certainly somebody will release relevant GUI in the next weeks.</p>
<p> EDIT: We didn't have to wait long - as a reader pointed out, there is a <a href="https://gist.github.com/ck-on/4959032">GUI for Zend Optimizer</a>.</p>
<p> As usual, if you need help, we will <a href="http://massivescale.net/performance-tuning.html">make your website fast</a> for you.</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEGGENr-2Qjm0tvh7HGr1koG1V8wcHuiWn6_KIlNKpcHJN_Rv8tRtm9-MW9ySN6TLBRKUe0SfezxPEpMiQ3lUSNv3QOnqORfrMPSuSvXC44gCXbUN0Q3OjBp6r4OoqIjILV0FpJOe6aCI/s1600/opcache-xcache-gui-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEGGENr-2Qjm0tvh7HGr1koG1V8wcHuiWn6_KIlNKpcHJN_Rv8tRtm9-MW9ySN6TLBRKUe0SfezxPEpMiQ3lUSNv3QOnqORfrMPSuSvXC44gCXbUN0Q3OjBp6r4OoqIjILV0FpJOe6aCI/s320/opcache-xcache-gui-2.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyWvlW1QDyr7G3opcelB2-Mmf9_loc9UWnGft_bBNiAWMZLi9R5MHlIf_hqpbO_A3DE1qzcgO7PZ3q1yMUs4gqQr6Dxcr9F-R94Sbua6GMCeUk226fwqgdZ3KH2nH6zRloLYc598-0m4o/s1600/opcache-xcache-gui-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyWvlW1QDyr7G3opcelB2-Mmf9_loc9UWnGft_bBNiAWMZLi9R5MHlIf_hqpbO_A3DE1qzcgO7PZ3q1yMUs4gqQr6Dxcr9F-R94Sbua6GMCeUk226fwqgdZ3KH2nH6zRloLYc598-0m4o/s320/opcache-xcache-gui-1.png" /></a></div>Anonymoushttp://www.blogger.com/profile/16913953736585630845noreply@blogger.com13