I would like to announce a special package here at Alagad, for those who are suffering server woes and need to closely control their budget. For a flat rate of $1999, you can have Alagad review your ColdFusion server configuration, identify potential bottlenecks, profile your source code, and ultimately end up with a comprehensive document outlining recommended changes to your current configuration (and / or source code) to improve performance of your application, all in 1 - 2 days. This includes up to 15 hours of server analysis and documentation. We will work closely with your team to determine the best way of testing your application, as well as identify areas your team feels may need to be reviewed more closely than others.
You can request a written proposal and additional details here, and simply mention the 'Alagad Economic Stimulus Package' to receive this special flat rate pricing. Projects will be done on a first-come first-served basis, so sign up soon, you could be sporting a faster application server this week!
Just wanted to put a quick post out there. I host about 50 trac environments on an EC2 server, several rather large ones of which are public and pretty high traffic. Yesterday the trac server started having issues, and most of the logged errors had a seemingly random type of python trace data, followed by:
IOError: failed to write data
I dug around online for a bit but did not see much in the way of help for this issue, then I noticed that nearly all the errors were showing from a client that started with 65.55.X.X. Flipping through other logs, it appeared to be an MSN bot agent hitting Trac pages, and in some cases even hitting an infinite recursion (somehow linking to /report2/report2/report2/report2/......). The quick and dirty fix to solve this issue was to block the entire subnet from accessing my vhosts, which was done with this little gem inside of each vhost <directory> tag in Apache:
Order Allow,Deny
Allow from all
Deny from 65.55.0.0/16
Granted this is not a perfect solution, but keeping the site up for real users was more important at the moment than allowing a rampant recursive spider to keep slamming the site as soon as I brought it back up (for nearly 2 days straight now).
Happy Friday!
This is part 3 in my Troubleshooting Coldfusion Performance series. It was briefly interrupted by a great trip to CFUnited 2009, then catching up, but here it finally is! Several folks approached me at CFUnited with encouragement and enthusiasm for this series, I cannot tell you how much I appreciate that! I'm glad I can finally give something back to a community that has given me so much over the years!
As this is part 3, you will most likely want to take a quick read over the 1st 2 posts in this series.
So at this point, we have isolated and resolved a SQL performance issue using some of the tools that come with MS SQL. While this does not mean that our SQL configuration is now completely optimal, it has resolved the largest issue we are observing here, so we move on. Now its time to tackle our out of memory issues.
For anyone who missed it, or wanted to get some of the program links or jvm.config settings, here you go!
OK, time for a follow up to my 1st post in this troubleshooting series for our Project X, and I am going to talk about some steps we can take to better identify and isolate the issues today. I had some great participation on the last post, thanks to all who contributed (and you are entered for the backpack!). If you have not read the first post outlining the hypothetical scenario, do that before reading the rest here.
So the first step I usually take in any project is as simple as observation. Looking at task manager, and enabling the 'show kernel times', will give us an instant pointer. Lets take a peek at one of the web servers while it is under heavy load, and we see this:
