Thread

It’s not my choice. I’ve explained the problem to the decision maker and I’ve put a support ticket in with the hosting company. I’ll let you know what happens.

Tip: Avoid hosting companies with the word “fast” in their company name?

Got some great results today. The new server we were running had PHP installed as FastCGI. We’ve now switched it to ISAPI and the site is absolutely flying. If anyone does have to serve on a Windows platform with IIS I highly recommend you setup PHP to use ISAPI and not CGI.

Richard

Richard, thanks for coming back with that information. I’m sure it will help others implementing EE on Windows platforms.

Got some great results today. The new server we were running had PHP installed as FastCGI. We’ve now switched it to ISAPI and the site is absolutely flying. If anyone does have to serve on a Windows platform with IIS I highly recommend you setup PHP to use ISAPI and not CGI.

Richard

That’s funny I’ve heard from other’s and thought fastCGI was the way to go, I would of recommended checking out the Zend PHP stack. Glad you are having better luck with it now then.

I spent a fair amount of time searching around on the net for what is recommended for PHP with IIS: ISAPI or FastCGI. The general vibe I got from this was that ISAPI was faster yet less stable than FastCGI.

With a previous company I was lead developer and also responsible for managing a Windows 2003 dedicated server which was setup with PHP running via ISAPI and all sites ran relatively quickly on that setup. I knew on the project discussed in this topic that the server was running PHP as CGI which led me to question whether this was an issue.

Based on my experience, all I can say on this issue is try each one if you can and see for yourself.

Thanks again,

Rich

The game changer was within the past year where the fastCGI setup’s are officially supported now even. Too bad you didn’t have good luck with it then tr309, thanks for the feedback.

I’m all for someone at EE changing the title of this Topic to something else; perhaps a bit less demeaning.

😉

@ Boyink! said “Embeds = good.  Usually.  But like anything good they can also be overused.  I’ve logged into some EE installs that just had me shaking my head…;)”

> Can you expand a bit on embed usage that’s made your head shake? some examples maybe?

@ GDmac said “You could also move the CSS to a static file on the server, instead of dynamic as a template.”

> I could make out the diagram well. I also don’t have much of a clue on what you were asking me to look at :( Maybe you can tap out a couple lines as you why template CSS is not a good thing.

Would there be any advantage to doing the CSS as an embed - along with some caching - instead of a CSS template?

For minor tweaks and such it’s seems to be nice to just log in to EE (from the closest available computer), have all files there (not static) and get done what’s necessary without having to worry about ftp, source files, etc. Right?

> Can you expand a bit on embed usage that’s made your head shake? some examples maybe?

I’m sure Boyink has his own examples, but one that I will never forget was a weblog entries tag returning over 200 results, with an embed tag inside, and that embed template embedded two other templates, both of which each had Query module tags on them.  That one weblog entries loop was generating hundreds and hundreds of queries, all of which were a result of poor template design.

For minor tweaks and such it’s seems to be nice to just log in to EE (from the closest available computer), have all files there (not static) and get done what’s necessary without having to worry about ftp, source files, etc. Right?

I completely agree and keep my CSS in templates, always.  Then I know I can always make changes from any web appliance.  If avoiding static files isn’t one of the points of using a CMS for a project, I don’t know what is (for me, anyway).  That said, I’d also never host a site anywhere on Windows or that was using PHP under CGI, as that prevents PHP from being able to send/read headers that would enable the visitor’s browser to cache the CSS.

Shake my head? That would make be run away. Fast 😊

I’m just using embed for “repeated” elements (e.g. nav, footer, etc.)

Would there be an advantage to doing the CSS as an embed instead of using template type = CSS? How does a browser treat a EE based CSS (as opposed to a static CSS)?

If the CSS is being “sent down the wire” everytime - as opposed to a tradition static CSS being cached - then isn’t using an embed the same thing? But maybe there’s a (minor) performance issue?

If you embed your CSS, then yes, you’re preventing the visitor’s browser from being able to cache it, and that data will be transmitted with the HTTP request along with the rest of the page content.  If you are hosted in a non-Windows, non-CGI environment, though, and using EE’s {stylesheet=} links to your CSS templates, headers are used so that the visitor’s browser caches it just as if it were a static CSS file.

...If avoiding static files isn’t one of the points of
using a CMS for a project, I don’t know what is (for me, anyway)

- Serving dynamic pages and connect parts and data in a dynamic way
- Enabling multiple members to author and moderate content (access rights)
- interacting with visitors, comments, polls, forum etc. (communities)
- automate and abstract web-publishing (titles, editting etc. without html knowledge)

CSS editting isn’t high on my list for reasons of CMS usage. Static CSS can save some DB-queries.
CSS Backgrounds are relative to the CSS file, so same directory can be handy: url(bgimg.jpg)
CSS, most of the time, is not mission-critical anymore, after site-launch.
CSS is cascading, so (temporary / emergency / remote) override can be done thru the embedded HEAD template.

...using PHP under CGI, as that prevents PHP from being able to send/read headers that would enable the visitor’s browser to cache the CSS.

I wasn’t aware of this, so are there any other EE specific issues that PHP under CGI causes I should be aware of?

When I looked around for a new host a while ago I got the impression that on shared hosting accounts it was the norm, as it was just too insecure now to run it direct.

I have several EE sites running on it and haven’t been aware of any problems, but am I just blissfully ignorant?

@GDmac - “CSS editting isn’t high on my list for reasons of CMS usage.”  So it’s not important to you to avoid static files, fine, that doesn’t mean it won’t be important to others; it is to me.  To add a quick example, say your organization has an employee or team assigned to style print and web media.  None of them are allowed FTP access, and they shouldn’t be allowed to edit all templates as some may have PHP enabled, or it’s a different person / team in charge of that, etc.  Or the publishers simply need to add a style in that they can make use of in their entries.  In either case, FTP and full template access is inappropriate.  ExpressionEngine’s easy solution is to assign them to a member group that has access to edit the CSS stylesheet(s) only.  Boom.  “Static CSS can save some DB-queries.”  If you’re worried about a few read queries, maybe dynamic isn’t the type of delivery you need for a project.  Again, in the proper environment, the visitor’s browser will cache EE’s CSS templates, and not even send an HTTP request for it again until the stylesheet is updated, so the query savings is practically unmeasurable.

@Paul Frost - It’s (PHP under CGI) a very easy way to provide an additional layer in shared hosting environments, and is cheap to implement.  Hosts that are truly interested in both PHP performance and security for their users in shared environments will run PHP as an Apache module, and do not run Apache as ‘nobody’ or ‘www’, but as your user.  It’s more expensive because you have memory allocated and processes for each user account instead of one shared pool, which is why you generally only see it on medium to high end hosts.  Other common issues are slower performance, increased memory usage, and an inability to see meaningful error messages if PHP crashes within the CGI wrapper (they’ll just be logged as generic 500 server errors).

Thanks Derek, that explains it a bit more.
What about EE specific issues, aside from the lack of caching the CSS?

You mentioned that only medium to high end hosts do it properly, does anyone out there have any recommendations for UK based hosts that provide this?

I have looked at Engine Hosting in the past but understood the control panel was a bit limiting compared to cPanel and it’s nice for the host to be in the UK and be able to phone support.